Date: Mon, 10 Mar 2008 11:57:26 +0600 From: Max Khon <fjoe@samodelkin.net> To: obrien@freebsd.org Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/usr.bin/make globals.h job.c job.h main.c make.1 make.h parse.c Message-ID: <47D4CDC6.6040302@samodelkin.net> In-Reply-To: <20080131171725.GA66805@dragon.NUXI.org> References: <200703080916.l289GB7N040141@repoman.freebsd.org> <20080113101421.GA45977@dragon.NUXI.org> <47A1BE18.4000903@samodelkin.net> <20080131171725.GA66805@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi! David O'Brien 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. > > While I think the functionality is pretty cool, and a really neat future. > I'd actually like to have this functionality off by default. I think > this is seriously dangerous, and I'd like to know about prior art to > justify having it on by default. I've talked to one of the NetBSD > make(1) maintainers, and he was quite suprised we'd have this on by > default too. It is turned on for GNU make by default. That was the only justification. >>> 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. > > That was at a minimum - the more I think about it, 'make -n' cannot have > side affects. /fjoe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47D4CDC6.6040302>