Follow-up Comment #14, bug #47880 (project make):
> when a user writes a makefile he should not have to know that
>
> depfiles:=$(obj:.o=.d)
> include $(depfiles)
>
> is less efficient than
>
> depfiles:=$(obj:.o=.d)
> depfiles:=$(addprefix $(CURDIR)/,$(depfiles))
> include $(depfiles)
Follow-up Comment #13, bug #47880 (project make):
> > My opinion is that the users should not have to know this detail.
> I didn't realize you were wearing your 'user' hat!
My bad. By "users" here (and in other places) i meant make users, people who
write makefiles. In other words, when a user
Follow-up Comment #12, bug #47880 (project make):
> > include $(CURDIR)/foo.mk
>
> This indeed suppresses the lookup.
>
> My opinion is that the users should not have to know this detail.
I didn't realize you were wearing your 'user' hat! To me, this is a problem
ideally for the author to
Follow-up Comment #11, bug #47880 (project make):
> Can you use this?:
> include $(CURDIR)/foo.mk
This indeed suppresses the lookup.
My opinion is that the users should not have to know this detail. The behavior
should preferably be optimial for the most common scenarios.
Also, most (as far as
Follow-up Comment #10, bug #47880 (project make):
> One trouble of this default is, when your dep files are missing, make does a
fs access per default directory for each missing dep file.
Are these always cases where you know you want a local file? Can you use
this?:
include $(CURDIR)/foo.mk
On Sun, 2021-04-25 at 11:21 -0400, Jeffrey Walton wrote:
> On Sun, Apr 25, 2021 at 10:51 AM Dmitry Goncharov <
> invalid.nore...@gnu.org> wrote:
> > Follow-up Comment #9, bug #47880 (project make):
> > > But, maybe it's better to grab that bull by the horns.
> > From the user's point of view, it
On Sun, Apr 25, 2021 at 10:51 AM Dmitry Goncharov
wrote:
>
> Follow-up Comment #9, bug #47880 (project make):
>
> > But, maybe it's better to grab that bull by the horns.
>
> From the user's point of view, it may indeed be better to have a single
> interface (MAKEFLAGS), which controls the
Follow-up Comment #9, bug #47880 (project make):
> But, maybe it's better to grab that bull by the horns.
>From the user's point of view, it may indeed be better to have a single
interface (MAKEFLAGS), which controls the behavior from the makefile.
> Regarding removing default directories, I
Follow-up Comment #8, bug #47880 (project make):
Sorry I guess I wasn't clear. I wasn't going to remove them by default: the
default behavior and search path won't change under any of these proposals.
I was suggesting that instead of creating a new flag specifically to remove
default includes,
Follow-up Comment #7, bug #47880 (project make):
> Regarding removing default directories, I wonder what people think of using
something like "-I-" to mean "delete all known include directories up to here
and start over with a fresh set"? So if you used "make -I- -I/foo -I/bar" the
include
Follow-up Comment #6, bug #47880 (project make):
Having makeflags take effect immediately could be a lot of effort so I was
hoping to avoid it. That's why I looked at modifying the .INCLUDE_DIRS
variable instead.
But, maybe it's better to grab that bull by the horns. I already solved some
Follow-up Comment #5, bug #47880 (project make):
> The problem is that MAKEFLAGS is only parsed once before all makefiles are
read, and again after all makefiles are read.
So, this all boils down to having make consider changes to MAKEFLAGS
immediately.
> I was hoping to avoid adding a new
Follow-up Comment #4, bug #47880 (project make):
> 5. Introduce a command line switch to allow the user to remove the default
include directories. https://savannah.gnu.org/bugs/?60412.
I was hoping to avoid adding a new command line switch. In general I don't
like them, plus we may need them for
Follow-up Comment #3, bug #47880 (project make):
> The change I have allows someone to reset the search path from within the
makefile
Awesome. i personally, need this change to be able to skip the default search
directories.
> In make generally (and, IMO, correctly) the person invoking make
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
Update of bug #47880 (project make):
Operating System: MS Windows => Any
Summary: [Win] added MAKELIBPATH as default include directory
=> Allow updates to .INCLUDE_DIRS to change search path
16 matches
Mail list logo
