bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #47880] Allow updates to .INCLUDE_DIRS to change search path


From: Paul D. Smith
Subject: [bug #47880] Allow updates to .INCLUDE_DIRS to change search path
Date: Mon, 19 Apr 2021 18:01:03 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36

Follow-up Comment #2, bug #47880 (project make):

I have a change which fixes this issue.  There is one thing to consider, which
I wonder if anyone has input on.

Today, .INCLUDE_DIRS contains all files in the search path.  That means it
contains both the default search directories and also the directories added
with -I.

The change I have allows someone to reset the search path from within the
makefile by modifying the value in .INCLUDE_DIRS.  That includes both removing
any default search paths and also adding new ones that are specific to the
build system, so that they don't have to be provided on the command line.

There is one issue: what do we do about the -I options provided by the user?

The way it currently works in the changes I have, the makefile can modify the
search path completely: it's initialized to the default value of -I
directories plus default directories before the first makefile is parsed and
that's it: if the makefile resets .INCLUDE_DIRS then that's the set of paths
that're used.

But, I don't really like this.  In make generally (and, IMO, correctly) the
person invoking make gets the final say: it doesn't matter what a variable is
set to in the makefile, if the user sets it on the command line then that's
what's used (I'm ignoring override here, I realize).  It's Not Good(tm) that
any makefile author can add ".INCLUDE_DIRS =" to their makefile and that
essentially prevents any -I option on make invocation from having any effect.

But I don't see a nice alternative.  I've considered these:

1) Have .INCLUDE_DIRS variable only contain the default search path, then
users can reset it and/or add their own by changing .INCLUDE_DIRS, but no
matter what they set it to the values provided with -I would always be
searched first.  This, though, is a backward-compatibility change since the -I
directories would no longer appear in .INCLUDE_DIRS.

2) Leave .INCLUDE_DIRS containing all the search paths, but then always search
for -I directories first regardless of what .INCLUDE_DIRS is set to.  This
could be confusing for users as the search path will not be what they have set
it to (for example, if they use ".INCLUDE_DIRS := mydir $(INCLUDE_DIRS)" the
invoker's -I directory will be searched before "mydir", regardless of what
they see when they run "$(info $(.INCLUDE_DIRS))").  Definitely we'd need to
massage the search path to avoid duplicate directory lookups.

3) Leave it as I have it now and say "oh well".

I'm currently leaning towards #2 as the "least bad" option but I'm interested
in opinions.  I would prefer #1 except I don't know if I can justify the
backward-compatibility break.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?47880>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]