From: Joe E. <jen...@fl...> - 2003-03-26 03:02:52
|
Forest W wrote: > >If yes it is damaged, IMHO. If not we have a very weird situation, because > >the > >transformation from Makefile.in to Makefile should leave the above line > >alone. > > No; expat/Makefile.in:301 sets VPATH to: > $(srcdir)/..:$(srcdir)/xmltok:$(srcdir)/xmlwf:$(srcdir)/xmlparse > As you can see, the leading $(srcdir) is present here. > > The Makefile generated by configure sets VPATH to: > /..:$(srcdir)/xmltok:$(srcdir)/xmlwf:$(srcdir)/xmlparse > > However, when I delete the generated Makefile, run autoconf, and then > run configure again, the new Makefile sets VPATH to: > $(srcdir)/..:$(srcdir)/xmltok:$(srcdir)/xmlwf:$(srcdir)/xmlparse > > What do you think of that? What version of autoconf did you use? What version of autoconf was used to build the configure script in the TclXML distribution? Autoconf 2.13 has a crude special-case hack that removes VPATH lines if $(srcdir) is equal to "." (which is the normal case), in order to work around a bug in Sun's 'make'. It looks like autoconf 2.52 has added some additional overcleverness: instead of deleting VPATH lines entirely, it tries to munge them using a hairy sed script. My guess: Andreas is building in the 'build' subdirectory, so the VPATH munging doesn't happen; Forest is building in the source directory, so it does, and that's what's breaking stuff. (BTW: expat is extremely portable source code and doesn't require a whole lot of autoconfigury to compile. expat/{Makefile,configure}.in can probably be simplified considerably.) --Joe English jen...@fl... |