Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Apr 2005 17:43:25 +1000 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Ruslan Ermilov <ru@FreeBSD.org>
Cc:        David O'Brien <obrien@FreeBSD.org>
Subject:   Re: cvs commit: src/sys/conf kmod.mk
Message-ID:  <20050421171036.Q2082@epsplex.bde.org>
In-Reply-To: <20050421070011.GA81229@ip.net.ua>
References:  <200504182110.j3ILAc8J031298@repoman.freebsd.org> <20050419182938.GA27941@dragon.NUXI.org> <20050420161212.GA52582@dragon.NUXI.org> <20050421070011.GA81229@ip.net.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 21 Apr 2005, Ruslan Ermilov wrote:

> On Thu, Apr 21, 2005 at 01:35:44PM +1000, Bruce Evans wrote:
>> On Wed, 20 Apr 2005, David O'Brien wrote:

>> If everything used ${DEPENDFILE} correctly, then "${DEPENDFILE}=.newdep
>> ${MAKE} _kernel-depend" should just work -- in particular, the old
>> dependencies shouldn't get in the way.
>>
> make(1) is who reads .depend, hence the added complexity.

I wasn't sure that it was that broken :-).  It defeats half the point of
having bsd.dep.mk to control things.

>>> I'm sitting in the kernel directory, I expect the ways of building
>>> modules to be as close to building the kernel (which is just a special
>>> .ko) as possible.
>>>
>>> We've never documented that 'make cleandepend' is nearly a required step
>>> for 'make depend' to be dependable.
>>
>> It is a bug that it is.  The bug is apparently that kmod.mk or possibly
>> bsd.dep.mk is missing the move-depend-file-out-of-the way code in the
>> above.
>>
> Speaking of kern.*.mk, I consider it a bug that "make depend" followed
> by "make depend" rebuilds the .depend file.  We need to decide if we
> want this behavior or not, and if we do, we should behave similarly
> in other places too, i.e., bsd.dep.mk.

The depend target doesn't, and possibly can't or shouldn't have enough
dependencies to know whether .depend should be rebuilt.  This is handled
in a different way in kernel makefiles.  Kernel makefiles always
rebuild, and application makefiles only rebuilt if one of the depended-on
files that they know about (mainly *.c) has changed.  I'm fairly happy
with this different behaviour.  The kernel is self-contained (at least
if you don't use the modules mistake), so it is easy to tell when its
.depend file should be rebuilt and avoid doing it unnecessarily, and
if you do it unnecessarily it only takes a short time to rebuild.  OTOH,
"make depend" for the src tree would rebuild hundreds of makefiles if
it always rebuilt.

Another dependency bug that sometimes bites me: "make" doesn't work
after "make clean", at least under the old version of -current that I
use, because dependencies for lots of generated sources (like device_if.c
(?)) are missing.  Dependencies for older generated files like
vnode_if.c are handled correctly, and "make depend" doesn't have
the problem because the necessary dependencies are in BEFORE_DEPEND.

> I proposed the following: with NO_CLEAN builds, default to always
> regenerating .depend files (by moving the old .depend files out of
> the way like is done in kern.post.mk), but provide a mean to skip
> regenerating .depend files, NO_CLEANDEPEND.

My version hasn't lost the support for not building .depend files
(which is just a pessimization on the !NOCLEAN^H^H^H^H^H_CLEAN case).
It has a knob _NODEPEND which is always set in the NOCLEAN case and
can be set by the user in the !NOCLEAN case to prevent building of
.depend files.  It removes old .depend files instead of moving them
out of the way as in bsd.prog.mk:

%%%
.if !defined(NOCLEAN)
_NODEPEND=	true
.endif
.if defined(_NODEPEND)
DEPEND=	cleandepend
.else
DEPEND=	depend
.endif
%%%

(Then s/depend/${DEPEND} almost everywhere else.)

I think the default for NOCLEAN should be to not rebuild dependencies.
It is supposed to be fast at the expense of correctness.  You often
want it to restart a build from where it failed, and then you don't
especially want it to rebuild all the makefiles before that point.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050421171036.Q2082>