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

[Marcel Moolenaar]

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.

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

-- 
  Marcel Moolenaar         USPA: A-39004          marcel at xcllnt.net