Re: Undesirable overhead in GNU Make 4.2.1.
On Tue Feb 6 15:12:45 2018, hans.ottevan...@gmail.com (Hans Ottevanger) wrote: > Hi, > > We are attempting to use GNU Make 4.2.1 to build a large software tree > (~29 targets). > > The build hosts we are testing on are (virtualized) quad core X86-64 > machines running RHEL 6. Our code tree is currently on "locally > perceived" storage. We compiled GNU Make 4.2.1 from sources. > > Our main concern at this moment is the time needed for "nil > incrementals", i.e. the time needed to establish that nothing has > changed, so nothing needs to be done. If we put all dependencies in > the Makefile itself or in one single included makefile, we manage to > do a nil incremental in about 12 seconds. > > But we plan to use auto-generated dependencies and thus include a .d > file in our main Makefile for each target. Currently auto dependency > generation is possible for about 9 of our targets. Nil incremental > builds cost increases to about 140 seconds in that case, which is > quite unacceptable for our usage. We found that this overhead > increases approximately quadratically with the number of included > dependency files. > > It appears that this behavior is caused by the need to maintain the > variable MAKEFILE_LIST. The names of all included makefiles are > appended one by one to the ever growing string representing this > variable.This also explains why memcpy() and strlen() champion the > profiled runs we did and also the quadratic behavior we observed. When > we change the source (read.c) so that the MAKEFILE_LIST is not > maintained at all, the overhead is gone and we are back to about 12 > seconds again. > > Are there any ideas (or opinions) about how to get rid of this type of > undesirable overhead? One of our own ideas is to provide a special > variant of -include (called e.g. dinclude?), intended to include just > .d files, without maintaining MAKEFILE_LIST. On the other hand it > might be feasible to improve the efficiency of appending to a > variable. Any suggestions? The latter should be possible by accumulating the elements in a hash table or linked list and composing the resulting string afterwards, allocating it once and strcpying the elements into position. Meanwhile, I think having a $MAKEFILE_LIST value of over a million characters will cause problems when you try to use it. So it does seem to be a good idea to add some kind of option for curbing or preventing its creation. -- Reinier Post TU Eindhoven ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #52028] Preventing infinite recursions when make is invoked from recipes
On Fri Sep 15 01:47:31 2017, invalid.nore...@gnu.org (anonymous) wrote: [...] > Summary: Preventing infinite recursions when make is invoked from recipes [...] > Details: > > Consider this Makefile: > > a : > echo a1 > $(MAKE) b > echo a2 > > b : > echo b1 > $(MAKE) a > echo b2 > > Building either a or b will cause infinite recursion. Yes, this is a potential issue with recursive $(MAKE) invocations, but it is not a bug. > It is possible to work around this with a template, similar to the following: > > SHELL := bash > exportable = $(shell echo $(1) | sed 's%[^[:alnum:]_]%_%g') > define make > $(eval d := $(strip $(call exportable,$(1 > $(eval f := $(if $(strip $(2)), -f $(realpath $(strip $2 > if [ "$$_making_$(d)" != "$@" ]; then \ > export _making_$(d)="$@"; \ > $(MAKE) $(f) "$(strip $(1))"; \ > fi This is a bad idea, for several reasons: 1. It uses nonportable functionality. Some of that will go away when implemented directly in C code, but not all of it. How to implement realpath for arbitrary operating systems and arbitrary file systems? If it were easy enough, GNU Make would have had it a long time ago. 2. It's a hack; there will always be cases slipping through. It is fundamentally impossible to determine whether a call to $(MAKE) is recursive just by looking at the calling syntax. E.g., realpath doesn't look at hard links. 3. There is a better way. A much simpler way to stop infinite recursion is to pass a variable indicating the recursion depth and make recursive calls conditional on its value. The $(MAKELEVEL) variable is provided for that purpose, and it has been in GNU Make for a long time, see e.g. https://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_5.html#SEC50 Finally, 0. There are more reasons to avoid $(MAKE). Nonrecursive make can be faster and can track dependencies better, although it may not be wise to avoid $(MAKE) at all costs, see e.g. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/03/hadrian.pdf -- Reinier Post TU Eindhoven ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #46242] Race condition when input file is updated while compiling
> that make can set (to the newest dependency's time-stamp) and later > > read, or if make were to store this same datum in a separate database, > > it would solve your problem. It would also make it possible to have > > make rules that tentatively build the new file, compare to existing, > > replace if (meaningfully) different but only revise "up to date at" > > otherwise. > > Such a tiny "database" could indeed solve this problem without race > condition. I would be more than happy to see this implemented! It > wouldn't have to be a "database", just a simple ephemeral text file that's > removed on clean exit of make, listing all the currently running rules > that'd have to be rerun if this file exists on startup (meaning that the > previous run was interrupted or crashed). This is just one of many limitations you're going to run into. For instance, you might run into cases where the same file can have several stages of uptodateness (e.g. in LaTeX builds) or where you rely on a file *not* being present, or where your whole build process structure subtly depends on the setting of certain environment variables or properties of the system you're on, etc. Plenty of problems that require a lot of subtle Makefile hacking to get it right, when it is possible at all. This is just one of them. > > As you note, every command that might be used in a make rule would need > > to do this "right", which is a prohibitive requirement. > > > > Requiring every command that could be used as a make rule to abide by > > this is, again, prohibitive. [...] > > Some of these ideas I've thrown in might not work in practice, I agree. > > Please note that I had a simple propsal: re-check the timestamps of input > files when a rule completes and re-run (moving away or dating back the > previous output file first) if any of them changed. This would not elimite > the race condition completely, but would make the window magnitudes smaller > (e.g. fraction of a millisecond instead of 15 seconds), and as such, would > already be a great improvement! It would help, but more can be done. However, that will take you away from standard 'make', which is a concern in itself. See e.g. makepp: http://makepp.sourceforge.net/2.0/makepp_build_algorithm.html > cheers, > egmont -- Reinier Post TU Eindhoven ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Documentation Bug
On Wed Jul 8 11:02:55 2015, engg.kaus...@gmail.com (Pankaj Kaushik) wrote: Hi Team, There is documentation bug in make file pdf(see attachement) on Page no 2 under section 2.2 at below line. We split each long line into two lines using backslash/ Bug :- You mentioned forward slash (/) against backslash text. You are mistaken and you are misquoting. The text says: We split each long line into two lines using backslash/newline; this is like using one long line, but is easier to read. I agree that this '/' is rather cryptic. It must be read as 'followed by': We split each long line into two lines using backslash followed by newline; this is like using one long line, but is easier to read. Please correct it. It would be better to write 'followed by' instead of '/' to avoid this misunderstanding. Regards, Pankaj -- Reinier Post ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: make doesn't take the shortest stem
On Mon Jun 1 13:27:53 2015, psm...@gnu.org (Paul Smith) wrote: On Mon, 2015-06-01 at 13:54 +0200, Meir BENAYOUN wrote: Item: Bug Privacy: Public Component Version: 3.81 When several pattern rules match a target, the one with the shortest stem should be used as stated in the documentation: You are using GNU make 3.81 (released in 2006) but reading the documentation for the latest version of GNU make (4.1, released last fall). It would be really helpful if each page of this documentation reminded the readers of this fact. If they're like me, they typically arrive on those pages from a search engine and checking for differences between versions just doesn't occur to them, the more so because their version may well be the latest offered by their OS distribution, even when it is 3.81. Perhaps it is possible to include some kind of standard header? E.g. 'these pages document GNU Make 4.1' with a link to documentation of older versions. -- Reinier ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Visualisation of make files as graphs
On Mon Jan 12 19:11:20 2015, elfr...@users.sourceforge.net (SF Markus Elfring) wrote: You can use gmake --print-database -f Makefile and then write a script to convert that into .dot format which gephi will load up for you. Do you know a few scripts (or other software tools) which provide such a data format conversion? Yes. See a previous thread on this issue: https://lists.gnu.org/archive/html/help-make/2014-04/msg5.html Will it become easier to present and edit an overview of the involved build rule dependencies? Yes. But apart from that, you must think about what it is exactly that you want to visualize: the rules as they are in the Makefile, or the rule executions of a particular run of make. They can be very different. See that previous thread for details. Regards, Markus -- Reinier Post ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Dynamic evaluation of build scripts
On Mon Jan 12 13:14:02 2015, elfr...@users.sourceforge.net (SF Markus Elfring) wrote: GNU make is the only implementation of make that supports any GNU make functions, including $(eval ...), if that's what you mean. I hope that more software tools can cope with make file syntax and processing of corresponding GNU extensions. In fact, recursive variable expansion is about the only one of the techniques I discuss above which is widely implemented in other versions of make. I find it interesting which limitations from other approaches need to be also considered for the development of reasonably portable build scripts. Making your makefiles portable across make implementations isn't going to do much for portability. If you want portability, it's probably going to be better to just require GNU Make everywhere. You could even create a couple of rules that check whether GNU Make is being used, and if not, fetch, compile and install it, then invoke it on your real Makefile. That is going to do a lot more for portability than waiting for features to be ported across make implementations ever will. -- Reinier Post TU Eindhoven ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Dynamic adjustments of build dependencies for the number of available processors
On Mon Jan 5 20:06:01 2015, elfr...@users.sourceforge.net (SF Markus Elfring) wrote: So you have in your toolbox $(shell) and $(eval). I am not familiar enough with the second make function. http://www.gnu.org/software/make/manual/html_node/Eval-Function.html $(eval) lets you generate rules dynamically. Does it really support the generation of completely new build rules (instead of adjusting only recipes)? Yes, it does. An alternative is to generate a Makefile and include it into your main Makefile. In both cases you are generating and then evaluating make rules at runtime. -- Reinier ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: FW: make: Interrupt/Exception caught (code = 0xc00000fd, addr = 0x4217b3)
On Wed Nov 19 09:30:17 2014, h...@sorex.eu (Harald-René Flasch) wrote: I am curious that this bug (at least known since 2008 ...) in make.exe of WinAVR is still not fixed 2014/2015 ... I'm not, after looking at the WinAVR project page: the home page says a 2006 release is the current one, and the latest published download dates from 2010. The GNU Make it includes cannot be recent. Work has been done since to improve handling Windows paths. -- Reinier Post ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Make does not build a missing prerequisite.
On Thu Oct 9 11:31:46 2014, maxim.yegorush...@gmail.com (Maxim Yegorushkin) wrote: [...] On both machines make-4.0 was build from sources. The machine where make always succeeded runs Fedora 20, the other one runs CentOS-6.5. Strange... Indeed. Are the files by any chance on a remote filesystem such as NFS? -- Reinier ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Make does not build a missing prerequisite.
On Tue Oct 7 13:09:11 2014, maxim.yegorush...@gmail.com (Maxim Yegorushkin) wrote: My dependencies are: build/Linux-x86_64-64.g++-release/lib/libdata_access.so : build/Linux-x86_64-64.g++-release/obj-mt-pic/data_access/data_access.o build/Linux-x86_64-64.g++-release/obj-mt-pic/data_access/data_access.o : src/c++/data_access/data_access.cc src/c++/data_access/data_access.cc : src/c++/data_access/data_access.reflect.h src/c++/data_access/data_access.reflect.h : src/c++/data_access/data_access.h src/c++/reflect/generate.py This is not a complete list. What happens is that make correctly identifies that data_access.cc depends on data_access.reflect.h, finds an implicit rule that generates data_access.reflect.h, rebuilds the dependencies of data_access.reflect.h but neglects to build data_access.reflect.h itself. Really? That's not what I'm seeing below. Why does it not build data_access.reflect.h please? I am using GNU make-4.0. Below is the relevant bit from `make -r -d` output: Considering target file 'build/Linux-x86_64-64.g++-release/lib/libdata_access.so'. File 'build/Linux-x86_64-64.g++-release/lib/libdata_access.so' does not exist. [...] 'src/c++/data_access/data_access.reflect.h'. Pruning file 'src/c++/data_access/data_access.h'. Considering target file 'src/c++/reflect/generate.py'. Looking for an implicit rule for 'src/c++/reflect/generate.py'. Trying pattern rule with stem 'generate'. Trying rule prerequisite 'src/python/olivetree_c.py'. [...] Finished prerequisites of target file 'src/python/olivetree_c.py'. Must remake target 'src/python/olivetree_c.py'. cd src/python ln -fs olivetree_c.py.release olivetree_c.py Putting child 0x1e74d10 (src/python/olivetree_c.py) PID 4317 on the chain. Live child 0x1e74d10 (src/python/olivetree_c.py) PID 4317 Reaping winning child 0x1e74d10 PID 4317 Removing child 0x1e74d10 PID 4317 from chain. Successfully remade target file 'src/python/olivetree_c.py'. Considering target file 'src/python/olivetree_c.py'. File 'src/python/olivetree_c.py' was considered already. Finished prerequisites of target file 'src/c++/reflect/generate.py'. Prerequisite 'src/python/olivetree_c.py' of target 'src/c++/reflect/generate.py' does not exist. This is weird. You just 'created' it, except that you really didn't: all you did was create a symbolic link to what is supposedly a pre-existing file. There are two risks wih this: 1) Does that file actually exist? Make claims it doesn't. 2) Even if it exists, you didn't update its modification time; make will notice it's older than the target, so why should it remake the target? Must remake target 'src/c++/reflect/generate.py'. Successfully remade target file 'src/c++/reflect/generate.py'. Pruning file 'etc/rules.mk'. Finished prerequisites of target file 'src/c++/data_access/data_access.cc'. Prerequisite 'src/c++/data_access/data_access.reflect.h' of target 'src/c++/data_access/data_access.cc' does not exist. No need to remake target 'src/c++/data_access/data_access.cc'. Finished prerequisites of target file 'build/Linux-x86_64-64.g++-release/obj-mt-pic/data_access/data_access.o' Maxim -- Reinier Post TU Eindhoven ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug-fix release of GNU make
On Mon Sep 29 20:40:55 2014, f.heckenb...@fh-soft.de (Frank Heckenbach) wrote: Any news? In order to make it into Debian jessie, time is really getting short. Of course, you may not care much about Debian, but it's still a rather popular distro, and importantly, it's one of the slowest, so if nothing happens, Debian stable will contain a seriously broken (esp. WRT new features) make version for something like 2 years. What is more, other distributions, such as Ubuntu, are based on Debian: their packages are patched Debian packages. -- Reinier Post TU Eindhoven ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Parallel Build, but Not for the Command-Line Targets.
On Mon Aug 25 10:40:39 2014, ra...@inputplus.co.uk (Ralph Corderoy) wrote: Hi Reinier, Yes, but it's an idiomatic one, oft suggested; Unpack and run `./configure make all check install'. I don't get it. What is wrong with make -sj clean; make -sj all; make -sj check; make -sj install That doesn't do the same thing; `make all check install' stops if one of the targets fails to build, not proceeding to the next. You have to replace the `;' with `' in your version to achieve the same with the shell. (I pointed this out in my original email to the list.) Thanks. My apologies for the sloppy reading. To repeat, `./configure make all check install' is standard usage; -j breaks this. It would be nice if there was a simple way to achieve parallelism only within the build of each of the argv[] targets, not across them. Maybe an interesting use case could be shells that don't support ? (The CMD.EXE I just tried supports it, to my surprise.) Cheers, Ralph. -- Reinier ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Parallel Build, but Not for the Command-Line Targets.
On Sun Aug 24 12:33:41 2014, ra...@inputplus.co.uk (Ralph Corderoy) wrote: Hi Paul, It seems a design flaw that I must make -sj clean make -sj all make -sj check make -sj install Well, that's because you're only considering this use-case, Yes, but it's an idiomatic one, oft suggested; Unpack and run `./configure make all check install'. But, if you consider something like: make prog1 prog2 prog3 prog4 then it's clearly a design flaw if these programs are built serially. Oh sure, I wasn't trying to suggest that it's never wanted, just that the binary -j doesn't seem sufficient to cover common cases. I don't get it. What is wrong with make -sj clean; make -sj all; make -sj check; make -sj install ?? There is no easy way to do this in GNU make today. I don't see this as a convincing use case. -- Reinier Post ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Add makefile.mak to list of default makefiles
On Mon Jun 30 21:28:43 2014, j...@jguk.org (Jonny Grant) wrote: Hi Eli I have a few, but triggered by make -f makefile.mak. So it would be quite useful GNU Make could pick up the Windows makefile extension .MAK On non-Windows platforms I've seen .mk quite a few times, but never .mak. I would also rename README.W32 to be README_W32.txt Seconded. Regards, Jon -- Reinier Post ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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 https://lists.gnu.org/archive/html/bug-make/2014-05/msg00039.html. ___ Reply to this item at: http://savannah.gnu.org/bugs/?30381 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 in the XML. What I wanted was this: define futurebases $(shell xmllint --xpath print(//futurebase/@filename) $(1)) endef .SECONDEXPANSION: %.htb: %.xml $$(call futurebases, %.xml) $(HOFFMAN) -g $ It doesn't work. I don't think this is related. My -M patch supports using the same rule multiple times on a path when traversing the dependency graph. It takes the graph for granted, it just traverses more paths in it. What you need to do is determine the dependency graph dynamically. The problem is not how to traverse it, but how to construct it. This happens before the graph is traversed. My patch won't help you. Apparently, you have a command that, given an *.xml file, lists the dependencies of a corresponding *.htb file. You are trying to list these dependencies in the rule for making the *.htb file, so you can use them in the recipe. I think your basic approach is correct: with .SECONDEXPANSION, you *can* expand a list of dependencies on a per-target basis. However, some problems remain in the code above: 1) Your recipe uses $, that is, the first dependency only. Is your list always 1 long? If not, use $+ instead. Besides, $ is the *.xml file; I don't think you want to use that to create the *.htb file. 2) The %.xml argument to your call will just be %.xml. I've never used .SECONDEXPANSION, but judging by the manual http://www.gnu.org/software/make/manual/html_node/Secondary-Expansion.html I think you need to use $ here instead. I'm not sure if you have the right escapes to make everything expand at the right time. Specifically, you need a way to ensure the xmllint command is only invoked during the secondary expansion. This is above my head but it should be possible in principle. However you still end up with rules that contain *.xml dependencies that really aren't dependencies of the targets, but of the command used to list the dependencies. I think I'd take a different approach: generate the rules as a first phase. There are two basic approaches to doing this: A) Using $(eval): write a macro that generates a whole rule, then $(eval) a $(call) of that maccro for each of your *,xml files. B) Write a rule that generates a 1-rule makefile from a *.xml file using a regular recipe. That 1 rule creates the *.htb file from its dependencies. Then in your regular makefile either include all of those rules or invoke them with $(MAKE) -f. Reply to this item at: http://savannah.gnu.org/bugs/?30381 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- Reinier Post TU Eindhoven ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #40639] GNU Make with profiling information
On Wed Nov 20 22:47:20 2013, eddy.petri...@gmail.com (Eddy Petrișor) wrote: On Tue Nov 19 22:29:22 2013, Reinier Post wrote: Follow-up Comment #1, bug #40639 (project make): I have created a cleaned up rebased branch that contains only changes for the profiling feature so it can be easier to review. https://github.com/eddyp/make-profiler/tree/profile-rebase Please note this branch will be rebased. Use 'git pull --rebase' if you need to resync. Looks very useful! Can't this functionality be provided by a wrapper $SHELL? Sure, it's an extra exec(), but it will keep the make code base simpler. I'm not sure if I understand what you mean. Do you mean wrapping all target invokes in a $SHELL? Yes; something line /usr/bin/time. If that's the case, you don't get the actual/real-time measurement, and that might skew your profiling information. True. Hnow how much of a difference does it make? I have some build systems that can take easily over 12 hours to do a full build (several thousands of elfs in recursive make calls - I know that's bad, I am working on it), so any extra time waste just for the measurement can mean significant delays in getting the results. If it's 15 minutes, they are not the thing you want to optimize first. The build is probably running overnight anyway. Can you measure it? -- Reinier Post TU EIndhoven ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #39943] Add an alternative parsing mode that regards space and tab as identical tokens
On Thu Sep 5 08:18:51 2013, psm...@gnu.org (Paul Smith) wrote: On Thu, 2013-09-05 at 11:43 +0100, Tim Murphy wrote: The detection also appears to only work if the statement has a syntax error in it. Correct. If make can understand what the line is (it's a valid makefile syntax), then why would it assume that the programmer may have meant something different than what was typed? It should never make any such assumptions. It should not change the way in which it interprets makefiles. I think the right approach is the one used by gcc: have one or more options that issue warnings for specific 'code smells' Examples: - a rule target appearing on a line that starts with non-TAB whitespace - a rule directly followed by a line that starts with non-TAB whitespace - an assignment with trailing whitespace (I've been bitten by this in the past) A second approach is to add an option that spits out the input makefile with all whitespace omitted or reduced to a single space when doing so doesn't make a difference to make's parser. Having that option would also help in constructing pretty-printers for makefiles. Examples of potentially fishy syntax: + a rule target on a line that starts with whitespace + a rule without dependencies followed by a line starting with whitespace that does not contain an assignment We have, since 3.82 was released, a way of avoiding this problem with the .RECIPEPREFIX variable. I think that's the right way forward, rather than trying to introduce heuristics based on some idea of common styles, which will invariably be incorrect in some situations. I'm not sure - such a variable can be deeply hidden. There are a lot of possible things make could warn about, that it doesn't currently. I just think trying to have make attempt to understand the semantics of makefiles (what the programmer meant) will be wrong often enough that it won't be considered useful by most. The semantics of makefiles are not determined by what the programmer means, but by how make interprets them. The semantics depend on the syntax, which is determined by how make parses makefiles. The syntax is a mess; there's nothing make can do about that now. Make should not change the semantics or syntax of makefiles, but it can do more to clarify them; that's what warnings are for. -- Reinier Post http://www.win.tue.nl/~rp/ ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Another issue with -O?
Reading this discussion, as a bystander I can't help wondering whether the addition of -O is worthwhile. Unix tools are supposed to be small and dedicated. Using a separate utility seems to be a clean solution here, and that is fact how it was originally done: http://lists.gnu.org/archive/html/bug-make/2011-04/msg00018.html Using a separate utility is less performant and more cumbersome, but it is more modular. The semantics are clear. The utility can be documented and developed separately from GNU Make. As a GNU Make user I worry that with the -O option I won't be sure how it works. -- Reinier Post TU Eindhoven ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Quirk with rules producing multiple output files
On Thu Apr 11 12:47:56 2013, psm...@gnu.org (Paul Smith) wrote: On Thu, 2013-04-11 at 12:14 +0200, Reinier Post wrote: It's just a shorthand for writing a lot of identical rules; it does NOT mean that a single invocation if the rule will generate all three targets, which is what you are expecting. Incidentally: other workflow/inference languages can express this distinction perfectly and still allow the resulting specifications to be analyzed for proper termination (e.g. safe Petri nets, Datalog); I'd love to know of an alternative to make that is based on such a language, but it seems too much to ask for make to be extended in this way. I'm not sure exactly what you mean by this distinction, but GNU make already supports multi-target generators with pattern rules, as mentioned in the part of the email you clipped. So the basic infrastructure exists. There were proof-of-concept patches floating around to support it for explicit rules as well. Hmm, indeed: | /tmp % cat Makefile | %.1:; echo $*.1 for $@ $@ | %.e.1 %.f.1:; echo $*.1 for $@ $@ | %.c.1 %.d.1:; for f in $*.c.1 $*.d.1; do echo $$f for $@ $$f; done | %.ab.2: %.a.1 %.b.1; cat $+ $@ | %.cd.2: %.c.1 %.d.1; cat $+ $@ | %.ef.2: %.e.1 %.f.1; cat $+ $@ | /tmp % make -rR stage.ab.2 stage.cd.2 stage.ef.2 | echo stage.a.1 for stage.a.1 stage.a.1 | echo stage.b.1 for stage.b.1 stage.b.1 | cat stage.a.1 stage.b.1 stage.ab.2 | for f in stage.c.1 stage.d.1; do echo $f for stage.d.1 $f; done | cat stage.c.1 stage.d.1 stage.cd.2 | echo stage.1 for stage.f.1 stage.f.1 | cat stage.e.1 stage.f.1 stage.ef.2 | cat: stage.e.1: No such file or directory | make: *** [stage.ef.2] Error 1 | rm stage.a.1 stage.b.1 stage.c.1 | /tmp % I didn't realise make would skip the creation of stage.e.1; yet this is documented very clearly: http://www.gnu.org/software/make/manual/html_node/Pattern-Intro.html I thought this was just describing an optimization; I didn't realize it would actually affect the build process. Why does it work this way? What is a possible use case? I use symbolic intermediate targets a lot, but my targets in pattern rules are always real files. Or is it just intended as an optimization to avoid a stat() call? (I tried cvs annotate to find this out, but this documentation text is in r1.1 already.) In any case, it may be useful to also be able to state that a multi-target pattern rule only makes its actual target. With :: we can already have alternative rules for the same targets. Considering these features together, the rule selection and execution mechanism becomes difficult to understand; a formal model might help. Really the trickiest part is the user interface (makefile syntax): it must be backward-compatible with existing makefiles, or at least be sure to break virtually none of them. -- Reinier Post ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
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 are written that way, then you must have the feature enabled or the build will fail. And vice versa. A fair desciption, but only to make users who were already aware of the limitation that this feature removes. I wonder how many make users fall into that category. I used make (on and off) for 20 years without being aware of this limitation and discovered it only after a painful debugging process. Using -j also requires one's Makefiles to be written in a certain way. The main difference is that with -j, that 'certain' way isn't so easy to characterize. The reason I chose a command line option was my conviction that applying it isn't expected to break any existing Makefiles. You argue the feature should instead be treated like, say, secondary expansion. But how do I specify a numerical limit with a special target? For situations like that we don't want to force the user to have to specify options on the command line: these options need to be set within the makefile so the makefile author controls them. Also it's not clear that having the flag on the command line, where it will be passed recursively to sub-makes, won't break those sub-makes in some situations. The only makefiles that will break are those that at present rely on *failing* to apply an implicit rule due to not being able to use the same rule twice in the same chain, *and subsequently succeeding* in some other way. I'm not quite sure how that could happen in the first place, let alone how it would be applied as a feature when writing Makefiles. Shouldn't it at least be flagged with a warning when it occurs? And again, the same consideration applies to -j. There is a special target, .NOTPARALLEL, to override -j. Won't it be more natural to add such a target, .NOCHAINRULEREUSE or .CHAINRULEREUSE, in addition to -M? -- Reinier ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Quirk with rules producing multiple output files
On Thu Apr 4 16:17:58 2013, psm...@gnu.org (Paul Smith) wrote: This is expected behavior. A rule like: foo bar: @echo $@ is exactly the same thing, to make, as writing: foo: @echo $@ bar: @echo $@ It's just a shorthand for writing a lot of identical rules; it does NOT mean that a single invocation if the rule will generate all three targets, which is what you are expecting. Incidentally: other workflow/inference languages can express this distinction perfectly and still allow the resulting specifications to be analyzed for proper termination (e.g. safe Petri nets, Datalog); I'd love to know of an alternative to make that is based on such a language, but it seems too much to ask for make to be extended in this way. -- Reinier ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #712] GNU make can't handle spaces in pathnames
On Wed Feb 27 04:55:13 2013, invalid.nore...@gnu.org (Jian) wrote: Follow-up Comment #12, bug #712 (project make): What's a pity the bug/limitation has lasted more than 10 years! I'd like to share my workaround here. Thanks ... I don't think make can be expected to handle spaces in filenames because by design it relies on many other tools and scripts that cannot handle them or handle them in very idiosyncratic ways. You're in for a lot of trouble regardless of what make itself supports. Most Unix scripters know this before they even meet make, so they will already avoid using spaces (or other shell metacharacters) in filenames with make. However, it might be helpful to document any specific problems make itself has with such characters in filenames. -- Reinier ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #38433] Example for eval in documentation contains error with define
On Wed Feb 27 14:07:42 2013, guent...@gmail.com (Philip Guenther) wrote: Meanwhile, other people complain that the docs are too long; adding this feature was added in 3.8x throughout the guide just makes it longer and harder to read. It's not a costless addition. I completely disagree. Length is not an issue for documentation these days; reliability is. Right now I don't know whether documentation for make I find online matches the version I'm using. The documentation for the program on your box is on your box. WTP? It's usually easier to use Google these days. -- Reinier ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #38433] Example for eval in documentation contains error with define
On Wed Feb 27 17:02:03 2013, guent...@gmail.com (Philip Guenther) wrote: IMO, the suggestion that was proposed would reduce the overall usability of the manual and increase the confusion. I seen it tried in multiple ways** in other open source projects (and at my day job) and the results were never complete (there were nuances left out), took a large amount of effort, and always made a small set of people happy and a much larger set of people unhappy. Can you list one or two examples? Doesn't the amount of pain depend on how it's done? E.g. I can imagine that keeping a set of crosslinking footnotes of the form 'this has changed in version x, see the corresponding place in the x-1 docs' is a lot easier than trying to document several versions within the same document. [...] (Did the manual to your car or bike or computer include comments throughout it describing how this year's model is different from the previous years?) The problem is that people find documentation elsewhere and need to be aware which version of the bike or model it applies to. You can argue the issue rightfully belongs on someone else's plate, but the fact is that lots of make users appear to lose a lot of time over this, especially between 3.81 and 3.82 (I have been bitten by it as well). The prime purpose of documentation is to keep users from wasting time on figuring out things that can be looked up instead. -- Reinier ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: bug!!! error2!!!
On Sat Dec 8 16:45:45 2012, chn475...@gmail.com (李金魁) wrote: hello : i find a bug when i make install e1000e Gbit ethernet driver! as follows: [root@xdja src]# make install make -C /lib/modules/2.6.18-308.el5/build SUBDIRS=/root/64位CentOS 5.8 -B网卡驱动/igb-4.0.17/src modules make: invalid option -- ? [...] This is not a problem with make, but with the fact that the Makefile you're using doesn't support with spaces in filenames. This is not unique to that Makefile: I rarely see Makefiles that do support spaces in filenames. In fact, tools and scripts on Unix/Linux systems generally assume that you do not use any characters in filenames that have meaning to the shell, such as spaces, quotes, commas, etcetera. Rename your directory so it doesn't have any such characters in them. Then restart the buld process from scratch. -- Reinier ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[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 and documentation updates are missing. The idea is really simple: it replaces rule-in_use with rule-nr_reuses and compare that number against the value of -M. Note that -M without an argument means 'infinite' (same as for -j), so it allows rule chaining to go into an infinite loop. I will use this as a workaround for myself. I didn't use the idea discussed below (to allow recursion only when the dependency is shorter than the target) only because it was slightly harder to implement. (file #21887) ___ Additional Item Attachment: File name: make-3.82-M.diff-Nurd Size:5 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?30381 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 rule-cmds-floc. Would this be acceptable? ___ Reply to this item at: http://savannah.gnu.org/bugs/?30381 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #30606] mysterious behavior from $(if)
Follow-up Comment #8, bug #30606 (project make): I still haven't figured out how to fix my Makefile, so I'll take Paul up on his offer. I have a command to generate Graphviz input files from CSV files. My initial rule looked like this (but with a TAB, of course): %.dot: %.csv deps.pl $? $@ But the command has several options that I often use, in various combinations. The number of option values for each is finite, so I can just enumerate all possible combinations: %.dot: %.csv deps.pl $? $@ %-b.dot: %.csv deps.pl -b $? $@ %-a0.dot: %.csv deps.pl -a0 $? $@ %-a0-b.dot: %.csv deps.pl -b -a0 $? $@ %-a1.dot: %.csv deps.pl -a0 $? $@ %-a1-b.dot: %.csv deps.pl -b -a0 $? $@ %-d.dot: %.csv deps.pl -t. $? $@ %-d-b.dot: %.csv deps.pl -t. -b $? $@ (...) I'm trying to summarize these rules into a single one with a couple of nested foreach loops (or anything else) to loop over the possible option values (including nothing at all). Note that suffix and option aren't always identical. ___ Reply to this item at: http://savannah.gnu.org/bugs/?30606 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #30606] mysterious behavior from $(if)
Follow-up Comment #9, bug #30606 (project make): There are two -a0 in there that should be -a1, sorry ... ___ Reply to this item at: http://savannah.gnu.org/bugs/?30606 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 information which makes it difficult to allow the same rule to be used multiple times in the same inference chain. This would need to be split up. Due to the length of pattern_search() and the number of variables it uses, I won't attempt a patch at this time. ___ Reply to this item at: http://savannah.gnu.org/bugs/?30381 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #30606] mysterious behavior from $(if)
URL: http://savannah.gnu.org/bugs/?30606 Summary: mysterious behavior from $(if) Project: make Submitted by: r_p Submitted on: Fri 30 Jul 2010 07:07:46 PM GMT Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 3.81 Operating System: None Fixed Release: None Triage Status: None ___ Details: With the following Makefile (simplified from my actual Makefile): define T b := $(subst aa,,$(1)) yn := $(if $(strip $(b)),y,n) vs := $(vs) $(1):$(yn) endef tests := ab ab ab ab ab ab ab $(foreach t,$(tests), \ $(eval $(call T,$(t))) \ ) all:; @echo $(vs) I get the following output: +verbatim ab: ab:n ab:y ab:y ab:y ab:y ab:y What on earth is going on here? How can I fix it? (I put the $(strip) in to be sure it wasn't related to https://savannah.gnu.org/bugs/?5798 .) ___ Reply to this item at: http://savannah.gnu.org/bugs/?30606 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #30606] mysterious behavior from $(if)
Follow-up Comment #4, bug #30606 (project make): Never mind. The problem is that the variables are already expanded, and the functions called, when the template is being defined, when I expect them to be expanded only when it is called. Resolved by doubling all $s except those on the arguments. Sorry. ___ Reply to this item at: http://savannah.gnu.org/bugs/?30606 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #30370] add a shorthand syntax for foreach-eval-call
Follow-up Comment #7, bug #30370 (project make): Thanks for the comments. Yes, supporting multiple masks directly in the dependency matching, based on regular expressions, is fundamentally different from using dynamically set variables as pseudo-masks which is what the foreach-call-eval-solution amounts to; if this is adopted, a special syntax to improve readability of the latter type of solution won't be necessary. (Olexiy, my makefiles look a little like yours. Surely you don't consider your example fragment as easy to read or write as a solution with multiple masks would be?) ___ Reply to this item at: http://savannah.gnu.org/bugs/?30370 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 after variable expansion, so variables in rules won't complicate it. Things will only become complicated if less restrictive criteria are chosen instead; this can be done using techniques from formal language theory. Even that wouldn't necessarily bother the users of make, just the implementers, but there is something to be said for keeping things simple. Performance will only be lost for cases in which a second application of a rule during a search matches, and a dependency in that rule is shorter than the target, and that dependency doesn't eventually produce a viable chain; the overhead resulting from comparing against the targets in the chain thus far should be negligible. So it would be relevant to find existing makefiles in which such second applications already occur. (This can be done with a modified make.) The existing description at http://www.gnu.org/software/make/manual/make.html#Implicit-Rule-Search doesn't even mention the restriction that no chain may contain the same rule twice. To document it, 6d can be changed as follows: (6) d. For each prerequisite that does not exist, follow this algorithm recursively to see if the prerequisite can be made by an implicit rule, excluding the present rule from the list of rules to consider. A variant on my proposal: (6) d. For each prerequisite that does not exist, follow this algorithm recursively to see if the prerequisite can be made by an implicit rule, excluding the present rule from the list of rules to consider if and only if the present target is not shorter than the prerequisite. Here, comparing the lengths happens on the rule's first application instead of on later applications. This can only make a difference if targets and dependencies may contain different numbers of masks, which is not possible at present: sh touch bab ba% ; echo '%.foo: %a%; @echo making $@ from $?' | make -f - b.foo making b.foo from ba% (The second % is not interpreted as a mask.) Olexiy, I know I can hack around the issue in this way, but it makes my makefiles unmaintainable. As I said, I have lost time writing makefiles in the past because I wasn't aware of this restriction, and I'm sure others have, too. I also lose time because I have to work around it with such techniques. It's unclear how often such recursion would be used if it were possible. ___ Reply to this item at: http://savannah.gnu.org/bugs/?30381 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 made by an implicit rule, excluding the present rule from the list of rules to consider. (imagine verbatim off) A variant on my proposal: (imagine verbatim on) (6) d. For each prerequisite that does not exist, follow this algorithm recursively to see if the prerequisite can be made by an implicit rule, excluding the present rule from the list of rules to consider if and only if the present target is not shorter than the prerequisite. (imagine verbatim off) ___ Reply to this item at: http://savannah.gnu.org/bugs/?30381 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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 details of GNU make's operation. Safeguarding against infinite recursion is clearly useful - although GNU make has other ways of getting into infinite loops - but the rules can be relaxed in many different ways. A straightforward way to address your concern is to allow multiple iterations only when the newly considered targets are shorter than the ones considered in previous iterations of the rule in question. Personally, I'd be happy to see the check dropped completely, I know how to use make -d. The use cases I have for it arise when I use utilities that produce files of the same type as their input files; for instance, text processing utilities such as grep, sort, rev, uniq, join, cut, or image processing utilities like those of netpbm or ImageMagick. Complex processing chains can be built up with such utilities, and in such chains, it is sometimes useful to call the same rule multiple times. I'd rather just write rules that make sense and debug cases of infinite regress with make -d than use make -d to discover cases of make's built-in prevention and hack around it in my Makefile by artificially duplicating the rules and renaming some of the dependencies in question, as I'm doing now: %.sorted: % @sort $? $@ %.sorted2: % @sort $? $@ I'm not saying that this use is typical (although I've personally run into this limitation a few times in the past and only now realize what is going on), I'm just saying that it would be a lot easier to write such rule systems if GNU make didn't make it difficult. ___ Reply to this item at: http://savannah.gnu.org/bugs/?30381 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[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: http://savannah.gnu.org/bugs/?30381 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #30370] add a shorthand syntax for foreach-eval-call
Follow-up Comment #2, bug #30370 (project make): An example is at http://stackoverflow.com/questions/2880975/make-invoke-command-for-multiple-targets-of-multiple-files ___ Reply to this item at: http://savannah.gnu.org/bugs/?30370 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #30370] add a shorthand syntax for foreach-eval-call
Follow-up Comment #4, bug #30370 (project make): The request at stackoverflow.com describes what I really want. I intentionally phrased the request in such a way that a particular implementation was suggested in order to avoid the criticism that the idea is vague or infeasible. The syntax would have to be clear, general, cand backward compatible at the same time. H. Some extension to the $() syntax seems natural but I also like the idea of extending the % notation somehow. ___ Reply to this item at: http://savannah.gnu.org/bugs/?30370 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #30381] Don't avoid implicit rule recursion quite so soon.
URL: http://savannah.gnu.org/bugs/?30381 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 Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: None Operating System: None Fixed Release: None Triage Status: None ___ Details: This caught me by surprise (sh is my shell prompt here): sh echo foo foo sh echo '%.rev : %; rev $? $@' Makefile sh make foo.rev.rev make: *** No rule to make target `foo.rev.rev'. Stop. sh make foo.rev foo.rev.rev rev foo foo.rev rev foo.rev foo.rev.rev Come on, make(1)! Yes I'm asking you to apply a rule twice, but with a different target! This keeps biting me in the make file I'm writing at the moment. My proposal is to keep a stack of the targets, and only stop recursion if a target already occurs on the stack. Or least let me set a limit to how often you're willing to try this. ___ Reply to this item at: http://savannah.gnu.org/bugs/?30381 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #30370] add a shorthand syntax for foreach-eval-call
URL: http://savannah.gnu.org/bugs/?30370 Summary: add a shorthand syntax for foreach-eval-call Project: make Submitted by: r_p Submitted on: Tue 06 Jul 2010 03:22:58 PM GMT Severity: 3 - Normal Item Group: Enhancement Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: None Operating System: Any Fixed Release: None Triage Status: None ___ Details: No bug, but something that has been on my wishlist for some 20 years: In practically every Makefile I write, I want to parametrize rules with multiple variables. It would be incredibly nice to have a shorthand syntax for this, e.g. progs = dot neato circo fdp exts = emf ps png gif %-$(p:progs).$(x:exts): %.dot $(p) -T%(x) $? $@ instead of having to use ugly, verbose workarounds such as foreach-eval-call. ___ Reply to this item at: http://savannah.gnu.org/bugs/?30370 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #30370] add a shorthand syntax for foreach-eval-call
Follow-up Comment #1, bug #30370 (project make): -T%(x) should be -T$(x) ___ Reply to this item at: http://savannah.gnu.org/bugs/?30370 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
