Date: Thu, 31 Jan 2008 09:17:25 -0800 From: "David O'Brien" <obrien@freebsd.org> To: Max Khon <fjoe@samodelkin.net> 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: <20080131171725.GA66805@dragon.NUXI.org> In-Reply-To: <47A1BE18.4000903@samodelkin.net> References: <200703080916.l289GB7N040141@repoman.freebsd.org> <20080113101421.GA45977@dragon.NUXI.org> <47A1BE18.4000903@samodelkin.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 31, 2008 at 06:24:56PM +0600, Max Khon wrote: > 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. 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. >> 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. -- -- David (obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080131171725.GA66805>