Re: GNU make release candidate 3.99.90 available
On Sat, 2013-05-18 at 14:20 +0300, Eli Zaretskii wrote: From: Paul Smith psm...@gnu.org Date: Fri, 17 May 2013 04:12:15 -0400 Hi all. The first release candidate for the next release of GNU make, GNU make 4.0, is now available for download: Paul, can you please add 4.0 to the list of versions accepted by the Savannah bug tracking UI, so that bugs fixed before the release could be marked as fixed in that version? Typically what I do is have all issues resolved before the release marked with SCM, then at release time I change all the bugs marked as fixed in SCM to be marked fixed in 4.0. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: GNU make release candidate 3.99.90 available
On Fri, 2013-05-17 at 19:42 +0200, Denis Excoffier wrote:
Compared with make-3.82, the new make-3.99.90 breaks those Makefiles,
like in tiff-v3.6.1 (rather old i know, before 2003 at least), that
use the construction:
make -${MAKEFLAGS}
Hrm. This is actually specifically discouraged by the documentation.
However reading the POSIX standard shows that make is required to accept
this format, at least for standard arguments.
The problem is that the new flags we're adding are causing some pain; I
may need to tweak the algorithm that generates the MAKEFLAGS values.
I'll take another look at this.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: GNU make release candidate 3.99.90 available
On Fri, 2013-05-17 at 22:35 +0300, Eli Zaretskii wrote: When a dynamic extension is being remade, it is unloaded by calling unload_file. The latter looks up its argument in a linked list of loaded objects. Now, unload_file is called with file-name as its argument; is it 100% sure that this string will be identical to what was used in load_file? IOW, do we never change relative file names to absolute ones (or vice versa), mirror backslashes to forward slashes, or do any other transformations that produce a different string which points to the same file? If we can do such transformations, unloading will be unreliable. Yes, I thought about this as I was making the change. I believe it is true that the initial pathname will be identical. However there are ways in which the path might change: for example through use of VPATH. I'm not exactly sure how all this will play out so it needs some testing. I still don't want to add back the pointer to the struct. Memory usage by GNU make is becoming a sore spot, especially as larger and larger build systems start to move to non-recursive make. If necessary we'll need to make the list a bit more sophisticated so we can add new elements to it if/when we rename targets. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: GNU make release candidate 3.99.90 available
Hi Paul, Paul D. Smith psm...@gnu.org writes: There's still a serious regression in the code due to the change in pattern rule searching added in 3.82. In some (not that unusual) circumstance GNU make will chew _enormous_ amounts of memory, compared to what it used to use in 3.81 and below. This is because in the current algorithm, every single time we do an implicit rule search and compute possible target and dependency names they are all added to the string cache, even if they are deemed to be useless and not needed because that implicit rule is not chosen. In cases where there are lots of futile implicit rule searches the string cache gets bloated with these useless strings. Seeing that you haven't fixed it for 4.0, I assume there is no obvious or easy solution ;-). I care a lot less about memory than about speed and I believe it is the same for most other users these days. So maybe we should try to tune the hash (i.e., the number of buckets) so that lookup doesn't suffer too much? Also I've not seen Debian experimental pick up release candidates like this in the past; is that something they do? I wrote to the maintainer. Let's see what he says. Personally I think getting into something like Gentoo may be more beneficial since their package management tool is running make quite a bit. Yes, though I would imagine they would be a lot more reluctant to do this since in their case make runs on the user machine, not on the build server (where any regressions will be quickly detected and reported). Boris -- Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog Compiler-based ORM system for C++ http://codesynthesis.com/products/odb ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: GNU make release candidate 3.99.90 available
On Mon, 2013-05-20 at 11:09 -0400, Boris Kolpackov wrote: This is because in the current algorithm, every single time we do an implicit rule search and compute possible target and dependency names they are all added to the string cache, even if they are deemed to be useless and not needed because that implicit rule is not chosen. In cases where there are lots of futile implicit rule searches the string cache gets bloated with these useless strings. Seeing that you haven't fixed it for 4.0, I assume there is no obvious or easy solution ;-). I've poked at it a few times for just a couple of minutes but nothing trivial occurred to me. I was hoping you'd look at it :-p :-). I don't think it's SO difficult to fix but it can be fiddly--this entire area is a bit fiddly. I care a lot less about memory than about speed and I believe it is the same for most other users these days. So maybe we should try to tune the hash (i.e., the number of buckets) so that lookup doesn't suffer too much? The complaint I got was that GNU make 3.82 was using 100's of MB of RAM more than it used to and this was the problem, not the lookup time. I'm not really jazzed about adding a workaround like this; the strcache is intended only for truly static strings that should exist for the lifetime of the process. It shouldn't be abused that way IMO. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[bug #39028] [patch] fix and uniformize four error messages
URL: http://savannah.gnu.org/bugs/?39028 Summary: [patch] fix and uniformize four error messages Project: make Submitted by: bens Submitted on: Mon 20 May 2013 09:27:25 PM CEST Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: SCM Operating System: Any Fixed Release: None Triage Status: None ___ Details: One error message says option requires a positive integral argument, where I think integer is meant instead of integral. Attached patch fixes that, decapitalizes another message, removes an inconsistent period from a third one, and adds two clarifying words to a fourth. ___ File Attachments: --- Date: Mon 20 May 2013 09:27:26 PM CEST Name: 0001-Fix-wording-of-two-error-messages-and-uniformize-two.patch Size: 2kB By: bens http://savannah.gnu.org/bugs/download.php?file_id=28120 ___ Reply to this item at: http://savannah.gnu.org/bugs/?39028 ___ 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 #39028] [patch] fix and uniformize four error messages
I think integer is meant instead of integral. Eg C99 uses integral as an adjective meaning of integers, per 1 b (1) from http://www.merriam-webster.com/dictionary/integral. My googling suggests that the OP's right, though, that the patched would be more widely understood. -Original Message- From: bug-make-bounces+martin.dorey=hds@gnu.org [mailto:bug-make-bounces+martin.dorey=hds@gnu.org] On Behalf Of Benno Schulenberg Sent: Monday, May 20, 2013 12:27 To: Benno Schulenberg; psm...@gnu.org; bo...@kolpackov.net; bug-make@gnu.org Subject: [bug #39028] [patch] fix and uniformize four error messages URL: http://savannah.gnu.org/bugs/?39028 Summary: [patch] fix and uniformize four error messages Project: make Submitted by: bens Submitted on: Mon 20 May 2013 09:27:25 PM CEST Severity: 3 - Normal Item Group: None Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: SCM Operating System: Any Fixed Release: None Triage Status: None ___ Details: One error message says option requires a positive integral argument, where I think integer is meant instead of integral. Attached patch fixes that, decapitalizes another message, removes an inconsistent period from a third one, and adds two clarifying words to a fourth. ___ File Attachments: --- Date: Mon 20 May 2013 09:27:26 PM CEST Name: 0001-Fix-wording-of-two-error-messages-and-uniformize-two.patch Size: 2kB By: bens http://savannah.gnu.org/bugs/download.php?file_id=28120 ___ Reply to this item at: http://savannah.gnu.org/bugs/?39028 ___ 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 ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: GNU make release candidate 3.99.90 available
On 2013-05-20 15:16, Paul Smith wrote:
On Fri, 2013-05-17 at 19:42 +0200, Denis Excoffier wrote:
Compared with make-3.82, the new make-3.99.90 breaks those Makefiles,
like in tiff-v3.6.1 (rather old i know, before 2003 at least), that
use the construction:
make -${MAKEFLAGS}
Hrm. This is actually specifically discouraged by the documentation.
However reading the POSIX standard shows that make is required to accept
this format, at least for standard arguments.
Perhaps the space in front of --jobserver-fds in MAKEFLAGS (make-3.82),
together with the do-nothing - target are already there to satisfy the
POSIX standard: just put the space back and that's it?
In the mean time i discovered a few minor documentation bugs:
- in doc/main.texi:
- in the 'Options Summary' section, list the new '-O' before '-p'
- replace The end of of this paragraph with The end of this
paragraph
- in variable.c:
- replace but the the rest of the chain with but the rest of the
chain
- in readme.vms:
- replace That deletes the them with That deletes them
Regards,
Denis Excoffier.
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #39028] [patch] fix and uniformize four error messages
On Mon, May 20, 2013 at 5:53 PM, Edward Welbourne e...@chaos.org.uk wrote: I think integer is meant instead of integral. 'integral' is the adjective form of 'integer', so, in context, it is correctly used. Eg C99 uses integral as an adjective meaning of integers, C99 and Merriam Webster, Oxford, etc... How about using plain language and calling it a whole number instead of using jargon ? How about not catering to the lowest common denominator and devolving to baby-speech for fear that someone may be intimidated by a dictionary ? Norbert ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #39028] [patch] fix and uniformize four error messages
How about using plain language and calling it a whole number instead of using jargon ? How about not catering to the lowest common denominator and devolving to baby-speech for fear that someone may be intimidated by a dictionary ? Saying what you mean in the plainest terms possible isn't baby-talk and isn't about being intimidated by a dictionary: it's about communicating as clearly and directly as possible. Using jargon is great when it actually adds something but is mere obfuscation the rest of the time (often with a side order of patting self on the back for knowing a way of saying things that some others will find it harder to follow). In paticular, in the case of integral, there is a second meaning of the word (go on, check that dictionary, in case you've forgotten your calculus) which creates a (completely wanton, given that there's a plainer term for a number being whole) potential for confusing readers. Even transient confusion disrupts the flow of reading (as does having to look a word up in a dictionary, for that matter). Plain language aids all readers, Eddy, a mathematician. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
