David O'Brien wrote:
On Thu, Mar 08, 2007 at 09:16:11AM +0000, Max Khon wrote:
fjoe 2007-03-08 09:16:11 UTC
Modified files:
usr.bin/make globals.h job.c job.h main.c make.1
make.h parse.c
Log:
Implement "Remaking Makefiles" feature:
After reading Makefile and all the files that are included using
.include or .sinclude directives (source Makefiles) make considers
each source Makefile as a target and tries to rebuild it. Both
explicit and implicit rules are checked and all source Makefiles are
updated if necessary. If any of the source Makefiles were rebuilt,
make restarts from clean state.
How does one turn this off? It causes SuffFindDeps to be run over every
.MAKEFILE_LIST member. This causes a problem if you try to build in
src/gnu/usr.bin/cvs/contrib and ./Makefile has an older date than
src/contrib/cvs/contrib/Makefile.in.
I'm curious, is this functionality depended on to build world? Or it
is a feature to do cool stuff outside of /usr/src?
I wanted to use this feature to auto-calculate depends during build
world. I know about Makefile.in issue in contrib/cvs and this seems to
be the only issue in FreeBSD src tree. I'd better remove Makefile.in
from there.
When remaking a source Makefile options -t (touch target), -q (query
mode), and -n (no exec) do not take effect, unless source Makefile is
specified explicitly as a target in make command line.
I'm not so sure this is good behavior. When trying to debug the issue
with src/gnu/usr.bin/cvs/contrib/Makefile; I did:
rm Makefile ; cvs up Makefile ; make -n
and yet still had my Makefile damanged (do to the other issues with this
commit). I really do think 'make -n' really does mean "DO NOT ACTUALLY
EXECUTE THEM".
At a minimum, make.1 needs updating to make it clear that 'make -n' can
have side affects.
Will do it.
/fjoe
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
