Message ID | 20230509012616.81579-2-darwi@linutronix.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2550911vqo; Mon, 8 May 2023 18:32:24 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5H1ZHkCTlos4iOm9tDwV7fRApXlBQYsrMrCGaqi9xvdWPHqnApbMRiLoJtwM0U7t6vMC6E X-Received: by 2002:a17:90a:e50d:b0:247:6a31:d59d with SMTP id t13-20020a17090ae50d00b002476a31d59dmr12235498pjy.1.1683595944311; Mon, 08 May 2023 18:32:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683595944; cv=none; d=google.com; s=arc-20160816; b=eiN8GD+ekCvRd8j3BA1EQ710ku6b0Y240mMmqnhibqy/PVNK1JqyBCH84jR7X9j9P9 tqcFfBpK304GS63pd+BDmmKF6Wz2Q2pLf80w2hByHdunkhSQHn+eyHdgcvj18CYJq23f 1UE1a58egSgTbwif77WMTLvMELxma2Vl6Y87cdmghJ2HpLOCOG7WElQBeqRQwkrJbLfr wMUredgWSlBHbiqp4ZaAI5cxJoSDdAjwees5z0UA5vOUnnZIsC75u4xaWDtg6kw6aHG2 wJivYnYO3putN4Qrj2xOiDNS6mcICdDkvqcq711lJQYSTXn8XpV3TFtWtgu7gFgPL/hw 5L9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:dkim-signature :dkim-signature:from; bh=uStzLe1tmofW57614nQAyaAY3eSlDqWR3vQxVmQVS1Y=; b=RePxUDPjmV9OTEjo17xU7AmXZ88QkhJ0ZsmFiLELFPfYjJEoXGeKgGt9cLF31kFScH n5VaTeD64jUL8mPFuUu8KxOUhcDe5KuAKKER4ZzX1F6glpfuVdQu0iAYsCY6ZmDS1/y/ HGfjzpAwMyfKU/3BgDFlRqcoX2UhUAn6Lrv6+icu8Jo92kudLWLzWQ5IOY3bA5dcYts4 oqrMxN/B6Gmh6I23RJhqAYsXpfFGgf3GipDYt6G7wpeV5kaFyo6LOB/87HM/S+epISlB +Y6YPTep4prm3CWGMaKml5IpoS+bBkPVaEtzhhdp5tjs7Gg7bPDDVraUayZIdwQAgBVd uHZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=xWNjFDl1; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=WJiot4UY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e5-20020a63aa05000000b00528595a1390si302268pgf.588.2023.05.08.18.32.12; Mon, 08 May 2023 18:32:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=xWNjFDl1; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b=WJiot4UY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233109AbjEIB0s (ORCPT <rfc822;jeantsuru.cumc.mandola@gmail.com> + 99 others); Mon, 8 May 2023 21:26:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60116 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233265AbjEIB0n (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 8 May 2023 21:26:43 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ACAE0903C; Mon, 8 May 2023 18:26:39 -0700 (PDT) From: "Ahmed S. Darwish" <darwi@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1683595598; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uStzLe1tmofW57614nQAyaAY3eSlDqWR3vQxVmQVS1Y=; b=xWNjFDl1s1ucegfBKQoncawd3d6If9tExr6i3v7IB0erVNUwt3jWQ6xpT9t2axmBV47Egz Qzzf/6eG0TQWoOSYHLyK98dgGPoWq8ZPdbKnLBF+bFMDkBIgUD80KfV3P4fHDLcVFEmJ1Q HKAZoci+2bpbtZ1iv9kQZ1koL34GE6y4AbhhEK5SRuKp1S60+KjRB4v/8MHrfVlyzt/aOm ewEZc6123SiU/pGCMhBFSqfDRsFxyVECyL0IWFbGbVRWNXoAghfj67OM2jzDVwAQAmoiQ0 hUyDmEWmdirizxsc1O1FFxo+AItwBn1ssPhe+phW2iue7vCxNDt/PUrrF1BIfg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1683595598; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uStzLe1tmofW57614nQAyaAY3eSlDqWR3vQxVmQVS1Y=; b=WJiot4UYEtS47knJadY85GFMDZjw4ZAVKGi64k8JHj3oZMySdSuYS/Vb8RZso5Gw1ThPCM 4eHRjiXqk7nTejDw== To: Masahiro Yamada <masahiroy@kernel.org>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Nicolas Schier <nicolas@fjasle.eu> Cc: Thomas Gleixner <tglx@linutronix.de>, linux-kbuild@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>, "Ahmed S. Darwish" <darwi@linutronix.de> Subject: [PATCH v2 1/2] scripts/tags.sh: Resolve gtags empty index generation Date: Tue, 9 May 2023 03:26:15 +0200 Message-Id: <20230509012616.81579-2-darwi@linutronix.de> In-Reply-To: <20230509012616.81579-1-darwi@linutronix.de> References: <20230504201833.202494-1-darwi@linutronix.de> <20230509012616.81579-1-darwi@linutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1765378300728517582?= X-GMAIL-MSGID: =?utf-8?q?1765378300728517582?= |
Series |
scripts: Resolve gtags empty index generation
|
|
Commit Message
Ahmed S. Darwish
May 9, 2023, 1:26 a.m. UTC
gtags considers any file outside of its current working directory
"outside the source tree" and refuses to index it. For O= kernel builds,
or when "make" is invoked from a directory other then the kernel source
tree, gtags ignores the entire kernel source and generates an empty
index.
Force-set gtags current working directory to the kernel source tree.
Due to commit 9da0763bdd82 ("kbuild: Use relative path when building in
a subdir of the source tree"), if the kernel build is done in a
sub-directory of the kernel source tree, the kernel Makefile will set
the kernel's $srctree to ".." for shorter compile-time and run-time
warnings. Consequently, the list of files to be indexed will be in the
"../*" form, rendering all such paths invalid once gtags switches to the
kernel source tree as its current working directory.
If gtags indexing is requested and the build directory is not the kernel
source tree, index all files in absolute-path form.
Note, indexing in absolute-path form will not affect the generated
index, as paths in gtags indices are always relative to the gtags "root
directory" (as evidenced by "gtags --dump").
Signed-off-by: Ahmed S. Darwish <darwi@linutronix.de>
Cc: <stable@vger.kernel.org>
---
scripts/tags.sh | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
Comments
On Tue, May 9, 2023 at 10:26 AM Ahmed S. Darwish <darwi@linutronix.de> wrote: > > gtags considers any file outside of its current working directory > "outside the source tree" and refuses to index it. For O= kernel builds, > or when "make" is invoked from a directory other then the kernel source > tree, gtags ignores the entire kernel source and generates an empty > index. > > Force-set gtags current working directory to the kernel source tree. > > Due to commit 9da0763bdd82 ("kbuild: Use relative path when building in > a subdir of the source tree"), if the kernel build is done in a > sub-directory of the kernel source tree, the kernel Makefile will set > the kernel's $srctree to ".." for shorter compile-time and run-time > warnings. Consequently, the list of files to be indexed will be in the > "../*" form, rendering all such paths invalid once gtags switches to the > kernel source tree as its current working directory. > > If gtags indexing is requested and the build directory is not the kernel > source tree, index all files in absolute-path form. > > Note, indexing in absolute-path form will not affect the generated > index, as paths in gtags indices are always relative to the gtags "root > directory" (as evidenced by "gtags --dump"). The code works as claimed, but I am just curious. If all the paths are relative, how can you use the tags files located in a separate directory? "make O=foo gtags" creates tags files in foo/. I want to use them from emacs. emacs cannot find the right file because it assumes the path is relative to 'foo' instead of the source tree. I set GTAGSROOT to the source tree, but I could not find a way to use it in a useful way. > diff --git a/scripts/tags.sh b/scripts/tags.sh > index ea31640b2671..3de4b4ebd891 100755 > --- a/scripts/tags.sh > +++ b/scripts/tags.sh > @@ -32,6 +32,14 @@ else > tree=${srctree}/ > fi > > + Unneeded empty line addition. > +# gtags(1) refuses to index any file outside of its current working dir. > +# If gtags indexing is requested and the build output directory is not > +# the kernel source tree, index all files in absolute-path form. > +if [ "$1" = "gtags" -a -n "${tree}" ]; then > + tree=$(realpath $tree)/ I decided to run shellcheck for new code. Please follow the suggestion from the tool. In scripts/tags.sh line 40: tree=$(realpath $tree)/ ^---^ SC2086 (info): Double quote to prevent globbing and word splitting. Did you mean: tree=$(realpath "$tree")/ (You do not need to fix the entire script. This is only for new code). > @@ -131,7 +139,11 @@ docscope() > > dogtags() > { > - all_target_sources | gtags -i -f - > + local gtagsoutdir="${PWD}" > + local gtagsroot="${tree}" > + > + [ -z "${gtagsroot}" ] && gtagsroot="." > + all_target_sources | gtags -i -C $gtagsroot -f - $gtagsoutdir > } You can write it in one line. dogtags() { all_target_sources | gtags -i -C "${tree:-.}" -f - "${PWD}" } -- Best Regards Masahiro Yamada
On Fri, 12 May 2023, Masahiro Yamada wrote: > > The code works as claimed, but I am just curious. Thanks. > If all the paths are relative, how can you use the tags files located > in a separate directory? > > "make O=foo gtags" creates tags files in foo/. > I want to use them from emacs. > emacs cannot find the right file because > it assumes the path is relative to 'foo' instead of the source tree. > Correct. In theory, since all the indexed linux source tree paths at the gtags generated files (GPATH/GRTAGS/GTAGS) are relative to the linux source tree root, opening such files from emacs ggtags-mode, *wherever* these files are, "should" work. In practice, ggtags/global (and thus also emacs ggtags-mode) operate with a model of the world where all indexed files must be under the source "root directory". So, the GPATH/GRTAGS/GTAGS files are expected to be under the source tree (except in special GTAGSLIBPATH= cases). > I set GTAGSROOT to the source tree, but I could not find a way > to use it in a useful way. Yes, that won't work, as emacs will search for the G* database files under that folder instead. Meanwhile setting GTAGSROOT to the O= directory, or to a build directory that is different from the kernel source tree, as in: cd ~/linux O=~/build/build-linux-x86 make O=$O x86_64_defconfig make O=$O gtags GTAGSROOT=$O emacs init/main.c will "mostly" succeed (as you hinted at): M-x ggtags-mode # emacs finds gtags files under ${GTAGSROOT} and sets ${GTAGSROOT} as # the root of the project M-x ggtags-find-definition Definition: rcu_read_lock -*- mode: ggtags-global; default-directory: "~/build/build-linux-x86/" -*- Global started at Mon May 15 15:54:01 global -v --result=grep --color=always --path-style=shorter -- rcu_read_lock include/linux/rcupdate.h:769:static __always_inline void rcu_read_lock(void) 1 object located (using '/home/darwi/build/build-linux-x86/GTAGS'). Global found 1 definition at Mon May 15 15:54:01 # Prompt Find this match in (default include/linux/rcupdate.h)?: ~/build/build-linux-x86/ ^^^ But at the Prompt step above, things break. In a fully working setup, this prompt will not be shown and emacs just jumps to rcuupdate.h line 769. What I personally do to mitigate that problem is: cd ~/linux for f in GTAGS GRTAGS GPATH; do ln -vsf ${O}/$f . done and switch these symlinks through minor local shell plumbing whenever I'm switching kernel projects with different build directories. It is not ideal, but maybe we can discuss this with the global(1) people at a later step. At least with this patch series, "make O=xyz/ gtags" produces a valid index. > > > +# gtags(1) refuses to index any file outside of its current working dir. > > +# If gtags indexing is requested and the build output directory is not > > +# the kernel source tree, index all files in absolute-path form. > > +if [ "$1" = "gtags" -a -n "${tree}" ]; then > > + tree=$(realpath $tree)/ > > I decided to run shellcheck for new code. > Please follow the suggestion from the tool. > > In scripts/tags.sh line 40: > tree=$(realpath $tree)/ > ^---^ SC2086 (info): Double quote to prevent > globbing and word splitting. > > Did you mean: > tree=$(realpath "$tree")/ > > (You do not need to fix the entire script. > This is only for new code). > Yes, the reason was to following the existing coding pattern at scripts/tags.sh. But, sure, will do. > > > @@ -131,7 +139,11 @@ docscope() > > > > dogtags() > > { > > - all_target_sources | gtags -i -f - > > + local gtagsoutdir="${PWD}" > > + local gtagsroot="${tree}" > > + > > + [ -z "${gtagsroot}" ] && gtagsroot="." > > + all_target_sources | gtags -i -C $gtagsroot -f - $gtagsoutdir > > } > > You can write it in one line. > > dogtags() > { > all_target_sources | gtags -i -C "${tree:-.}" -f - "${PWD}" > } > Ditto. The script was almost-fully POSIX style (except the first line), so I avoided bash features on purpose. I personlly always prefer using Bash features though, so I'll definitely update the code. Thanks a lot for the review. I'll send a v3. -- Ahmed S. Darwish Linutronix GmbH
On Mon, 15 May 2023, Ahmed S. Darwish wrote: > On Fri, 12 May 2023, Masahiro Yamada wrote: > > > > You can write it in one line. > > > > dogtags() > > { > > all_target_sources | gtags -i -C "${tree:-.}" -f - "${PWD}" > > } > > > > Ditto. The script was almost-fully POSIX style (except the first line), > so I avoided bash features on purpose. > Nitpick for correctness sake the "Use default values" parameter expansion is actually POSIX-ly correct: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02 Thanks, Ahmed
diff --git a/scripts/tags.sh b/scripts/tags.sh index ea31640b2671..3de4b4ebd891 100755 --- a/scripts/tags.sh +++ b/scripts/tags.sh @@ -32,6 +32,14 @@ else tree=${srctree}/ fi + +# gtags(1) refuses to index any file outside of its current working dir. +# If gtags indexing is requested and the build output directory is not +# the kernel source tree, index all files in absolute-path form. +if [ "$1" = "gtags" -a -n "${tree}" ]; then + tree=$(realpath $tree)/ +fi + # Detect if ALLSOURCE_ARCHS is set. If not, we assume SRCARCH if [ "${ALLSOURCE_ARCHS}" = "" ]; then ALLSOURCE_ARCHS=${SRCARCH} @@ -131,7 +139,11 @@ docscope() dogtags() { - all_target_sources | gtags -i -f - + local gtagsoutdir="${PWD}" + local gtagsroot="${tree}" + + [ -z "${gtagsroot}" ] && gtagsroot="." + all_target_sources | gtags -i -C $gtagsroot -f - $gtagsoutdir } # Basic regular expressions with an optional /kind-spec/ for ctags and