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

2021-11-29 Thread Paul D. Smith
Follow-up Comment #24, bug #48643 (project make): If we decide to do this I'm not sure it should be a command line flag: command line flags should be limited to modifying how a given user wants their build to run. It shouldn't modify fundamental ways that a makefile is parsed. The author of the

[bug #55242] Included Makefile not found, no rule to build it but make does not fail

2021-11-29 Thread Paul D. Smith
Update of bug #55242 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #5: Thanks for your though

Target is not updated properly if intermediate prerequisite is in grouped targets rule with dry run, but ok in a real run

2021-11-29 Thread Mikhail P
Greetings! I get unexpected behavior with the following toy makefile when *d_file* is newer than *a_file* |a_file : b_file|| ||    echo "making a_file from $<" > $@|| || ||b_file c_file &: d_file|| ||    echo "making b_file from $<" > b_file|| ||    echo "making c_file from $<" > c_file|| || |

Re: [bug #61409] The code used to create sub-processes on Windows triggers the spawnve() issue

2021-11-29 Thread Liviu Ionescu
> On 29 Nov 2021, at 16:04, David Boyce wrote: > > ... why can't GNU make dig up these special "=" env vars on its own and add > them to its custom "envp" environment? Sure, any suggestions are welcome, if someone knows how to do it, can use my test project (https://github.com/xpack-dev-too

Re: [bug #61409] The code used to create sub-processes on Windows triggers the spawnve() issue

2021-11-29 Thread David Boyce
> The only thing that is guaranteed to work is to always create the children processes with a NULL environment ... This has been stated twice as an absolute fact but it leaves an obvious question: why can't GNU make dig up these special "=" env vars on its own and add them to its custom "envp" env

[bug #61409] The code used to create sub-processes on Windows triggers the spawnve() issue

2021-11-29 Thread Liviu Ionescu
Follow-up Comment #8, bug #61409 (project make): > Your suggestion to modify the Make's own environment also won't work well, because Make invokes programs asynchronously, i.e. it doesn't wait for the child to exit, and so modifying Make's environment will affect Make itself I'm not sure this is

[bug #61409] The code used to create sub-processes on Windows triggers the spawnve() issue

2021-11-29 Thread Eli Zaretskii
Follow-up Comment #7, bug #61409 (project make): It is unrealistic to ask Make not to modify the environment of the programs it invokes, because some of the GNU Make features absolutely require to put stuff into the child environment. Your suggestion to modify the Make's own environment also won'

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

2021-11-29 Thread Dmitry Goncharov
Follow-up Comment #23, bug #48643 (project make): Yet another option is to have compatibility search disabled by default and introduce flag '--enable-compatibility-search'. This is a good choice going forward, because we really don't want new makefiles to rely on compatibility search. This choice