[Keith Owens]
> prepend/append are logical wrappers, the order is prepend top to
> bottom, base file, append bottom to top. This must be done over all
> source trees.
I think my hack wrapper does that already.
> prepend/append entries in shadow trees below the base version of a
> file must be ignored.
I had that wrong but it is trivially fixable. In fact, doing so
simplifies the script somewhat.
> This script will not automatically cope with files or source trees
> being added or deleted.
That is true. It also doesn't cope with the ${KBUILD_*TREE*}
variables being changed after the initial run.
Which isn't to say you couldn't add such a command to the toplevel
Makefile to be run before every build, similar to what kbuild25 does
in the absense of NO_MAKEFILE_GEN.
> Relying on end users to know when to run manual commands is
> unacceptable, kbuild must automatically detect changes that affect
> the kernel.
End users don't use shadow trees. Developers do. Unless kernel
patches are now being distributed as shadow tarballs instead of patch
files, which AFAICT is not by any means the common case.
Developers should know when to rerun the hypothetical 'make forest'.
If not, it could be automated by $(TOPDIR)/Makefile, see above.
One problem with putting a hack script in $(TOPDIR)/Makefile is that
it causes spurious rebuilds, since it always regenerates from *.*pend
files even when they haven't changed.
> The killer: changing the set of source trees or a file in a source
> tree introduces timestamp skew that make cannot cope with.
This is true. This is a showstopper. From a correctness standpoint,
there is no easy way to solve this problem - if one expects to be able
to add / remove shadow trees "at runtime", one must accept either
running a lengthy (slow) script at that time, or move to kbuild25
where such a thing was explicitly designed for.
> BTW, shadow trees do not "clutter" up kbuild 2.5. The hard part was
> separating source and object and tracking timestamp skew correctly.
Hmmm, depends on perspective. Separate source / object is not hard -
many projects can trivially achieve that with VPATH and a little care.
Of your four sources of timestamp skew, one of these was created by
shadow trees, so it's a problem you had to solve anyway. In the
absense of shadow trees, the other three causes of skew are well known
and with a bit of care can often be ignored. (In fact, ntp can be
used to mitigate nfs, and I believe modern ntpds only skew the clock a
few milliseconds at a time, which is a pretty fast edit / compile /
run cycle if you think about it. As for SCMs, someone claimed that
CVS set times backwards but that is only true on initial checkout,
whereas update is the case where you'd care about this.)
Summary: without shadow trees, the timestamp skew problem almost goes
away anyway, even though theoretically there *are* other sources of
it.
> Going from one directory to two was hard, going from two to many was
> easy.
I'll buy that statement if you mean going from one *source* directory
to two. Remember, though, the feature everyone seems to want is to
have one source directory and one object directory. By all
appearances that really *is* a significantly easier problem.
(Even the -I thing you mention in the next message. Very seldom do
you need access to generated files in custom include directories other
than $PWD.)
Peter
-------------------------------------------------------
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
