From: Sam Ravnborg <sam@ravnborg.org>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
LKML <linux-kernel@vger.kernel.org>,
jdike@addtoit.com
Subject: Re: asm-offsets.h is generated in the source tree
Date: Mon, 12 Sep 2005 21:15:25 +0200 [thread overview]
Message-ID: <20050912191525.GA13435@mars.ravnborg.org> (raw)
In-Reply-To: <20050911231601.GL25261@ZenIV.linux.org.uk>
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
next prev parent reply other threads:[~2005-09-12 19:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-10 15:20 asm-offsets.h is generated in the source tree Stephen Rothwell
2005-09-10 16:19 ` Sam Ravnborg
2005-09-11 2:32 ` Al Viro
2005-09-11 8:31 ` Sam Ravnborg
2005-09-11 15:45 ` Al Viro
2005-09-11 17:04 ` Sam Ravnborg
2005-09-11 21:29 ` Al Viro
2005-09-11 22:03 ` Sam Ravnborg
2005-09-11 23:16 ` Al Viro
2005-09-12 19:15 ` Sam Ravnborg [this message]
2005-09-13 6:30 ` Al Viro
2005-09-13 6:48 ` Kyle Moffett
2005-09-13 6:53 ` Keith Owens
2005-09-13 6:58 ` Kyle Moffett
2005-09-13 21:55 ` Al Viro
2005-09-15 1:07 ` Al Viro
2005-09-10 19:08 ` Sam Ravnborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050912191525.GA13435@mars.ravnborg.org \
--to=sam@ravnborg.org \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox