[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #19, bug #30381 (project make): Regarding the earlier suggestion of using recursive calls to Make: The problem with this is concurrency. I want to do multi-threaded make, and I don't want different recipes building the same shared prereq simultaneously, stepping on each others'

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #18, bug #30381 (project make): Ack, my code got mangled, because I'm new at Rich Markup. Here it is again: I could really use this feature. I'm implementing a sort of branching revision control of databases, in which the history is stored as SQL diffs in files named things li

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #17, bug #30381 (project make): I could really use this feature. I'm implementing a sort of branching revision control of databases, in which the history is stored as SQL diffs in files named things like .from..sql . So, for example, there's an explicit rule in the makefile to

Re: [bug #30381] Don't avoid implicit rule recursion quite so soon. (fwd <- reinp...@win.tue.nl)

On Jun 2, 2014 5:14 AM, "Reinier Post" wrote: > On Fri May 30 02:58:17 2014, invalid.nore...@gnu.org (Brent Baccala) wrote: > > Follow-up Comment #15, bug #30381 (project make): > > > > I support this feature. > > > > I just tried to write a makefile that implicitly generates output files from > >

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #16, bug #30381 (project make): Brent, I don't think your problem can be helped by this patch. For details, see my reply to the list . ___ Reply to this

Re: [bug #30381] Don't avoid implicit rule recursion quite so soon.

On Fri May 30 02:58:17 2014, invalid.nore...@gnu.org (Brent Baccala) wrote: > Follow-up Comment #15, bug #30381 (project make): > > I support this feature. > > I just tried to write a makefile that implicitly generates output files from > XML control files, that contain references to other files

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #15, bug #30381 (project make): I support this feature. I just tried to write a makefile that implicitly generates output files from XML control files, that contain references to other files in the XML. What I wanted was this: define futurebases $(shell xmllint --xpath "pr

Re: [bug #30381] Don't avoid implicit rule recursion quite so soon.

On Sat Apr 6 13:37:58 2013, invalid.nore...@gnu.org (Paul D. Smith) wrote: > Follow-up Comment #14, bug #30381 (project make): > > I don't think it's correct to implement this feature using a > command-line option. Makefiles need to be written in a certain way > to use this feature and if they a

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #14, bug #30381 (project make): I don't think it's correct to implement this feature using a command-line option. Makefiles need to be written in a certain way to use this feature and if they are written that way, then you must have the feature enabled or the build will fail. A

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #13, bug #30381 (project make): Here is version two of the patch. It fixes an essential off-by-one error, adds the feature to .FEATURES, improves the tests, and adds documentation (generated info files not included). The reported version is still 3.82. (file #21902) _

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #12, bug #30381 (project make): Another idea is to make the "Avoiding implicit rule recursion" message report which rule is being avoided. For this it seems necessary to either add a floc field to struct rule or give even commandless rules a cmds field so as to allow the use of

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #11, bug #30381 (project make): Strike my last comment: invoking a rule multiple times in a chain appears to work just fine. To prove this, here is a patch against the make 3.82 source that adds a -M option, which allows this; a test script is included, but string translations

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #10, bug #30381 (project make): I really need this feature with my present set of makefiles, so I've looked at the code (implicit.c) to see how easy it would be to make the change. The main issue is the mixing in struct rule of definition-time information and inference-time inf

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #9, bug #30381 (project make): Maybe we can use something like %(1).foo%(2) : %(1)a%(2) So your example will look like %(1).foo : %(1)a%(1) I agree with Reiner. make can be better and has more features, then current implementation. At least all functions from http://gmsl.s

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #8, bug #30381 (project make): Somehow the verbatim tags ate most of my descriptions (a preview facility would be really nice), retry: (imagine verbatim on) (6) d. For each prerequisite that does not exist, follow this algorithm recursively to see if the prerequisite can be ma

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #7, bug #30381 (project make): Paul, I don't think it's complicated to describe. %: %.o and %.o: %.c don't shorten the search target so they can't be used twice, while %.made: % does. All the cases in my own makefiles are of the second type anyway. This is only considered

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #6, bug #30381 (project make): Reiner, I agree with Paul. Performance is very important. And we should not add very rare used feature. What about submakes. Did you try %.rev : % sort $? > $@ $(MAKE) $...@.rev __

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #5, bug #30381 (project make): But it isn't just a matter of infinite recursion; there's a very serious issue of performance as well, even without infinite recursion. Computing pattern rule matches can already take quite a while: if we add more ways in which patterns can recurs

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #4, bug #30381 (project make): PS the second rule in the example should also have a > of course. ___ Reply to this item at: ___ Messa

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #3, bug #30381 (project make): Sorry to have been so cryptic, but I really wanted to express the need and various ideas for how to approach a solution, rather than present a detailed proposal - for that, I would need more input from other users and more knowledge about the detai

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Follow-up Comment #2, bug #30381 (project make): Actually my example is solved by your suggestion to use a stack of targets. However, if you imagine a pattern rule where every iteration of the rule _grows_, instead of shrinks, then a stack of targets wouldn't help. What about: %.x : %.x.x ; ca

[bug #30381] Don't avoid implicit rule recursion quite so soon.

Update of bug #30381 (project make): Item Group:None => Enhancement Component Version:None => 3.81 ___ Follow-up Comment #1: This is the documente

[bug #30381] Don't avoid implicit rule recursion quite so soon.

URL: Summary: Don't avoid implicit rule recursion quite so soon. Project: make Submitted by: r_p Submitted on: Wed 07 Jul 2010 03:26:17 PM GMT Severity: 3 - Normal Item