Date: Thu, 21 Apr 2005 21:59:25 +0300 From: Ruslan Ermilov <ru@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: David O'Brien <obrien@FreeBSD.org> Subject: Re: cvs commit: src/sys/conf kmod.mk Message-ID: <20050421185925.GA85015@ip.net.ua> In-Reply-To: <20050421171036.Q2082@epsplex.bde.org> References: <200504182110.j3ILAc8J031298@repoman.freebsd.org> <20050418.152011.74745144.imp@bsdimp.com> <20050419182938.GA27941@dragon.NUXI.org> <20050420055904.GA33015@ip.net.ua> <20050420161212.GA52582@dragon.NUXI.org> <20050421125501.W88810@delplex.bde.org> <20050421070011.GA81229@ip.net.ua> <20050421171036.Q2082@epsplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On Thu, Apr 21, 2005 at 05:43:25PM +1000, Bruce Evans wrote:
> 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.
>
That's where we have a problem -- some of us are happy with the
behavior, some of us want all be similar, and some of us don't
like it. (I don't.)
> 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.
>
Short time -- maybe. I still consider it a major mistake that
"make depend" followed by "make depend" does something -- it
shouldn't.
> OTOH,
> "make depend" for the src tree would rebuild hundreds of makefiles if
> it always rebuilt.
>
Of .depend files, yes. This is evil.
> 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.
>
Maybe this is only an old bug, as there are these lines in kern.post.mk:
.if !exists(${.OBJDIR}/.depend)
${SYSTEM_OBJS}: assym.s vnode_if.h ${BEFORE_DEPEND:M*.h} ${MFILES:T:S/.m$/.h/}
.endif
At least "make -n kernel >/dev/null" after "make clean" doesn't
complain now.
> >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.
>
So do I, but I also want it to be a case for the kernel build.
> 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.
>
Yes, agreed. In case of upgrades, it's easy to "make cleandepend"
first.
Cheers,
--
Ruslan Ermilov
ru@FreeBSD.org
FreeBSD committer
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQFCZ/gNqRfpzJluFF4RAicWAKCKZGpcks32Dp42l4tCI8qcVdGi3gCdEZtT
Jyhydp8NQ1sRdGnXBFBzEvo=
=JsRy
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050421185925.GA85015>