Re: asm-offsets.h is generated in the source tree

[Al Viro <viro@ZenIV.linux.org.uk>]

On Mon, Sep 12, 2005 at 09:15:25PM +0200, Sam Ravnborg wrote:
> o Use symlinks
>   - With all their horror they do the job.
>   - The need special care with make O=
>   - We fail to detect when the point somewhere else, so make mrproper
>     is needed.
>   - They confuse people
>     
> o include_next
>   - gcc extension
>   - Give us correct dependencies
>   - Signal that something fishy is going on
> 
> o Use some magic define trick like:
>   - #include "ARCHDIR##foo.h"
>   - I cannot recall correct syntax but something like this is doable

* Provide a function that would
	take target of form <directory>/.<link>
	create a symlink at <directory>/<link> to argument of function,
doing obvious changes for O=
	touch the target

That would turn e.g. arm/Makefile rule into

include/asm-arm/.arch: $(wildcard include/config/arch/*.h) include/config/MARKER
	$(call symlink, arch-$(incdir-y))

with all the guts handled by the function in question.  For O= build you'd
get
	include/asm-arm created if needed
	include/asm-arm/arch -> $(srctree)/include/asm-arm/arch-....
and for normal one
	include/asm-arm/arch -> arch-....
In either case include/asm-arm/.arch is touched and depends on the right
config options.  Same for include/asm-sh/cpu and include/asm-sh/mach,
etc.

The only case not handled by that scheme is when we create a symlink and
then create files in its target.  Which, AFAICS, is the case only for
include/asm - UML used to need that for arch/um/include/sysdep, but doesn't
anymore (as the matter of fact, arch/um/include2/ is gone in my tree).

The reason why include_next blows is very simple: OK, so make can figure
out what we mean.  But make is not the only thing that has to understand
which file is refered to - people writing and reviewing code need the same
and having to figure out what exactly do we have in search path is asking
for trouble.  With symlinks (or bindings, etc.) you have #include argument
that doesn't need that sort of lookups - <asm/arch/foo.h> is visibly
different from <asm/foo.h> and one can immediately see what it's about.

IOW, playing tricks with search paths becomes wrong as soon as it becomes
something you have to keep in mind while reading kernel code itself.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/