cvs commit: src/usr.sbin/config main.c

[Ruslan Ermilov]

On Fri, Apr 22, 2005 at 01:24:47PM -0700, Marcel Moolenaar wrote:
> On Apr 22, 2005, at 1:16 PM, Ruslan Ermilov wrote:
> 
> >On Fri, Apr 22, 2005 at 01:08:14PM -0700, Marcel Moolenaar wrote:
> >>On Apr 22, 2005, at 1:03 PM, Ruslan Ermilov wrote:
> >>
> >>>>>What exactly is broken? I don't see a breakage, even when source
> >>>>>files disappeared. I assume I must be forgetting something or not
> >>>>>doing everything right.
> >>>>
> >>>>when an include file is removed, make depend can fail to recreate
> >>>>.depend in the modules.
> >>>>
> >>>This is only a problem with NO_CLEAN builds, and it's not limited
> >>>to just modules -- I often saw this problem with the world builds.
> >>
> >>Ok. Does it help if there's an option to make that supresses the
> >>automatic loading on .depend or more generically, allows one to
> >>name the depend file and it merely defaults to .depend (suppression
> >>is then accomplished by specifying /dev/null as the depend file)?
> >>If such option would be used for "make depend", would that resolve
> >>the problems in a generic way?
> >>
> >Nope.  We only regenerate .depend when its dependencies are
> >changed.  For bsd.prog.mk, this means that .depend is only
> >regenerated when some of ${SRCS} are changed (but this does
> >NOT cover headers these ${SRCS} include, and some of these
> >headers may disappear).
> >
> >To put it differently: when a header disappears, the breakage
> >is not at the "make depend" stage (which doesn't do anything),
> >but at a later "make all" stage.
> 
> I see. I'm probably not understanding the problem completely,
> but this definitely gets me in the right state of mind.
> 
At point 1 in time, you have your source foo.c depend on
header bar.h.  At point 2 in time, bar.h disappears, source
foo.c doesn't change (bar.h was depended through indirect
inclusion via another header), and you try to rebuild.
"make depend" won't rebuild .depend because foo.c didn't
change, and "make all" will break because of a stale
dependency recorded in .depend (foo.o: bar.h).  I consider
NO_CLEAN builds to be safe only when sources do not change,
e.g., for incremental builds.  At the very minimum, when
sources change, .depend files should be regenerated.

> >I personally fail to see how this can be solved...  :-(
> 
> Ok, what about this:
> mkdep(1) creates lines of the form
> 
> 	foo.o: foo.c inc1.h inc2.h
> 
> Would this problem be solved if mkdep(1) created lines like:
> 
> 	foo.o .depend: foo.c inc1.h inc2.h
> 
> or equivalent?
> 
> Would something else break if we do that?
> 
I fail to see what this gives us, except for also breaking
"make .depend" when .depend is present and inc2.h disappears.


Cheers,
-- 
Ruslan Ermilov
ru at FreeBSD.org
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20050422/36c4f7af/attachment.bin