[bug #66974] Irregular target introduction of unmatched wildcard include

URL: <https://savannah.gnu.org/bugs/?66974> Summary: Irregular target introduction of unmatched wildcard include Group: make Submitter: None Submitted: Tue 01 Apr 2025 08:15:07 PM UTC Severity: 3 -

[bug #65982] make --trace does not explain remade include files

Update of bug #65982 (group make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System:

[bug #65982] make --trace does not explain remade include files

Follow-up Comment #3, bug #65982 (group make): Oh, sorry, I didn't R enough of TFM but at least a little doc bug will be fixed as a result. Sorry for the waste of time otherwise. ___ Reply to this item at:

[bug #65982] make --trace does not explain remade include files

Update of bug #65982 (group make): Item Group: Bug => Documentation ___ Follow-up Comment #2: This is intended behavior. The docs for the trace option: https://www.gnu.org/software/make/manual/h

[bug #65982] make --trace does not explain remade include files

Follow-up Comment #1, bug #65982 (group make): > ... also includes 2 generated makefiles ... Actually the attached version has only one generated makefile (x1.mk) but the situation is unaffected. ___ Reply to this item at:

[bug #65982] make --trace does not explain remade include files

URL: <https://savannah.gnu.org/bugs/?65982> Summary: make --trace does not explain remade include files Group: make Submitter: None Submitted: Sat 13 Jul 2024 02:38:49 AM UTC Severity: 3 -

[bug #64002] Improve MAKEFILE_LIST with include

URL: <https://savannah.gnu.org/bugs/?64002> Summary: Improve MAKEFILE_LIST with include Group: make Submitter: None Submitted: Wed 05 Apr 2023 05:00:15 PM UTC Severity: 3 - Normal Item

[bug #63516] `include` of absolute path prepends path with `./`

Update of bug #63516 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #9, bug #63516 (project make): > The file name "d:foo" means on Windows "the file 'foo' in the directory that is current on drive 'd' Yep, I don't know much about Windows but I do know that much! :) > So in my opinion we should treat such file names as absolute, because prepend

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #8, bug #63516 (project make): The file name "d:foo" means on Windows "the file 'foo' in the directory that is current on drive 'd'. Yes, windows programs can have a separate current directory on each drive. You can see that if you do the following dance: C:\> cd foobar C:

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #7, bug #63516 (project make): Thanks for the patch but there's no need to spend more time on this; as I said I have a fix. During this time of year I've got a lot going on so it takes me a bit longer to finish things. But Eli I was curious about your comment that we should tre

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #6, bug #63516 (project make): [comment #5 comment #5:] > Thanks for the patch. > > I have three comments: > > (1) The test under "WINDOWS32" should allow a backslash after the colon as well as a forward slash. Sounds right. > > (2) Do we want Make to consider "drive-relati

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #5, bug #63516 (project make): Thanks for the patch. I have three comments: (1) The test under "WINDOWS32" should allow a backslash after the colon as well as a forward slash. (2) Do we want Make to consider "drive-relative" file names, as in "d:foo/bar", relative or absolute?

Re: [bug #63516] `include` of absolute path prepends path with `./`

On Thu, Dec 15, 2022 at 4:17 PM anonymous wrote: > > Follow-up Comment #4, bug #63516 (project make): > > I've attached my fix in case it's helpful. Also attached is a small fix to > `bootstrap.bat` that I had to make to get it to build with `tcc`. > > (file #54105, file #54106) Regarding this f

[bug #63516] `include` of absolute path prepends path with `./`

ional Item Attachment: File name: 0001-Remove-extra-backslash-in-sed-invocation.patch Size:0 KB <https://file.savannah.gnu.org/file/0001-Remove-extra-backslash-in-sed-invocation.patch?file_id=54105> File name: 0002-Windows-Fix-check-for-absolute-pathnames-of-include-.patch Size

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #3, bug #63516 (project make): Yes, that's it. I have a fix and will put in up a patch shortly. ___ Reply to this item at: ___ Messag

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #2, bug #63516 (project make): Line 376 in `src/read.c` may be the culprit: if (ebuf.fp == NULL && deps->error == ENOENT && (flags & RM_INCLUDED) && *filename != '/' && include_directories) Looks like it's trying to determine whether the path is absolute in a way that

[bug #63516] `include` of absolute path prepends path with `./`

Follow-up Comment #1, bug #63516 (project make): `make` was installed with `scoop`. ___ Reply to this item at: ___ Message sent via Savannah https://sav

[bug #63516] `include` of absolute path prepends path with `./`

URL: <https://savannah.gnu.org/bugs/?63516> Summary: `include` of absolute path prepends path with `./` Project: make Submitter: None Submitted: Mon 12 Dec 2022 10:17:30 PM UTC Severity: 3 -

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

Update of bug #56301 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Component Version:

[bug #60412] Avoid default include directories when searching for included files.

t; Closed ___ Follow-up Comment #1: This was fixed by providing two enhancements: First, it's now possible to add a "-I-" option to the command line. If this is done then make forgets about any include file search directories that precede this option (in

[bug #60412] Avoid default include directories when searching for included files.

Additional Item Attachment, bug #60412 (project make): File name: sv60412_dash_a_test.diff Size:0 KB File name: sv60412_dash_a_doc.diffSize:1 KB

[bug #60412] Avoid default include directories when searching for included files.

Additional Item Attachment, bug #60412 (project make): File name: sv60412_dash_a.diffSize:3 KB ___ Reply to this item at:

[bug #60412] Avoid default include directories when searching for included files.

URL: <https://savannah.gnu.org/bugs/?60412> Summary: Avoid default include directories when searching for included files. Project: make Submitted by: dgoncharov Submitted on: Sat 17 Apr 2021 08:34:55 PM UTC Sever

[bug #47399] include sometimes fails for built files

Follow-up Comment #8, bug #47399 (project make): Just to clarify, it's not support for the include keyword we're discussing here. I have no problem believing that various make implementations provided some kind of include facility before GNU make even existed: it seems an obviou

[bug #47399] include sometimes fails for built files

/utree.pl?file=Ultrix-3.1/src/cmd/make/gram.y) certainly includes support for "include" and has copyright dates of 1984-1986, SCCS id 3.0 and date of "4/21/86", i.e. 1986-04-21. This version appears to have been derived from System V (the executables are named starting with "s5mak

[bug #58735] if depending on include, gmake does not execute commands for out of date targets in the right order

Follow-up Comment #2, bug #58735 (project make): Thank you for confirming that gmake executes the commands for out of date targets that result from the include directive in the inverse (which is the wrong) order. This wrong order causes gmake or the compiler to try to access files that have not

[bug #58735] if depending on include, gmake does not execute commands for out of date targets in the right order

er that is all completed, make tries to rebuild all the makefiles (existing or not). If any fail to rebuild (and were not included with "-include" / "sinclude"), then make fails. If all were rebuilt, then make starts over from scratch and re-reads everything. It is

[bug #58735] if depending on include, gmake does not execute commands for out of date targets in the right order

URL: <https://savannah.gnu.org/bugs/?58735> Summary: if depending on include, gmake does not execute commands for out of date targets in the right order Project: make Submitted by: schily Submitted on: Wed 08 Jul 2020 03:10:27

Re: Suggestion: Modernization of the include path

On Tue, Jun 2, 2020 at 10:19 AM Paul Smith wrote: > On Tue, 2020-06-02 at 08:48 -0400, Sam Kendall wrote: > > > I suggest that > > > a) $HOME/.local/include is effectively added to the > > >include_directories ... > > > > If two users build the

Re: Suggestion: Modernization of the include path

On Tue, 2020-06-02 at 08:48 -0400, Sam Kendall wrote: > > I suggest that > > a) $HOME/.local/include is effectively added to the > >include_directories ... > > If two users build the same source tree, they will effectively be > building variants of it, each extend

Re: Suggestion: Modernization of the include path

> I suggest that > a) $HOME/.local/include is effectively added to the >include_directories ... If two users build the same source tree, they will effectively be building variants of it, each extending it with her own $HOME/.local/include directory. And if one user builds two *

Re: Suggestion: Modernization of the include path

Christian Hujer (31 May 2020 15:53) wrote > I suggest that > a) $HOME/.local/include is effectively added to the >include_directories, as if it were inserted in >default_include_directories before /usr/gnu/include. > b) Change function src/read.c/eval_makefile

[bug #58472] Modernization of the include path

URL: <https://savannah.gnu.org/bugs/?58472> Summary: Modernization of the include path Project: make Submitted by: None Submitted on: Sun 31 May 2020 07:13:43 PM UTC Severity: 3 - Normal Item

Suggestion: Modernization of the include path

Hello everyone, I suggest that a) $HOME/.local/include is effectively added to the include_directories, as if it were inserted in default_include_directories before /usr/gnu/include. b) Change function src/read.c/eval_makefile() to loop over .INCLUDE_DIRS instead of include_directories when

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

Follow-up Comment #4, bug #56301 (project make): This test is the same as the one submitted earlier, but unlinks the included makefiles. diff --git a/tests/scripts/features/include b/tests/scripts/features/include index 0c63c06..4401622 100644 --- a/tests/scripts/features/include +++ b/tests

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

Follow-up Comment #3, bug #56301 (project make): These patches are against the current master (0c326a66c9eb3a3b5e4ab7892578b016b0590b1f). ___ Reply to this item at:

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

Follow-up Comment #2, bug #56301 (project make): Here is a test. diff --git a/tests/scripts/features/include b/tests/scripts/features/include index 0c63c06..2281ee4 100644 --- a/tests/scripts/features/include +++ b/tests/scripts/features/include @@ -260,4 +260,13 @@ inc1:; @%s $@ &&

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

Follow-up Comment #1, bug #56301 (project make): Here is a fix. diff --git a/src/main.c b/src/main.c index bcba2d1..5c1a7da 100644 --- a/src/main.c +++ b/src/main.c @@ -2305,6 +2305,8 @@ main (int argc, char **argv, char **envp) any_remade |= (mtime != NONEXISTENT_MTIME

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

Update of bug #56301 (project make): Item Group:None => Bug ___ Reply to this item at: ___ Messa

Re: [bug #56892] toxic combination of -include and match-anything rules

x recursive makefile > suite (not of my design or under my ownership) a co-worker added a > construct like the following: > > -include foobar.mk > foobar ?= XYZ > > The idea is that foobar.mk would be a one-line include file which > assigns the "foobar" variable if it

[bug #56892] toxic combination of -include and match-anything rules

Update of bug #56892 (project make): Item Group: Bug => Enhancement ___ Reply to this item at: ___ Messa

[bug #56892] toxic combination of -include and match-anything rules

Follow-up Comment #3, bug #56892 (project make): I can think of one way to address these types of issues that might not be too impactful: Make knows both how deep inside a recursion it is (via MAKELEVEL) and also how many times its re-exec'd itself (via MAKE_RESTARTS). It could check to see if e

[bug #56892] toxic combination of -include and match-anything rules

Follow-up Comment #2, bug #56892 (project make): Ok. WRT your second point, you are of course right and I didn't think it out properly. WRT the delayed warning being new as of 4.2.1, I didn't know that and agree that it's a serious compatibility issue, so I'm happy to drop this. _

[bug #56892] toxic combination of -include and match-anything rules

Follow-up Comment #1, bug #56892 (project make): It is definitely not the case that we can ignore -include if the makefile doesn't exist. In fact until recently, virtually every makefile that needed to be rebuilt would be included with "-include", because otherwise you'd ge

[bug #56892] toxic combination of -include and match-anything rules

URL: <https://savannah.gnu.org/bugs/?56892> Summary: toxic combination of -include and match-anything rules Project: make Submitted by: boyski Submitted on: Sat 14 Sep 2019 08:28:32 PM UTC Severity: 3 -

Re: A problem with "-include"

I added back the mailing list, for completeness. On Sun, 2019-06-02 at 00:25 +0430, Arham Amouei wrote: > I just didn't like the fact that whenever I entered "make clean" the > make first updated depend.mk and then deleted it! Ah. It would have been good if your original questions had been more

Re: A problem with "-include"

On Sat, 2019-06-01 at 19:47 +0430, Arham Amouei wrote: > It seems to me that -include depend.mk in addition to including > depend.mk, executes the rule that depend.mk is its target. I'd like > to stop this behavior. Found nothing helpful in the manual for this > purpose. I saw

A problem with "-include"

Hi My makefile comes below. When the folder is clean and I enter make clean I receive mpicc -MM *.c > depend.mk rm -f *.o libfmd.so depend.mk It seems to me that -include depend.mk in addition to including depend.mk, executes the rule that depend.mk is its target. I'd like to stop this

[bug #56301] Mandatory/Optional include files and pattern rule with multi-targets

URL: <https://savannah.gnu.org/bugs/?56301> Summary: Mandatory/Optional include files and pattern rule with multi-targets Project: make Submitted by: masahiroy Submitted on: Fri 10 May 2019 04:33:49 PM UTC Sever

Re: Why is --include-dir option effective only in sub make ?

Hi Paul, 2018-09-13 21:34 GMT+09:00 Paul Smith : > On Thu, 2018-09-13 at 14:18 +0900, Masahiro Yamada wrote: >> I wonder why --include-dir does not become >> effective in the current Makefile. > > In order for this to work, the MAKEFLAGS variable would have to be re

Re: Why is --include-dir option effective only in sub make ?

On Thu, 2018-09-13 at 14:18 +0900, Masahiro Yamada wrote: > I wonder why --include-dir does not become > effective in the current Makefile. In order for this to work, the MAKEFLAGS variable would have to be re- parsed every time MAKEFLAGS was set in the makefile and that's not h

Why is --include-dir option effective only in sub make ?

Hello, I wonder why --include-dir does not become effective in the current Makefile. Here is the test case. [ Not working sample ] -(Makefile)-- MAKEFLAGS += --include-dir=foo include inc.mk all: @echo hello -(Makefile END

[bug #43901] Stop on error when build -include

the -include variant to avoid getting warning messages about include files that will be remade later. Thus you can use "include" and have your makefiles fail if the rule to rebuild the included file fails. I'm closing this issue. ___

[bug #40236] include, -include and sinclude ignores failures to read the included file

Update of bug #40236 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #40234] Ignored missing include in makefile causes "no makefile found" message.

Update of bug #40234 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

Re: [PATCH][bug #48037] Add glob folder include to w32/Makefile.am

> From: Luke Allardyce > Date: Sat, 28 May 2016 00:11:51 +0900 > > Fixes windows build when compiling with make. > > diff --git a/w32/Makefile.am b/w32/Makefile.am > index b0b4734..53ba788 100644 > --- a/w32/Makefile.am > +++ b/w32/Makefile.am Thanks, pushed. __

[PATCH][bug #48037] Add glob folder include to w32/Makefile.am

\ compat/posixfcn.c pathstuff.c w32os.c -libw32_a_CPPFLAGS = -I$(srcdir)/include -I$(srcdir)/subproc -I$(top_srcdir) +libw32_a_CPPFLAGS = -I$(srcdir)/include -I$(srcdir)/subproc -I$(top_srcdir) \ +-I$(top_srcdir)/glob ___ Bug

Re: include warnings vs -include ignore errors

On Wed, 2016-05-25 at 09:19 -0700, Raymond Dubler wrote: > What I need is: >   1. no warning that blah.d is missing >   2. same functionality as include blah.d, ie display error and > terminate of failure > > Unless I am missing something in the manual, this is not provided with

include warnings vs -include ignore errors

My concern is as follows: Using include blah.d when there is a build rule for blah.d causes the following: 1. a warning that blah.d is missing 2. execution of rule to build blah.d a. on success, continue working b. on failure, display error and terminate Using -include blah.d when

[bug #47624] Suppress unnecessary warning for "include XXX" when we know how to build XXX

ed bug #102 instead, which solves this problem completely (even if the rule to build the included makefile isn't defined until after the include line). ___ Reply to this item at: <http://savannah.

[bug #47624] Suppress unnecessary warning for "include XXX" when we know how to build XXX

Follow-up Comment #2, bug #47624 (project make): I would suggest one small change: instead of making the message go away entirely, change it to reflect the full situation: a) No such file or directory, no path to rebuild. Stopping. b) No such file or directory, rebuilding from target (...) c) Ru

[bug #47624] Suppress unnecessary warning for "include XXX" when we know how to build XXX

Follow-up Comment #1, bug #47624 (project make): I like this change because we have also seen much confusion resulting from this message-which-looks-like-an-error-message-but-isn't. Also want to point out an alternative: Makefile.test:11: generated_include1: No such file or directory (remaking)

[bug #47624] Suppress unnecessary warning for "include XXX" when we know how to build XXX

URL: <http://savannah.gnu.org/bugs/?47624> Summary: Suppress unnecessary warning for "include XXX" when we know how to build XXX Project: make Submitted by: stefanb Submitted on: Tue 05 Apr 2016 08:18:01 AM GMT

[bug #47399] include sometimes fails for built files

Follow-up Comment #6, bug #47399 (project make): Regarding licensing: I can't say for sure what CDDL-covered code might have been linked with GNU make on OpenIndiana. However it's most likely simply things such as the C runtime library, since that's about all that GNU make relies on. In that cas

[bug #47399] include sometimes fails for built files

Follow-up Comment #5, bug #47399 (project make): > Also it's not clear what you mean when you say "make" Tested versions are listed in the comments at the top of the test makefile. Note that on OpenIndiana, /usr/bin/make, /usr/bin/dmake, and /usr/xpg4/bin/make all use the same executable, but wit

[bug #47399] include sometimes fails for built files

#x27;s not clear what you mean when you say "make"; the original make implemented by Feldman didn't have this feature, of course. And the POSIX definition of "make" doesn't mention it either (until recently POSIX didn't require "include"). When I say

[bug #47399] include sometimes fails for built files

e your "include baz" line to "-include" or "sinclude" No, I cannot; that would cause the makefile to be non-portable, i.e. it would no longer work with make, dmake, bmake,... > you can move the "include baz" line into the "bar" makefile Maintenanc

[bug #47399] include sometimes fails for built files

Update of bug #47399 (project make): Open/Closed: Closed => Open Triage Status:None => Medium Effort ___ Reply to this item at:

[bug #47399] include sometimes fails for built files

Update of bug #47399 (project make): Item Group: Bug => Enhancement Status: Not A Bug => None ___ Follow-up Comment #2: Actually I'm going to

[bug #47399] include sometimes fails for built files

there is no file "baz" and no target that can build "baz", it fails. This is the way make has always worked, and always been intended to work; this feature was already present in GNU make in 1992, when the first set of source code was added to source control. You have various ch

[bug #47399] include sometimes fails for built files

URL: <http://savannah.gnu.org/bugs/?47399> Summary: include sometimes fails for built files Project: make Submitted by: None Submitted on: Sat 12 Mar 2016 11:51:38 PM UTC Severity: 3 - Normal Item Grou

Re: Make: Unexpected Behavior with Dependencies and include Statement

> I was thinking to build the objects but not the dependencies. We do a lot > of one-time only builds, where we don't need dependencies at all. In that case, leave out the include of any .d whose .o doesn't exist; you fatuously know you need to build the .o, so you don&#x

Re: Make: Unexpected Behavior with Dependencies and include Statement

On Wed, 2015-09-23 at 15:00 -0500, John Westing wrote: > > You are doing exactly Basic Auto-dependencies. But that works because > > of the re-exec if include files are rebuilt > > I don't think that's true, as the author explains in regards to the > basic method

Re: Make: Unexpected Behavior with Dependencies and include Statement

> of the re-exec if include files are rebuilt I don't think that's true, as the author explains in regards to the basic method: "Let’s address the first problem above: the re-invocation of make. If you think about it, this re-invocation is really not necessary. Since we know *some*

Re: Make: Unexpected Behavior with Dependencies and include Statement

counter example? What I'm doing is very similar to the Basic > Auto Dependencies case from the article. You are doing exactly Basic Auto-dependencies. But that works because of the re-exec if include files are rebuilt, which you want to avoid doing... then it won't work anymore. >

Re: Make: Unexpected Behavior with Dependencies and include Statement

related, I don't think autoremaking answers my second question. Why does rebuilding running "make a.o" also rebuild a.d? a.o doesn't depend on a.d. On Wed, Sep 23, 2015 at 12:24 PM, Paul Smith wrote: > On Wed, 2015-09-23 at 12:15 -0500, John Westing wrote: > > So wh

Re: Make: Unexpected Behavior with Dependencies and include Statement

On Wed, 2015-09-23 at 12:15 -0500, John Westing wrote: > So when an include make file gets modified make restarts the original > make file? Correct. > For efficiency I don't want to always create the dependencies, that's > why I did it this way. I don't understand w

Re: Make: Unexpected Behavior with Dependencies and include Statement

So when an include make file gets modified make restarts the original make file? For efficiency I don't want to always create the dependencies, that's why I did it this way. Is there anyway to disable remaking? On Wed, Sep 23, 2015 at 12:13 PM, Paul Smith wrote: > On Wed, 2015-0

Re: Make: Unexpected Behavior with Dependencies and include Statement

On Wed, 2015-09-23 at 13:06 -0400, Mike Shal wrote: > Though normally you don't want to include .d files as targets in your > Makefile. Just generate them as a side-effect of compilation with -MMD > or whatever in gcc and then include them, and you can avoid the whole > issue. F

Re: Make: Unexpected Behavior with Dependencies and include Statement

7; --in-place $@ > > a.o: > gcc -c -m32 -o $@ a.c > > all: a.d a.o > > -include a.d > > > See: https://www.gnu.org/software/make/manual/html_node/Remaking-Makefiles.html#Remaking-Makefiles Specifically, after reading all the Makefiles (like "a.d",

Re: Make: Unexpected Behavior with Dependencies and include Statement

I made a typo in my previous email: The following make file duplicates the problem, the one in the previous email does not: a.d: gcc -m32 -MM -o $@ a.c sed 's!a.o!$@ a.o!' --in-place $@ a.o: gcc -c -m32 -o $@ a.c all: a.d a.o -include a.d

Make: Unexpected Behavior with Dependencies and include Statement

I originally posted this problem here: http://stackoverflow.com/questions/32742321/make-unexpected-behavior-with-dependencies-and-include-statement Here's my problem: I have the following Makefile: a.d: gcc -m32 -MM -o $@ a.c sed 's!a.o!$@ a.o!' --in-pl

[bug #46012] MAKEFLAGS does not include command overrides if -e flag is set

URL: <http://savannah.gnu.org/bugs/?46012> Summary: MAKEFLAGS does not include command overrides if -e flag is set Project: make Submitted by: rici Submitted on: Mon 21 Sep 2015 02:10:12 GMT Severity: 3 -

[bug #45438] -include file prerequisites not found, give no error

Update of bug #45438 (project make): Status:None => Duplicate Open/Closed:Open => Closed Fixed Release:None => 3.82 _

[bug #45438] -include file prerequisites not found, give no error

Follow-up Comment #3, bug #45438 (project make): Not allowed to upgrade, but thanks for the info. ___ Reply to this item at: ___ Message sent via/by Sav

[bug #45438] -include file prerequisites not found, give no error

Follow-up Comment #2, bug #45438 (project make): Upgrade. This was fixed some time in the last five years. ___ Reply to this item at: ___ Message sent

[bug #45438] -include file prerequisites not found, give no error

Follow-up Comment #1, bug #45438 (project make): May be related to #29074, but doesn't sound like a duplicate. ___ Reply to this item at: ___ Message se

[bug #45438] -include file prerequisites not found, give no error

URL: <http://savannah.gnu.org/bugs/?45438> Summary: -include file prerequisites not found, give no error Project: make Submitted by: ultrajoe Submitted on: Mon 29 Jun 2015 06:15:42 PM GMT Severity: 3 -

[bug #43901] Stop on error when build -include

URL: <http://savannah.gnu.org/bugs/?43901> Summary: Stop on error when build -include Project: make Submitted by: andigor Submitted on: Пнд 29 Дек 2014 12:44:32 Severity: 3 - Normal Item Group: Enhan

Re: Problem with GNU Make (3.81, probably newer) with stacking --include-dir=...

On Wed, 2014-06-11 at 13:45 -0400, Paul Smith wrote: > Unfortunately in older versions of make the option and argument > are left as two separate words: > > $ echo 'a:;: $(MAKEFLAGS)' | make-3.81 -f- -I/usr/include -I/bin > : I /usr/include -I /bin > > which

Re: Problem with GNU Make (3.81, probably newer) with stacking --include-dir=...

On Tue, 2014-06-10 at 16:01 -0700, Corey Brenner wrote: > I've run into a situation where I want to control the include dirs in > a recursive make. I am adding include paths to recursive invocations > via --include-dir=, when I find one which matches my criteria. > > Howeve

Problem with GNU Make (3.81, probably newer) with stacking --include-dir=...

Hi, I've run into a situation where I want to control the include dirs in a recursive make.  I am adding include paths to recursive invocations via --include-dir=, when I find one which matches my criteria. However, GNU Make seems to be holding on to these directories from high

[bug #40236] include, -include and sinclude ignores failures to read the included file

URL: <http://savannah.gnu.org/bugs/?40236> Summary: include, -include and sinclude ignores failures to read the included file Project: make Submitted by: None Submitted on: tor 10 okt 2013 12.13.16 Severity: 3 -

[bug #40234] Ignored missing include in makefile causes "no makefile found" message.

URL: <http://savannah.gnu.org/bugs/?40234> Summary: Ignored missing include in makefile causes "no makefile found" message. Project: make Submitted by: padavo Submitted on: Thu 10 Oct 2013 05:28:09 AM GMT

[bug #31149] Rules to build -include makefiles cause unexpected side-effects

again, the 3.82 output is the same as the 3.81 output and is correct. The reason is that when you add the explicit -include of Obj/test1.d that forces the target to be known to make, and make considers it to exist hence be a valid result of the vpath

Re: [bug #38437] cannot find the include file

/28 Philip Guenther > On Wed, Feb 27, 2013 at 8:55 PM, Jian wrote: > ... > > Supposing 2 makefiles in dir A: 1.mak, 2.mak, and 1.mak include 2.mak. > > Now in dir B, 3.mak includes 'A/1.mak' (will auto include 2.mak). But > error > > shows that 2.mak cannot

[bug #38437] cannot find the include file

to. When reading a makefile, the path of this file should be added into the search path automaticallly. 2013/2/28 Philip Guenther On Wed, Feb 27, 2013 at 8:55 PM, Jian wrote: ... > Supposing 2 makefiles in dir A: 1.mak, 2.mak, and 1.mak include 2.mak. > Now in dir B, 3.mak includes &#

[bug #38437] cannot find the include file

U make has always worked: the include file reference is always relative to the current working directory of the GNU make program, regardless of what directory the current makefile is in. There are far too many makefiles out there relying on this behavior, to change it now. Suggestions have been m

Re: [bug #38437] cannot find the include file

On Wed, Feb 27, 2013 at 8:55 PM, Jian wrote: ... > Supposing 2 makefiles in dir A: 1.mak, 2.mak, and 1.mak include 2.mak. > Now in dir B, 3.mak includes 'A/1.mak' (will auto include 2.mak). But error > shows that 2.mak cannot be found. > > The make option "-I"

  1   2   3   >