> >>>>> 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) ?
>
Although editcap_SOURCES refers to the source files in their paths, they are actually compiled by their respective Makefile.nmake files in their directories, hence the objects are also placed on those directories. editcap_OBJECTS, by the rule you listed, converts those paths to object paths for the linker which can find them.
--
Graham Bloice