Re: Make, MAKE_TERMOUT, color escape sequences, TTYs, and PTYs

Hi, I can imagine this will be difficult to make complete, useful and bug free, there are many issues that will appear. I'd suggest saving a lot of time in development while still allowing the feature in its earliest forms and leaving room for issues to be resolved at will by providing hooks for

Re: Suggested feature design for https://savannah.gnu.org/bugs/?42125

generation which becomes a bit of a pain and which impacts tab-completion (which I value a great deal) programmatic rule definition via functions which is difficult to understand for many people that need to enhance a component's build definitions and is

Re: Suggested feature design for https://savannah.gnu.org/bugs/?42125

On 24 Apr 2016 01:00, "Paul Smith" wrote: > On Thu, 2016-04-21 at 08:29 +0100, Tristan Wibberley wrote: > > x86-64 x86 armel: %=build/%/main.o: main.c ; true > > factors :: path=subst : prerequisites ; recipe > > Almost all the syntax you suggest that uses &q

Re: Suggested feature design for https://savannah.gnu.org/bugs/?42125

rt to imperative rule generation because that becomes unclear and difficult to debug quite quickly. On 20 April 2016 at 09:14, Tristan Wibberley wrote: > Aaaand, there's the thinko ... > > I just realised that substitution normally only applies to the first % in > the re

Re: Suggested feature design for https://savannah.gnu.org/bugs/?42125

it's other use. How about some other token not used for this purpose elsewhere? Although I can't find one. On 20 April 2016 at 07:48, Tristan Wibberley wrote: > Hi folks, > > I'm interested in making it easier to specify some of the build system > behaviours I want and I

Suggested feature design for https://savannah.gnu.org/bugs/?42125

; true # same as this where all targets of one rulesare generated in a single step (as if there is a # % sign in there but $* must be the empty string) # main.o main.log .main.deps main.symbols: main.c ; # err.o err.log .err.deps err.symbols: err.c ; true Regards Tristan Wibberley ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make

[bug #42125] Explicit rules do not support multiple targets

Follow-up Comment #2, bug #42125 (project make): There is a space of inputs that is currently disallowed that could support both multiple rule types: 1. a single target for each of multiple rules, and 2. a single rule having multiple targets for both implicit and explicit rules. T

[bug #47715] Implicit rule defined for multiple targets at once only runs one time

Follow-up Comment #6, bug #47715 (project make): Please find here detailed thoughts on the documentation to cover this situation. I will add to https://savannah.gnu.org/bugs/?42125 with a suggested mechanism to choose the behaviour of multiple targets that I think is probably straightforward to i

[bug #47715] Implicit rule defined for multiple targets at once only runs one time

Follow-up Comment #4, bug #47715 (project make): Can you consider this a bug against the documentation? I looked through to find explanation of this issue with some care. ___ Reply to this item at:

[bug #47715] Implicit rule defined for multiple targets at once only runs one time

Follow-up Comment #2, bug #47715 (project make): Note that when running `make a/foo.o b/bar.o` the recipe is run twice instead of only once. Is this expected to differ from the behaviour of `make a/foo.o b/foo.o` ? If so then what's the key factor? whether the value of $* differs between the two

[bug #47715] Implicit rule defined for multiple targets at once only runs one time

URL: Summary: Implicit rule defined for multiple targets at once only runs one time Project: make Submitted by: codeshot Submitted on: Sat 16 Apr 2016 01:12:44 PM GMT Severity: 3 - Nor