public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michal Marek <mmarek@suse.cz>
To: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH] kbuild: Use symbolic link to the source tree for out-of-tree build
Date: Tue, 05 Aug 2014 17:55:40 +0200	[thread overview]
Message-ID: <53E0FE7C.6030002@suse.cz> (raw)
In-Reply-To: <20140709182542.B0CB.AA925319@jp.panasonic.com>

On 2014-07-09 11:25, Masahiro Yamada wrote:
> Hi Michal,
> 
> 
> On Wed, 09 Jul 2014 10:59:59 +0200
> Michal Marek <mmarek@suse.cz> wrote:
> 
>> On 2014-07-09 08:27, Masahiro Yamada wrote:
>>> Since commit 9da0763bd, the variable 'srctree' is set as follows:
>>>
>>> [1] Building in the source tree
>>>       => srctree is set to '.'
>>> [2] Building in a subdir right under the source tree
>>>       => srctree is set to '..'
>>> [3] Other cases
>>>       => srctree is set to the absolute path to the source tree
>>>
>>> Pros are more readable compiler messages, WARN_ON() etc.
>>> for case [1] and [2]. (but not [3])
>>>
>>> Cons are we have to do build-test for 3 cases when adding
>>> some changes to the build infrastructure.
>>>
>>> We want to treat case [2] and [3] in the same way like prior to
>>> commit 9da0763bd, keeping the compact log messages.
>>>
>>> The idea here is to create a symbolic link 'srctree' pointing
>>> to $(KBUILD_SRC) at the very early stage of the build process.
>>
>> If the symlink points to an absolute path, then you can't move the
>> source and build tree around anymore.
> 
> 
> In which cases do we need to do this?

Sorry for the late response.

You might want to nfs-export the build and source tree and mount it on a
different machine. Up to 3.16, one had to make sure that the paths match
on both machines. 3.16 removes this limitation.


> Anyway, even if we move the source and build tree around,
> it is much faster to rebuild it.
> 
> The point here is that the absolute paths do not appear
> in .*.cmd files.

If you either do not use O= or use O=<subdir>, then there won't be any
absolute paths either. It could be extended to handle
O=subdir1/subdir1/... if needed.


> For example,
> 
> $ make O=foo/bar defconfig all
>   [ full build ]
> $ cd ..
> $ mkdir baz
> $ move linux baz
> $ cd baz/linux
> $ make O=foo/bar
>   [ much faster re-build ]

I now noticed that the patch unconditionally recreates the symlink on
every make O= invocation. While this nicely fixes the problem with moved
build directory, it also means that a 'make O=... modules_install' ran
as root will try to recreate the symlink. This will fail on nfs. So I'd
rather keep the current logic with $(SRCTREE) containing either an
absolute or relative path.

Michal

      reply	other threads:[~2014-08-05 15:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-09  6:27 [PATCH] kbuild: Use symbolic link to the source tree for out-of-tree build Masahiro Yamada
2014-07-09  8:59 ` Michal Marek
2014-07-09  9:25   ` Masahiro Yamada
2014-08-05 15:55     ` Michal Marek [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=53E0FE7C.6030002@suse.cz \
    --to=mmarek@suse.cz \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    --cc=yamada.m@jp.panasonic.com \
    /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