All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Oberparleiter <oberpar@linux.ibm.com>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	linux-kbuild@vger.kernel.org
Subject: Re: Specifying CFLAGS for a directory on the command line
Date: Fri, 16 Jun 2023 20:10:44 +0200	[thread overview]
Message-ID: <c45f6e75-da4e-e496-e3c4-4fdfea29104a@linux.ibm.com> (raw)
In-Reply-To: <ZIwDIOxq3rE/8QUV@moria.home.lan>

On 16.06.2023 08:37, Kent Overstreet wrote:
> On Thu, Jun 15, 2023 at 11:54:23AM +0200, Peter Oberparleiter wrote:
>> I'll likely not be able to implement this myself, but if you or anyone
>> else wants to go that route, here are my thoughts: $(src) should have
>> the relative source code path that is needed, so here's what needs to be
>> done:
>>
>> 1. Determine how to handle non-letter/digit/underscore characters in the
>>    variable name:
>>
>>    a) GCOV_PROFILE_fs/bcachefs => supported by GNU make [1], though
>>       discouraged due to possible side-effects
>>    b) GCOV_PROFILE_fs_bcachefs => might cause overlays, e.g. a/b/c and
>>       a/b_c both have the same a_b_c suffix
>>
>>    Personally I'd prefer option b)
> 
> Agreed, feels more consistent
> 
>> 2. Define a new Makefile variable that contains $(src) with required
>>    character replacements (scripts/Kbuild.include might be a good place)
>>
>> 3. Add $(GCOV_PROFILE_$(name_of_that_new_var)) to the code quoted above
>>    (scripts/Makefile.lib)
> 
> So this is where I was getting stuck, because we really want this to
> apply to subdirectories (e.g. GCOV_PROFILE_fs_xfs should really also
> apply to fs/xfs/libxfs).
> 
> Do we have existing code for generating a list of path prefixes for a
> given path?

Not that I know of. Here's how it could be made to work using Makefile
magic alone (as a pure programming exercise :)

This will expand a directory to a list of all parent directories:

# expand_parents(a/b/c) = a/b/c a/b a
expand_parents2 = $(if $(subst .,,$(1)),$(call expand_parents,$(1)),)
expand_parents  = $(1) $(call expand_parents2,$(patsubst %/,%,$(dir $(1))))

This list could then be turned into variable suffixes:

# flatten_dirs(a/b/c) = a_b_c a_b a
flatten_dirs = $(subst /,_,$(call expand_parents,$(1)))

And finally the resulting list of suffixed variables could be evaluated:

# eval_vars(X_,a/b/c) = $(X_a_b_c) $(X_a_b) $(X_a)
eval_vars = $(foreach var,$(call flatten_dirs,$(2)),$($(1)$(var)))

So a call like this

$(call eval_vars,GCOV_PROFILE_,a/b/c)

would evaluate to the concatenation of the contents of the following
variables:

GCOV_PROFILE_a_b_c
GCOV_PROFILE_a_b
GCOV_PROFILE_a

The first non-empty variable would then determine whether profiling
should be enabled for the associated source file or not. This would even
implement the correct order of precedence (specific to generic)

Not sure if this amount of magic is suitable for kbuild though. An
alternative, less complex approach would be to move this decision logic
to a helper script.


-- 
Peter Oberparleiter
Linux on IBM Z Development - IBM Germany R&D


  reply	other threads:[~2023-06-16 18:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-09 22:23 Specifying CFLAGS for a directory on the command line Kent Overstreet
2023-06-09 23:11 ` Nick Desaulniers
2023-06-09 23:12   ` Nick Desaulniers
2023-06-09 23:36     ` Kent Overstreet
2023-06-12 16:18       ` Peter Oberparleiter
2023-06-13 18:22         ` Kent Overstreet
2023-06-15  9:54           ` Peter Oberparleiter
2023-06-15 10:39             ` Masahiro Yamada
2023-06-15 14:22               ` Kent Overstreet
2023-06-16 16:45               ` Peter Oberparleiter
2023-06-16 17:00                 ` Kent Overstreet
2023-06-16  6:37             ` Kent Overstreet
2023-06-16 18:10               ` Peter Oberparleiter [this message]
2023-06-17  0:28                 ` Kent Overstreet
2023-06-21  8:54                   ` Peter Oberparleiter
2023-06-22 10:35                     ` Kent Overstreet

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=c45f6e75-da4e-e496-e3c4-4fdfea29104a@linux.ibm.com \
    --to=oberpar@linux.ibm.com \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.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.