linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: linux-sh@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-kbuild <linux-kbuild@vger.kernel.org>
Subject: Re: kill include symlinks for sh?
Date: Tue, 29 Jul 2008 17:54:40 +0900	[thread overview]
Message-ID: <20080729085440.GD29389@linux-sh.org> (raw)
In-Reply-To: <20080729064049.GA28656@uranus.ravnborg.org>

On Tue, Jul 29, 2008 at 08:40:49AM +0200, Sam Ravnborg wrote:
> Hi Paul
> 
> > This didn't end up being _too_ painful, though it did take a bit of time
> > to hunt down all of the guilty parties. I've pushed out what I have now,
> > which you can see at:
> > 
> > http://git.kernel.org/?p=linux/kernel/git/lethal/sh-2.6.git;a=commitdiff;h=f15cbe6f1a4b4d9df59142fc8e4abb973302cf44
> > 
> > It's been holding up to all of the random builds I've thrown at it so
> > far, so there shouldn't be any really nasty surprises left over.
> 
> I took a quick look at it and the header re-org looks good.
> I like that you added the 'mach-' prefix to the directory names.
> 
> But I also noticed several changes like this:
> -#include <asm/landisk/iodata_landisk.h>
> +#include <mach/iodata_landisk.h>
> 
> In this case you _know_ that this is a landisk so
> the less magic option would have been the longer
> include form like this:
> +#include <mach-landisk/mach/iodata_landisk.h>
> 
> It would be preferable that we use the gcc -I
> directive:
> 
>     -Iarch/sh/include/mach-$MACH
> 
> only to automagically select between identical named
> files for the different platforms and not like
> the above where we use it simply to cut off the include
> path a little.
> 
Yes, I had thought about that as well. We certainly need to go this route
if we are building multiple mach types at the same time. Fortunately the
vast majority of mach types do not have their own include structure, so
it's not been something that's popped up yet as a real problem.

> Another note is that you decided to move the generated
> file over to arch/sh/include too.
> I really do not know if I think this is the right approach.

This was before I realized that asm-offsets.h was being placed in
include/asm-sh anyways, despite the directory not existing until Kbuild
created it. I don't have any problems with moving it back, I just thought
the idea of multiple include directories for the same asm/ prefix seemed
non-intuitive.

      reply	other threads:[~2008-07-29  8:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-28 11:57 kill include symlinks for sh? Sam Ravnborg
2008-07-28 23:19 ` Paul Mundt
2008-07-29  6:40   ` Sam Ravnborg
2008-07-29  8:54     ` Paul Mundt [this message]

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=20080729085440.GD29389@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=sam@ravnborg.org \
    /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;
as well as URLs for NNTP newsgroup(s).