Re: Undesirable overhead in GNU Make 4.2.1.

T 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

or 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

Re: [bug #46242] Race condition when input file is updated while compiling

[...] > > 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 th

Re: Documentation Bug

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 '/&#

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

Re: Visualisation of make files as graphs

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.

Re: Dynamic evaluation of build scripts

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

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 ge

Re: FW: make: Interrupt/Exception caught (code = 0xc00000fd, addr = 0x4217b3)

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/mailm

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 remot

Re: Make does not build a missing prerequisite.

erate.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

ne 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. -

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; mak

Re: Parallel Build, but Not for the Command-Line Targets.

. 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

imes, 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 . ___ Reply to this

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

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> > &g

Re: [bug #40639] GNU Make with profiling information

On Wed Nov 27 09:56:55 2013, eddy.petri...@gmail.com (Eddy Petrișor) wrote: > Pe 25.11.2013 11:09, "Reinier Post" a scris: > > > > Can't this functionality be provided by a wrapper $SHELL? > > > > Sure, it's an extra exec(), > > > > but i

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 cha

Re: [bug #40639] GNU Make with profiling information

hub.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 t

Re: [bug #39943] Add an alternative parsing mode that regards space and tab as identical tokens

ful 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

Re: Another issue with -O?

w 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 thr

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

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

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

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. L

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 filen

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 > m

Re: [bug #17873] .NOTPARALLEL enhancements

UTEX: this that > .MUTEX: yours mine Yikes - isn't make complicated enough? Isn't there a straightforward way to handle this that better fits with the Unix toolbox philosophy? E.g. by using a wrapper command to handle the mutual exclusion? Something like with-pidfile /tmp/ld.pid

[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 #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: ___ Message sent v

[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 $? > $@

[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 #31002] make picks wrong pattern rule

Follow-up Comment #8, bug #31002 (project make): My vote for reverting this change. Incomprehensible webs of legacy makefiles are indeed a major issue. ___ Reply to this item at: _

[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.

[bug #30606] mysterious behavior from $(if)

Follow-up Comment #1, bug #30606 (project make): The problem is not with $(if) as I thought: replacing it with ifeq ($(b),ab) yn := y else yn := n endif produces the same output. ___ Reply to this item at:

[bug #30606] mysterious behavior from $(if)

URL: 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

[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 #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-soluti

[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 w

[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:

[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.

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

[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: ___ Message sent via/by Savannah http://savannah.

[bug #30370] add a shorthand syntax for foreach-eval-call

URL: 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: