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/