Message ID | 20231215160637.842748-1-masahiroy@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-1256-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:3b04:b0:fb:cd0c:d3e with SMTP id c4csp9385999dys; Fri, 15 Dec 2023 08:07:18 -0800 (PST) X-Google-Smtp-Source: AGHT+IEo0iYivOn+Ug6nmfaBg9jr6qPmbNgEKefqQbKsS5gAV5ULA5/31IeCESdBV+V5FefTuB3n X-Received: by 2002:a7b:ce0f:0:b0:402:f501:447c with SMTP id m15-20020a7bce0f000000b00402f501447cmr7024777wmc.0.1702656438393; Fri, 15 Dec 2023 08:07:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702656438; cv=none; d=google.com; s=arc-20160816; b=sT/zDX/76FCyLkqbhNFfTcO5rSPj0odV4xLY95GiF1OanhZ2HKXS06wXzJe+ifIlm7 dXmGz1H3zh2PhJCGPrx2rclu7berSEla8GQQpeEasjPyLVxGOHW2Bx6hXJff1/jCaBbY RzMWCwAwkMpUY+T2WMhDMfeSmzmx0GzwnOO02cBgpLn7fT7KJ6SJqbNBH0IT2OYDk1WU UqUDSuDZUE5gUJ/3NmOr1RaxbxsP650NfNKYnfPm5fbivDiM6PztS4mDnI3yzltxpZzZ BeQ3AKTvkoGRvRss6qdBLFswOYxk91TOFSGqtyfUu6hUW8B6hdI+wmgfD4K4iVfgshpa tg0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=FJ4AH41srdYPpS9GYHI5JINjtAC0dLYl0Y8MbEtPyAw=; fh=7DXO8kht7/M/A+2KL5ICS5xUlSmdB7vGPUmm3kZJ8r0=; b=bTltQuln9jve0Lx2mHRyoNuKwOeeD/qLOQEAic/aIgJCVpJopNg+TiCX6PYjtoYpas acnza0wySs++3B5oOg2mZKy/V+pR0uNoAfIXQo4WzlJVGl1cHe/wScZMS1/OD2b3uk7P 9847vRCWZbIs4aPEeprKptsAG9V2mQPuf1aNhiZmKRB1MLRV3PU4lTSLhnMm33FUF1OF eYdhk/0pK2NMcZlKb98CvNdgnkarFEMoFqVL5VzlErqKy9X6sVeNB9wd6yUTXeKjLhZC CVcmbxmB/vJzHvN1iB42lI2X4C2NZnB9ZO5tEDIxA+IA0Hp3umF6bBifFQUpeE5VWVKF 8/gg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=CSxq79aV; spf=pass (google.com: domain of linux-kernel+bounces-1256-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-1256-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id gf22-20020a170906e21600b00a1c8f7e79fasi7912150ejb.910.2023.12.15.08.07.18 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Dec 2023 08:07:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-1256-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=CSxq79aV; spf=pass (google.com: domain of linux-kernel+bounces-1256-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-1256-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 056E61F25043 for <ouuuleilei@gmail.com>; Fri, 15 Dec 2023 16:07:18 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3D4AD3C48F; Fri, 15 Dec 2023 16:06:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CSxq79aV" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF7723BB2E; Fri, 15 Dec 2023 16:06:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE743C433C8; Fri, 15 Dec 2023 16:06:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702656406; bh=bGtK0d0oGVloKhV2jX7EqKBQotgvfSWouc8MLPevJ8g=; h=From:To:Cc:Subject:Date:From; b=CSxq79aVTkHfAnmg4GRqhIqSUyMRhFOIotw6KZKB7Grp2lZuKrogdZ4Uf4yo1oNmz wKH9ZExCzK+Q9E6MNhtjF3rOyubzPyzqEgOgWhmig5Bw84UGa2/B5McIx0lvLlNanN fmya/2EplByqXShNMA5yE9lq1AUYef94gS8eG8dobCkAsAyzociRZnmwjRcvWYgysZ UJnLz8ju0FhgmJ5IofXZyMyZKnpGSUeZOMwnksFBdrJ4ZQRDzJDA5DKf5QR3w6r95w h4Xza+g+dt+kmORiNhg/pn9rsXT7Y7OMMLda0Fp2COHmgH67fU9ZSfIkQfE3kgPBAu meMPLSGoBO7Jw== From: Masahiro Yamada <masahiroy@kernel.org> To: linux-kbuild@vger.kernel.org Cc: Masahiro Yamada <masahiroy@kernel.org>, Nicolas Schier <n.schier@avm.de>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Nicolas Schier <nicolas@fjasle.eu>, linux-kernel@vger.kernel.org Subject: [PATCH v2] kbuild: resolve symlinks for O= properly Date: Sat, 16 Dec 2023 01:06:37 +0900 Message-Id: <20231215160637.842748-1-masahiroy@kernel.org> X-Mailer: git-send-email 2.40.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785266288269934061 X-GMAIL-MSGID: 1785364677678879250 |
Series |
[v2] kbuild: resolve symlinks for O= properly
|
|
Commit Message
Masahiro Yamada
Dec. 15, 2023, 4:06 p.m. UTC
Currently, Kbuild follows the logical chain of directories for the O= option, just like 'cd' (or 'realpath --logical') does. Example: $ mkdir -p /tmp/a /tmp/x/y $ ln -s /tmp/x/y /tmp/a/b $ realpath /tmp/a/b/.. /tmp/x $ realpath --logical /tmp/a/b/.. /tmp/a $ make O=/tmp/a/b/.. defconfig make[1]: Entering directory '/tmp/a' [snip] make[1]: Leaving directory '/tmp/a' 'make O=/tmp/a/b/.. defconfig' creates the kernel configuration in /tmp/a instead of /tmp/x despite /tmp/a/b/.. resolves to the physical directory path /tmp/x. This is because Kbuild internally uses the 'cd ... && pwd' for the path resolution, but this behavior is not predictable for users. Additionally, it is not consistent with how the Kbuild handles the M= option or GNU Make works with 'make -C /tmp/a/b/..'. Using the physical directory structure for the O= option seems more reasonable. The comment says "expand a shell special character '~'", but it has already been expanded to the home directory in the command line. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de> --- Changes in v2: - Quote $(KBUILD_OUTPUT). If ~ is contained in KBUILD_OUTPUT, it should not expanded any further. Makefile | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-)
Comments
On 2023-12-16 01:06:37 [+0900], Masahiro Yamada wrote: … > Using the physical directory structure for the O= option seems more > reasonable. > > The comment says "expand a shell special character '~'", but it has > already been expanded to the home directory in the command line. It might have been expanded, it might have not been expanded. Having a shell script: | #!/bin/sh | | exec make O=~/scratch/mk-check defconfig with bin/sh = dash results in: | make[1]: Entering directory '/home/bigeasy/linux/~/scratch/mk-check' while bin/sh = bash expands the ~ properly before for O=. Would it be too much to ask, to expand the ~? Sebastian
On Mon, Jan 22, 2024 at 03:12:03PM +0100, Sebastian Andrzej Siewior wrote: > On 2023-12-16 01:06:37 [+0900], Masahiro Yamada wrote: > … > > Using the physical directory structure for the O= option seems more > > reasonable. > > > > The comment says "expand a shell special character '~'", but it has > > already been expanded to the home directory in the command line. > > It might have been expanded, it might have not been expanded. Having a > shell script: > | #!/bin/sh > | > | exec make O=~/scratch/mk-check defconfig > > with bin/sh = dash results in: > > | make[1]: Entering directory '/home/bigeasy/linux/~/scratch/mk-check' > > while bin/sh = bash expands the ~ properly before for O=. Would it be > too much to ask, to expand the ~? Expanding tilde expandos is traditionally a shell feature, as you already mentioned; and bash supports also expandos like '~+' and '~-'. I think, we should leave the shell things in shells. Thus, please update your shell scripts to be compliant to their interpreting shell (e.g. use '$HOME' or switch the shell). Kind regards, Nicolas
On 2024-01-22 15:59:37 [+0100], Nicolas Schier wrote: > Expanding tilde expandos is traditionally a shell feature, as you > already mentioned; and bash supports also expandos like '~+' and '~-'. > I think, we should leave the shell things in shells. > > Thus, please update your shell scripts to be compliant to their > interpreting shell (e.g. use '$HOME' or switch the shell). I reported that this change silently broke dash users. If you accept this then you could acknowledge it instead of suggesting workarounds. > Kind regards, > Nicolas Sebastian
On Mon, Jan 22, 2024 at 04:05:01PM +0100, Sebastian Andrzej Siewior wrote: > On 2024-01-22 15:59:37 [+0100], Nicolas Schier wrote: > > Expanding tilde expandos is traditionally a shell feature, as you > > already mentioned; and bash supports also expandos like '~+' and '~-'. > > I think, we should leave the shell things in shells. > > > > Thus, please update your shell scripts to be compliant to their > > interpreting shell (e.g. use '$HOME' or switch the shell). > > I reported that this change silently broke dash users. If you accept > this then you could acknowledge it instead of suggesting workarounds. I'm sorry, I didn't mean to upset you. Yes, we were aware that the change breaks some usage patterns. Thanks for pointing that out. Kind regards, Nicolas
From: Sebastian Andrzej Siewior > Sent: 22 January 2024 14:12 > > On 2023-12-16 01:06:37 [+0900], Masahiro Yamada wrote: > … > > Using the physical directory structure for the O= option seems more > > reasonable. > > > > The comment says "expand a shell special character '~'", but it has > > already been expanded to the home directory in the command line. > > It might have been expanded, it might have not been expanded. Having a > shell script: > | #!/bin/sh > | > | exec make O=~/scratch/mk-check defconfig > > with bin/sh = dash results in: > > | make[1]: Entering directory '/home/bigeasy/linux/~/scratch/mk-check' > > while bin/sh = bash expands the ~ properly before for O=. Would it be > too much to ask, to expand the ~? Raise a bug on dash... Or split the lines: O=~/xxxx make O="$O" ... David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Mon, Jan 22, 2024 at 11:12 PM Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote: > > On 2023-12-16 01:06:37 [+0900], Masahiro Yamada wrote: > … > > Using the physical directory structure for the O= option seems more > > reasonable. > > > > The comment says "expand a shell special character '~'", but it has > > already been expanded to the home directory in the command line. > > It might have been expanded, it might have not been expanded. Having a > shell script: > | #!/bin/sh > | > | exec make O=~/scratch/mk-check defconfig > > with bin/sh = dash results in: > > | make[1]: Entering directory '/home/bigeasy/linux/~/scratch/mk-check' > > while bin/sh = bash expands the ~ properly before for O=. Would it be > too much to ask, to expand the ~? Not only O=. If the shell does not expand the '~' character, there are more variables that do not work as expected. For example, $ make CROSS_COMPILE=~/path/to/compiler/dir $ make M=~/path/to/external/module/dir' It is strange to require only O= to expand the '~' character. So, Kbuild should be agnostic about '~'. This is consistent. > > Sebastian >
diff --git a/Makefile b/Makefile index 04a86c81b5c0..5036edc40f46 100644 --- a/Makefile +++ b/Makefile @@ -190,14 +190,11 @@ ifeq ("$(origin O)", "command line") endif ifneq ($(KBUILD_OUTPUT),) -# Make's built-in functions such as $(abspath ...), $(realpath ...) cannot -# expand a shell special character '~'. We use a somewhat tedious way here. -abs_objtree := $(shell mkdir -p $(KBUILD_OUTPUT) && cd $(KBUILD_OUTPUT) && pwd) -$(if $(abs_objtree),, \ - $(error failed to create output directory "$(KBUILD_OUTPUT)")) - +# $(realpath ...) gets empty if the path does not exist. Run 'mkdir -p' first. +$(shell mkdir -p "$(KBUILD_OUTPUT)") # $(realpath ...) resolves symlinks -abs_objtree := $(realpath $(abs_objtree)) +abs_objtree := $(realpath $(KBUILD_OUTPUT)) +$(if $(abs_objtree),,$(error failed to create output directory "$(KBUILD_OUTPUT)")) endif # ifneq ($(KBUILD_OUTPUT),) ifneq ($(words $(subst :, ,$(abs_srctree))), 1)