[bug #31621] interaction of pattern rules and globs
Follow-up Comment #1, bug #31621 (project make): Forgot to post this: $ cat x.mk %/md5: %/sums/*.md5 echo action ___ Reply to this item at: http://savannah.gnu.org/bugs/?31621 ___ 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
Re: [bug #31614] allow spaces in target names
2010/11/10 Paul Smith psm...@gnu.org: However, this is not nearly the only problem with this suggestion. Adding support for whitespace inside filenames is actually extremely tricky, because almost all of make is really just text parsing, and all that parsing is whitespace-based. Hmm, right, I didn't realize this. Functions like sort, word and others would all need to recognize the escape, wildcard would need to return escaped spaces... And who knows what that ends up breaking. I wonder, is the stance that this can of worms is best left closed, or is that anything that would be desirable? PM ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
make-3.82 NEWS question
In the NEWS file for make-3.82 is this info about the wildcard function * WARNING: Future backward-incompatibility! Wildcards are not documented as returning sorted values, but up to and including this release the results have been sorted and some makefiles are apparently depending on that. In the next release of GNU make, for performance reasons, we may remove that sorting. If your makefiles require sorted results from wildcard expansions, use the $(sort ...) function to request it explicitly. It says Future but I am seeing this behavior in 3.82. It that correct? I built make-3.82 on this older system type Linux zephyr 2.4.21-47.ELsmp #1 SMP Wed Jul 5 20:38:41 EDT 2006 i686 i686 i386 GNU/Linux It is running on this newer system type Linux lwe127084 2.6.9-89.0.26.ELsmp #1 SMP Sun May 30 09:31:52 EDT 2010 i686 i686 i386 GNU/Linux This change is going to be a nightmare for us users. Things that have worked forever now break. The last thing people want to do is edit production code to fix things like this. Would it be possible to make this a compile option to keep old functionality or have to enable it to speed things up. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make-3.82 NEWS question
On Thu, 2010-11-11 at 12:46 -0800, Warren Dodge wrote: * WARNING: Future backward-incompatibility! Wildcards are not documented as returning sorted values, but up to and including this release the results have been sorted and some makefiles are apparently depending on that. In the next release of GNU make, for performance reasons, we may remove that sorting. If your makefiles require sorted results from wildcard expansions, use the $(sort ...) function to request it explicitly. It says Future but I am seeing this behavior in 3.82. It that correct? Yes: I meant to undo that change but due to some CVS fu before the release, my undo of that change did not make it into the official tarball even though the update of the NEWS file did. Sigh. So as it stands, the change IS in 3.82 even though the NEWS file says it isn't. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
