On Mon, 25 Jun 2001 08:06:11 -0700,
Michael Elizabeth Chastain <[EMAIL PROTECTED]> wrote:
>Oof, both of you want to go first, and there are no "killer arguments"
>for which to prefer.
Yes there is. Eric is ready, I am not quite ready yet, I am still
fighting implicit dependencies. ESR goes first.
>esr> Fundamentally CML2 doesn't care where the input and output lives.
>esr> Input and output locations are specifiable on the command line with
>esr> defaults to the current directory.
>
>Keith, is this everything you need for split source and target?
>(Do you need multiple input locations?)
This is my problem to solve, using the same symlink technique as CML1.
Any CML language is allowed to assume that 'find' on the current "top
level" directory will find all the config files. If kbuild 2.5 has to
build a symlink forest to maintain that illusion, then so be it, it is
my problem.
>esr> Why do this inside CML2 rather than by macroexpansion in the makefile
>esr> command?
>
>I agree. If you have command line options, then that suffices.
Not for everything, which is why I create the symlink forest. Even if
you ignore multiple source trees, there is still the need to add
options to existing menus (and other config files) for third party
code.
Everybody patching the same menu does not work, it guarantees patch
failures. There is some code around that build up menus from
fragments, but it only works for menus and requires special code in
everything that reads the files, because the result must be synthesized
by every program.
kbuild 2.5 generalises that idea by looking for .prepend and .append
files which are prepended and appended to the corresponding base file.
It works for all files, not just menus. To do that *and* support
separate source and object directories, the resulting file must be
written in the object directory. So even without multiple source
trees, you can have config files in both the source and object
directories, CML must automatically find the correct version of each
file.
Solution: Create a forest of symlinks under the top level object
directory, pointing to each config file, providing a clean
environment for CML programs. No special code in any
programs[*], Makefile-2.5 handles everything.
Copy the input files such as .config, .config.old to the
forest as real files.
Run CMLx, it sees a single set of files and does its thing,
writing to the current directory.
Copy the output files such as .config to the relevant place
in the object directory.
[*] Actually I had to tweak scripts/kernel-doc to know about multiple
directories, because it can read any file. CML has a well defined
set of files so the symlink trick works.
"No problem is so big or so complicated that it cannot be solved by
another level of indirection".
Does anybody know where that quote comes from?
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/kbuild-devel
