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
prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.