Re: configure in snapshout == configure.in
От | Peter Eisentraut |
---|---|
Тема | Re: configure in snapshout == configure.in |
Дата | |
Msg-id | Pine.LNX.4.30.0012271924040.1006-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: configure in snapshout == configure.in (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: configure in snapshout == configure.in
|
Список | pgsql-hackers |
Tom Lane writes: > Last week I tried to do a "make clean" in some subdirectory that's > not cleaned by a toplevel clean -- I think it was doc/src/sgml, but it > might have been a contrib dir -- and make went absolutely nuts. When > the dust settled I had a toplevel configure file that was identical to > configure.in, just like you describe, and I couldn't do anything because > make kept trying to re-execute configure before it would do anything else. It's in contrib/rserv/Makefile %: %.in sed -e "s:_OBJWD_:$(libdir)/contrib:g" \ -e "s:_DLSUFFIX_:$(DLSUFFIX):g" \ -e "s:@SQLDIR@:$(libdir)/contrib:g"\ -e "s:@BINDIR@:$(bindir):g" \ -e "s:@LIBDIR@:$(libdir)/contrib:g" <$< > $@ chmod 775 $@ which also triggers in src/Makefile.global $(top_builddir)/config.status: $(top_srcdir)/configure cd $(top_builddir) && ./config.status --recheck when configure.in is older than configure, which is not all that unlikely. I guess the rule in rserv's makefile needs to be qualified better. > I've seen some other bizarre behavior from make lately, like failing to > rebuild utils/SUBSYS.o when some of the utils subdirectories contained > newer SUBSYS.o files. Again, hard to replicate, but I've seen it. > I'm starting to wonder if our spiffy new makefiles are stressing any > buggy areas of gmake... I'm aware of that problem. It's pretty easy to replicate actually, if you touch a file two or more directories deep under src/backend you will get an incomplete build. I'm thinking that we should convert the subdirectories' rules for building their subdirectories back to a straigh for-loop and not the cuteness that the backend/Makefile tries to do to get parallel make's working efficiently. Eventually the solution would be to put all the rules in one makefile and not rely on recursion at all, but that's for another day's debate. > FWIW, I'm running GNU Make version 3.79.1, which is the latest release > last I checked. ... but not necessarily the best. :-( -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
В списке pgsql-hackers по дате отправления: