On 17.06.2023 02:28, Kent Overstreet wrote: > On Fri, Jun 16, 2023 at 08:10:44PM +0200, Peter Oberparleiter wrote: >> 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) > > I just hooked it up and it works perfectly - I owe you a beer :) Glad to be of help! >> 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. > > Now that I've spent a couple days starting to wrap my head more around > make, it doesn't look terribly magic to me. I'd hate to have to spawn > off a subshell for this. Leaving the method of how this input data is processed inside kbuild aside for a moment, I'm wondering if specifying the list of directories via a CONFIG symbol instead of make parameters would work equally well. Initially I thought this would be too complex to process using Makefile functions alone, but with the logic shown above this could be relatively simple to achieve. Also having given this some more thought, a CONFIG symbol indeed seems like a better fit considering aspects such as reproducibility of builds and config symbol documentation. The CONFIG symbols could look something like: - CONFIG_GCOV_PROFILE_INCLUDE: list of directories to include in profiling - CONFIG_GCOV_PROFILE_EXCLUDE: list of directories to exclude from profiling where the precedence would be: exclude list > include list > GCOV_PROFILE_* specified in Makefiles > CONFIG_GCOV_PROFILE_ALL Sub-directory handling could work similar to how you described it for the make parameter, i.e. an include/exclude statement for a parent directory would also apply to sub-directories. What this approach work for your use case? Note that I'm not asking you to implement this - I just want to get a better picture of how a generic solution could look like. -- Peter Oberparleiter Linux on IBM Z Development - IBM Germany R&D
