cvs commit: src/usr.bin/make globals.h job.c job.h main.c make.1 make.h parse.c

[David O'Brien]

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?


>   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.

-- David