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

[Sam Ravnborg <sam@ravnborg.org>]

Hi Al. 
 
> See what I mean?  _IF_ we just wanted subarch foo.h, your scheme would
> work.  If we wanted subarch-dependent header that would be pulled by
> foo.h - ditto (sysdep/blah.h from foo.h).  But we can't do that when
> we want #include <asm/foo.h> (from arch-independent code) pull some
> UML stuff *and* asm/foo.h of subarch.
> 
> That's the problem.  Everything else is reasonably easy to deal with.
> That one is not.  And yes, I know about #include_next.  I'd rather
> stick to C, though, TYVM...
> 
I got the picture. And you are right that there is no way to sort this
out with a clever directory structure and a few -I options.
The only two solutions I see you already pointed out:

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

Of the three possibilities the include_next is the better chocie. Why?
Because we leave it to the build system to figure out what .h file to
include, and thus letting the build system having full knowledge we make
sure to recompile whatever is needed when we change subarch.
Without the asm symlink in the kernel it would just work in many cases
when you changed architecture.

So to repaet. symlinks are evil when used to in sources.

	Sam

-
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/