[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

2021-11-14 Thread Steven Simpson
Follow-up Comment #16, bug #48643 (project make): [comment #15 comment #15:] > If patch-v1 is applied and released, then users will start writing > makefiles which depend on this feature. This will slow down make, > including for those users who do not even use this feature. Okay. > Once this

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

2021-11-11 Thread Steven Simpson
Follow-up Comment #14, bug #48643 (project make): I've got three implementations of Make lined up. One is master, one has my recent changes applied to master from last month (ssfix; patch included), and one is master with your sv48643_fix.diff applied (dgfix). I've attached a script to compare

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

2021-10-19 Thread Steven Simpson
Follow-up Comment #11, bug #48643 (project make): I saw a couple of tests in targets/NOTINTERMEDIATE failing, 2 and 10. Preserving an already set notintermediate flag (in the same way that intermediate is preserved) allows the tests to pass. This (src/implicit.c#919):

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

2021-10-18 Thread Steven Simpson
Follow-up Comment #10, bug #48643 (project make): [comment #9 comment #9:] > Unfortunately it's exactly the is_target test that causes the problems. The rest of the changes, without that, don't seem to have any issues. Okay, thanks. I hope to get round to the documentation issue. For now, I've

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

2021-10-18 Thread Steven Simpson
Follow-up Comment #8, bug #48643 (project make): [comment #6 comment #6:] > I'm seeing some failures after applying this patch. Just to narrow down the investigation, it might help to split this patch into two. The is_target test and the supporting declaration of f would be the primary patch.

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

2021-05-07 Thread Steven Simpson
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)

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

2021-04-26 Thread Steven Simpson
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

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

2021-04-25 Thread Steven Simpson
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

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

2021-04-24 Thread Steven Simpson
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

Re: Possible GNU Make 4.3 bug

2021-03-20 Thread Steven Simpson
Hi Eldred, On 15/03/2021 22:25, Eldred HABERT wrote: The bug is the following two lines:    Must remake target 'res/tpnk_dev_logo_tiles.2bpp.pb16.size'.    Successfully remade target file 'res/tpnk_dev_logo_tiles.2bpp.pb16.size'. This .size file appears to be a generated header for

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

2021-02-10 Thread Steven Simpson
Additional Item Attachment, bug #48643 (project make): File name: fix-17752-48643.patch Size:4 KB ___ Reply to this item at:

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

2021-02-10 Thread Steven Simpson
Follow-up Comment #4, bug #48643 (project make): Here's a patch that restores the is_target test, and counts the %: rules on the stack, permitting at most one. This should fix this bug, without bug #17752 returning, as features/patternrules test 6 still passes, though perhaps its explanation

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

2021-02-08 Thread Steven Simpson
Follow-up Comment #3, bug #48643 (project make): With the is_target test restored in implicit.c, "make check" fails: features/patternrules ... Error running /home/simpsons/Works/make/tests/../make (expected 0; got 512): '/home/simpsons/Works/make/tests/../make'

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

2021-02-07 Thread Steven Simpson
Follow-up Comment #2, bug #48643 (project make): I think the problem might be in src/implicit.c. >From 3.81 code: /* The DEP->changed flag says that this dependency resides in a nonexistent directory. So we normally can skip looking for the

[bug #48643] Irrelevant targets can confuse make on which pattern rule to select.

2016-08-23 Thread Steven Simpson
Follow-up Comment #1, bug #48643 (project make): According to what I wrote in , this behaviour is present in 3.82, 4.1 and 4.2.1, but not 3.81. ___ Reply to this item at: