Re: [WIP PATCH 00/30] Adding trailing slash to $(*tree)

From: Elliott Mitchell <ehem+linux@m5p.com>
To: Nicolas Schier <nicolas@fjasle.eu>
Cc: masahiroy@kernel.org, nathan@kernel.org, linux-kbuild@vger.kernel.org
Subject: Re: [WIP PATCH 00/30] Adding trailing slash to $(*tree)
Date: Mon, 4 Mar 2024 11:36:27 -0800	[thread overview]
Message-ID: <ZeYiu3V+Q5xItFHD@mattapan.m5p.com> (raw)
In-Reply-To: <ZeWa_qAsfmxJ5KFy@buildd.core.avm.de>

On Mon, Mar 04, 2024 at 10:57:18AM +0100, Nicolas Schier wrote:
> 
> can you please describe a concrete problem you want to solve with your
> patch set?  Masahiro already asked in [1], and I still don't get your
> motivation while reading your cover letter.  It would be helpful to see
> your goal when looking at your patches.

I'm trying to develop an alternative kernel build system for one Linux
distribution.  Due to how other pieces of the distribution work it seems
using the out-of-tree build mechanism to build in-tree modules may be a
better approach.  This may be abusing the current build system, but if it
works without breaking anything else that should be acceptable.

The problem I've run into is due to the mechanisms of the build system,
the variable $(srctree) gets the value "." while $(src) got the value of
$(CURDIR).

At which point various places which use $(srctree)/$(src) ended up with
the value ./`pwd` and that doesn't work.  Almost all uses of $(srctree)
had it followed with a slash, so if $(srctree) includes the trailing
slash, $(srctree)$(src) ends up the correct value.

This may be outside the envelope of what is supportted, but if it works
without breaking anything it really should be okay.

> Also, I cannot see the problem with commit 16671c1e1cac2 that you
> mentioned.  If a subtree does not want to inherit some variables, but
> re-use the same names, it seems quite legitimate to me to reset those
> variables before use.

Take a quick glance at patch #27.  Basically every Makefile inside tools/
sets $(srctree) to the equivalent of $(abs_srctree).  This suggests
16671c1e1cac2 was working around an issue for tools/perf, but instead
the issue effects most of the Makefiles.  I'm left suspecting the issue
was later fixed for tools/perf and 16671c1e1cac2 was a mistake.

I suspect at this point removing the lines at the top of tools/Makefile
added by 16671c1e1cac2 and removing all those duplications would work
better.  All I'm certain of is the present situation it doesn't look
right.

Another option is dropping the last 4 looks viable.  Due to ending up
with absolute paths, their values of $({src|obj}tree) are likely
non-problematic for me.

-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445