On Fri, Feb 17, 2012 at 10:34:33AM -0500, Jeff Morriss wrote:
> Joerg Mayer wrote:
>> On Fri, Feb 17, 2012 at 02:01:05PM -0000, Graham Bloice wrote:
>>>>> Most likely it has a problem with the / instead of \ in uil/util.obj.
>>>>> Does someone have an idea how to resolve this?
>>>> util.obj is being produced in the top level root directory, but the linker
>>> is
>>>> looking for it in ui\. I'm looking at the makefile now.
>>>>
>>> Hmm. I think this would need an explicit build rule. As it stands, the
>>> compiler is told to compile ui/util.c when in the top level directory, so
>>> that's where the object file is placed. The linker is told to look for
>>> ui/util.obj and complains.
>>
>> Thanks for looking into it. I will look at how to resolve this in the
>> build structure. As this is is going to effect additional files as I move
>> the files around we need a "proper" solution. Ideas are of course
>> welcome ;-)
>
> I've been a little uneasy with the fact that there's no makefile in ui/
> . It seems like putting source files in there but no makefile is asking
> for trouble. But I haven't thought about it much.
Adding Makefiles (at least to ui/cli/) is likely to happen. What I fail to
see is the difference to the case of editcap (toplevel Makefile.common)
where we add epan/crypt/md5.c and epan/nstime.c to the source list. Is the
following line of Makefile.nmake responsible for "fixing" this problem:
editcap_OBJECTS = $(editcap_SOURCES:.c=.obj)
?
Thanks
Jörg
--
Joerg Mayer <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.