believe if you find any of -j,
--jobs, or --jobserver-fds in $(MAKEFLAGS) the build is parallel.
Since the latter two both match --jobs%, this should boil down to two
nested findstring function calls on the MAKEFLAGS value.
David Boyce
___
Bug-make mailing
mapping
pathnames to file descriptors, but I don't see a use case for varying
the sync file path.
(d) Documentation is TBD but I'll wait and see if the patch is wanted
first. Current version attached, with test makefile.
David Boyce
make-sync.patch
Description: Binary data
Makefile.synctest
On Tue, Apr 12, 2011 at 1:46 PM, David Boyce david.s.bo...@gmail.com wrote:
So I've made a proof-of-concept patch
against 3.82.90 which seems to work without that overhead and my
question is, would this be of interest towards 3.83?
Ping?
The original patch attachment was made by hand using
On Thu, Apr 14, 2011 at 1:29 PM, Paul Smith psm...@gnu.org wrote:
I've looked at it and as a concept I don't have too many issues with it
Thanks.
One example: I think saving stdout and stderr to different files and
then printing them separately is problematic; consider if your recipe
prints
On Thu, Apr 14, 2011 at 1:48 PM, Eli Zaretskii e...@gnu.org wrote:
David, can you explain why you needed to lock the files? Also, what
region(s) of the file you are locking? fcntl with F_WRLCK won't work
on Windows, so the question is how to emulate it.
I was about to write this up but I see
On Thu, Apr 14, 2011 at 2:10 PM, Paul Smith psm...@gnu.org wrote:
There is no specific region of the file that's locked: the lockfile is
basically a file-based, system-wide semaphore.
Yes, it's conceptually a semaphore. In fact a Windows port might
prefer to use real semaphores. The reason I
On Thu, Apr 14, 2011 at 3:00 PM, Eli Zaretskii e...@gnu.org wrote:
Yes, but a few words about how is this semaphore supposed to get job
done, and in fact what kind of synchronization will this bring to
Make, would be appreciated. I don't think you described the feature
too much in your
On Thu, Apr 14, 2011 at 3:08 PM, David Boyce david.s.bo...@gmail.com wrote:
On Thu, Apr 14, 2011 at 2:10 PM, Paul Smith psm...@gnu.org wrote:
I'm not sure I like the idea of having to define a lockfile to enable
this feature though. It feels a little too much like exposing the
implementation
On Fri, Apr 15, 2011 at 6:45 AM, Eli Zaretskii e...@gnu.org wrote:
I lack the higher-level picture. Can you describe in a few words how
will this work in a running Make? I don't mean the details of how
files are locked and unlocked (I understand that part), I mean the
larger picture, like
On Thu, Apr 14, 2011 at 4:30 PM, David Boyce david.s.bo...@gmail.com wrote:
I don't know why this hasn't occurred to me or the authors of similar
programs before, but it appears to be possible to get a lock on any
writable file descriptor - for instance stdout or stderr, or one
On Fri, Apr 15, 2011 at 9:48 AM, Eli Zaretskii e...@gnu.org wrote:
So effectively, whenever a job finishes, its parent Make takes the
semaphore, outputs all of the output of that job to the screen, then
releases the semaphore, is that right?
Yes, exactly.
And how do you communicate the name
On Fri, Apr 15, 2011 at 11:09 AM, Eli Zaretskii e...@gnu.org wrote:
But this new option uses up 2 additional files per job, doesn't it?
One or two, as discussed elsewhere in this thread.
Each sub-Make inherits all the file descriptors of all its parents,
grandparents, etc. If a sub-Make was
On Fri, Apr 15, 2011 at 1:03 PM, Eli Zaretskii e...@gnu.org wrote:
Can Make be invoked with its stdout closed by the parent process? If
it is, will this still work?
I've tried to code it such that if anything goes wrong setting up the
sync, of which a closed stdout would be one example, it
Here's an updated version which is much closer to done at least from
my POV. I believe most of the requested improvements are there, the
semaphore code is factored, there's even a start on documentation.
Despite what was said about ifdefs before, the entire patch is
currently enclosed in #ifdef
On Tue, Apr 19, 2011 at 10:13 AM, Edward Welbourne e...@opera.com wrote:
How about if we introduce a variable that can be set for specific
targets (using the target-specific variable mechanism). Targets that
set this variable to some predefined value will not have their output
redirected, so
On Tue, Apr 19, 2011 at 11:06 AM, David Boyce david.s.bo...@gmail.com wrote:
Here's an updated version which is much closer to done
Ignore this version, I found a bug :-(
David
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman
URL:
http://savannah.gnu.org/bugs/?33134
Summary: spurious error when stdout is already closed
Project: make
Submitted by: boyski
Submitted on: Thu 21 Apr 2011 01:03:09 AM GMT
Severity: 3 - Normal
Item
On Wed, Apr 20, 2011 at 9:58 PM, Philip Guenther guent...@gmail.com wrote:
Could you explain why you think that's spurious? Make wanted to write
date to stdout and the write failed. Seems legit to me.
That's actually not what generates the error message. I'm not sure why
it doesn't happen the
On Thu, Apr 21, 2011 at 1:48 AM, Philip Guenther guent...@gmail.com wrote:
[...]
All quite true and admirably researched but this is not a
standards-lawyering exercise, it's a software-engineering issue.
I can't remember how many installers I've run which, when cancelled,
finish by saying ERROR
Follow-up Comment #1, bug #33134 (project make):
Note that there is a thread on the bug-make mailing list discussing this in
some detail:
http://lists.gnu.org/archive/html/bug-make/2011-04/msg00077.html
___
Reply to this item at:
On Thu, Apr 21, 2011 at 11:29 AM, Philip Guenther guent...@gmail.com wrote:
On Thu, Apr 21, 2011 at 3:50 AM, David Boyce david.s.bo...@gmail.com wrote:
All quite true and admirably researched but this is not a
standards-lawyering exercise, it's a software-engineering issue.
Why are you
I've filed this as an enhancement request
(https://savannah.gnu.org/bugs/index.php?33138) for better tracking.
Unfortunately there's a typo in the headline which I can't fix.
David
___
Bug-make mailing list
Bug-make@gnu.org
Follow-up Comment #2, bug #33134 (project make):
My original one-line patch had two mistakes, which may be a record! In the
course of work for enhancement #33138 I made a macro:
#define STREAM_OK(strm) ((fcntl(fileno((strm)), F_GETFD) != -1) || (errno !=
EBADF))
whose logic would be much better
URL:
http://savannah.gnu.org/bugs/?33138
Summary: .PARLLELSYNC enhancement with patch
Project: make
Submitted by: boyski
Submitted on: Thu 21 Apr 2011 04:17:07 PM GMT
Severity: 3 - Normal
Item Group:
Follow-up Comment #1, bug #33138 (project make):
Latest patch attached. This works well in my tests on Solaris and Linux. I
know of no reason it wouldn't work the same on any POSIX platform, and it's
ifdef-ed so as to not break the build on any non-POSIX platform. A start on
documentation is
On Tue, May 3, 2011 at 1:33 AM, Paul Smith psm...@gnu.org wrote:
I wonder if we can figure out a way to make this work better, as Eli
asked. Can we work out a way to handle normal rules (rules with +
or $(MAKE)) and sub-make rules differently, so that output from normal
rules wasn't collected
On Tue, May 3, 2011 at 1:20 PM, Paul Smith psm...@gnu.org wrote:
In that way, SYNC is a feature that the makefile USER selects, or not,
and not something the makefile AUTHOR would choose.
Does that make sense?
It makes perfect sense when you put it that way and I agree wrt to
both .ONESHELL
Follow-up Comment #6, bug #33034 (project make):
In fairness, this is a special situation. I have the same problem as tz, and
I expect quite a few other people do too.
My company makes drivers. The corollary is that we keep dozens if not hundreds
of entire Linux kernel source build trees going
trimpath; more
mnemonic, more standard.
David Boyce
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
in the manual?
Lexical may be technically correct but ASCII is more precise.
David Boyce
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
would be more
useful. I'm pretty sure ecmake does something like that. Anyway, I
think that would have more general utility than colorization per se.
-David Boyce
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
.
-David Boyce
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Judging from the outpouring of support I received when I made the same
suggestion/offer :-( I'm unsurprised at seeing no public response to
yours either. But disappointed. I agree that this is a real problem
which does not seem to resonate with those not directly affected by
it.
I think the best
On Mon, Nov 14, 2011 at 4:29 AM, Atte Peltomäki atte.peltom...@iki.fi wrote:
Nice work. Your implementation seems much more refined than mine. Only
one thing catches my attention; your version doesn't seem to properly
preserve the original line ordering between stdout and stderr. I suggest
URL:
http://savannah.gnu.org/bugs/?35063
Summary: Suggest conventional $(%XX) syntax for special
characters
Project: make
Submitted by: boyski
Submitted on: Wed 14 Dec 2011 02:27:53 AM GMT
Severity: 3 - Normal
will enjoy the symmetry, others will still see the common sense
in it.
-David Boyce
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
are freed, but I couldn't find any. Also this
over-allocates new_argv a bit in the cause of simplicity.
-David Boyce
Index: job.c
===
RCS file: /sources/make/make/job.c,v
retrieving revision 1.215
diff -u -r1.215 job.c
--- job.c
Follow-up Comment #4, bug #35063 (project make):
I don't agree with this, and I don't know what you mean about altering the
basic syntax. The original proposal makes no change to syntax (although I see
that I used the word incorrectly in the subject line), it adds a new range of
built-in
Follow-up Comment #6, bug #35063 (project make):
I think the root of our disagreement is in the goals. This is not at all about
adding url encode/decode capability to make; it's about a consistent, safe way
of getting special characters past the make parser and I suggested url
encoding (aka
URL:
http://savannah.gnu.org/bugs/?35397
Summary: make bug with ONESHELL and SHELLFLAGS
Project: make
Submitted by: boyski
Submitted on: Sun 29 Jan 2012 08:22:36 PM GMT
Severity: 3 - Normal
Item Group: Bug
to make a case in favor of doing
something special but either way it would be good to get the behavior
on the record.
David Boyce
On Sun, Jan 29, 2012 at 3:02 PM, Paul Smith psm...@gnu.org wrote:
On Mon, 2012-01-23 at 09:52 -0800, Lawrence Ibarria wrote:
I do like this suggestion, feels quite clean
semantics are specified by make (and thus portable),
not deferred to the platform or filesystem.
Again this is not a request per se, just something to think about
before semantics are set in stone.
-David Boyce
___
Bug-make mailing list
Bug-make@gnu.org
https
. And it's safely atomic because the file
has the same contents whether the write succeeds or fails.
A proof-of-concept patch is attached along with a demo makefile.
-David Boyce
Makefile
Description: Binary data
func_file-dsb.diff
Description: Binary data
URL:
http://savannah.gnu.org/bugs/?35485
Summary: New $(.MFDIR) built-in variable
Project: make
Submitted by: boyski
Submitted on: Wed 08 Feb 2012 06:30:41 PM GMT
Severity: 3 - Normal
Item Group: Enhancement
pathnames ar recorded as used, which means you can get a mix
of absolute and relative and non-canonical names like
../../lib/libfoo/../../cmd/blah.mk. Absolute paths in particular can
get quite long. But this is unlikely to happen - have you tried
simplifying as below?
-David Boyce
URL:
http://savannah.gnu.org/bugs/?35493
Summary: Provide access to existing platform type data via a
builtin variable
Project: make
Submitted by: boyski
Submitted on: Thu 09 Feb 2012 05:08:57 PM GMT
Severity: 3 - Normal
Follow-up Comment #1, bug #35485 (project make):
T Murphy says:
I think that getting the directory of the current makefile is useful although
I am sure my team have had trouble with $(abspath) and the way it works in
some situations on windows (unfortunately our stuff has to work on both) - it
Follow-up Comment #3, bug #35485 (project make):
I'm not sure how much more specific I can be than saying that it's just
shorthand for $(abspath $(dir $(lastword $(MAKEFILE_LIST but let me try
to elaborate.
First, the variability of .MFDIR would be precisely the same as that of
MAKEFILE_LIST
Follow-up Comment #5, bug #35485 (project make):
I don't think the stack-based approach is actually more runtime or space
intensive ...
I don't think so either. I just meant it would be a more intrusive change in
terms of diff size than the one-liner proposed here. But if you're that it's
not,
?
-David Boyce
On Thu, Apr 5, 2012 at 1:12 PM, Tim Murphy tnmur...@gmail.com wrote:
Hi,
On 5 April 2012 20:52, Lawrence Ibarria libar...@nvidia.com wrote:
I like this idea quite a bit.
I see this as still work in progress to define what type of functions the
plugins can have.
Maybe they can even
.
-David Boyce
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
On Fri, Apr 6, 2012 at 12:40 PM, Eli Zaretskii e...@gnu.org wrote:
Date: Fri, 6 Apr 2012 12:08:33 -0400
From: David Boyce david.s.bo...@gmail.com
Cc: bug-make@gnu.org bug-make@gnu.org
Apropos of this, the Apache Portable Runtime has a nice abstraction
over dlopen and LoadLibrary
On Fri, Apr 6, 2012 at 5:36 PM, Tim Murphy tnmur...@gmail.com wrote:
I had a little look at libtdl. To be brutal I thought that using
dlopen/LoadLibrary directly was *much* easier. There isn't really
anything madly complicated about what's being done.
To clarify: when I originally spoke
Even with GNU make as it stands, couldn't you emit your rules in the
form of variables, override them at will, and eval() them at the end?
E.g.
define ruleA
version 1
endef
then later...
define ruleA
version 2
endef
$(eval $(call ruleA,...))
-David Boyce
On Fri, Aug 10, 2012 at 12:36 PM
On Fri, Aug 10, 2012 at 2:38 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
I have no answer for that, lacking any knowledge about GNU make
internals; I guess the make developers here will be in a better
position to answer my question.
Yes, and I hope you get your feature. But
Follow-up Comment #4, bug #33138 (project make):
This is the original author. I've become very busy at my day job in the last
year or two so I've lost track of this. Thanks for picking it up and improving
it. I haven't had time to look at your new patch yet, and not sure when I
will, but here are
Follow-up Comment #7, bug #33138 (project make):
I agree this seems useful. However, since it would involve changes
to existing code which are not strictly needed...
Not functional changes, just a little refactoring, and adding a new reliance
on tmpfile() may cause more stress to ports than
fixed in the last
~7 years.
David Boyce
On Mon, Jan 7, 2013 at 10:17 AM, Ian Lynagh ig...@earth.li wrote:
Hi all,
I've got a makefile for a large project which appears to send make into
an infinite loop. I wonder if anyone could help me work out what is
going wrong, and how to fix
On Tue, Jan 8, 2013 at 8:37 AM, Ian Lynagh ig...@earth.li wrote:
Well, ideally I'd like to find a solution that doesn't require all the
users to install a newer make. But I'll do some more diagnosis and see
what I find.
Yes. If it's a fixed bug then a little binary searching or a walk
through
] Terminated
Terminated
I implemented the replacement shell in Python but it could use any
language. You just need to kill the process group once the first
recipe fails.
-David Boyce
On Fri, Jan 11, 2013 at 9:38 AM, Oleksandr Gavenko gaven...@gmail.com wrote:
On 2013-01-10, jungsoo.son wrote:
I
the
pressure to implement it with new GNU make syntax and makes the new feature
less likely to happen. However, it would still be best if GNU make had
(optional) native support.
David Boyce
On Wed, Jan 23, 2013 at 10:01 PM, toby cabot t...@caboteria.org wrote:
Hi Folks,
Greetings from the GNU Volunteer
The INSTALL document is for people who just download the standard source
tarball. I suspect there's a README.git for people doing a git clone; at
least there used to be a README.cvs for CVS users.
-David Boyce
On Fri, Feb 15, 2013 at 4:15 PM, dave kerns invalid.nore...@gnu.org wrote:
Follow
). Notice the dropdown at the top left
where you get to pick the version you care about.
David Boyce
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
in the original patch I sent
in.
-David Boyce
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
at once.
-David Boyce
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
On Thu, Apr 18, 2013 at 2:39 PM, Frank Heckenbach f.heckenb...@fh-soft.dewrote
This might be right (I was just objecting to your claim that it was
necessarily so on any 32-bit Unix), and I'd prefer to use fd's
anyway.
Well ... Linux is not Unix, as partisans will proudly tell you, so
this to
be easier and more natural on Windows than Unix. All that's required is to
choose a semaphore to synchronize on, dump output to temp files, and copy
it to stdout/stderr only after acquiring the semaphore. And remove the temp
files of course.
-David Boyce
On Tue, Apr 23, 2013 at 10:50 AM, Eli
On Tue, Apr 23, 2013 at 12:04 PM, Paul Smith psm...@gnu.org wrote:
I'm not sure if the lock locks the FD (so that if you dup'd the FD but
it still pointed to the same output, you could take exclusive locks on
both), or if it locks the underlying resource.
I'm pretty sure it's the underlying
On Wed, Apr 24, 2013 at 10:26 AM, Tim Murphy tnmur...@gmail.com wrote:
I would suggest pretending that one has semaphores first with some nice
little abstraction and then implementing them in the best way the platform
has to offer.
How about we introduce functions called acquire_semaphore()
On Sun, Apr 28, 2013 at 1:34 AM, Paul Smith psm...@gnu.org wrote:
I'm not excited about that term (job); it's kind of accurate, but in
the documentation for example we're really mushy about exactly what a
job is, vs. a recipe or a command line etc. I'd like to pick some
terms for this, define
On Mon, Apr 29, 2013 at 4:34 PM, Paul Smith psm...@gnu.org wrote:
Plus on UNIX any extension is acceptable since we're using dlopen()
(even with the normal linker you can give any library name you want,
it's only the -l flag that makes assumptions). Maybe someone wants to
write pattern rules
On Mon, Apr 29, 2013 at 7:53 PM, Paul Smith psm...@gnu.org wrote:
Well, David, when you suggested it I wasn't so sure. But now that I've
thought of it myself... brilliant!! :-p :-)
But now I'm having second thoughts ...
-David
___
Bug-make mailing
that you're running on ubuntu 13.04 or solaris 10.
Which is exactly what make_host tells you. It provides the
architecture make was built for in the form of e.g.
x86_64-unknown-linux-gnu or whatever configure comes up with.
On Mon, Apr 29, 2013 at 8:03 PM, David Boyce david.s.bo...@gmail.com wrote
On Sun, May 5, 2013 at 2:49 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
On 05/05/2013 05:30 PM, Paul Smith wrote:
On Sun, 2013-05-05 at 11:11 +0200, Stefano Lattarini wrote:
Sorry to add this only now, but I realized the failure is only
reproducible if I run the testsuite with
On Wed, May 15, 2013 at 7:54 AM, Eli Zaretskii e...@gnu.org wrote:
because of the need to convert the file names from UTF-16 to
something the rest of the code can grok.
Well, if I understand correctly there's no need to actually grok the
UTF-16 filenames, just to get past them with a more
http://256.gr/whzo/tmil.bsdiajld
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
results in frequent failed builds due to fork failures.
Thus it seems to me that
Pro: spawn doesn't suffer from the documented problems which result from
trying to emulate fork on Windows.
should be part of the conversation too.
-David Boyce
___
Bug
good
enough for me. In fact any answer is good enough for me as long as the
resulting make.exe works reliably with -j at large scale factors.
David Boyce
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
:-)(
http://www.faqs.org/docs/artu/ch15s04.html).
-David Boyce
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Solaris has a really old, really broken, /bin/sh which they've kept around
forever for compatibility reasons. Maybe there are some tests which assume
features that aren't supported in Solaris /bin/sh?
David
On Tue, Sep 17, 2013 at 7:38 AM, Paul Smith psm...@gnu.org wrote:
On Tue, 2013-09-17
I'm not sure if Pavel is on this list so adding him explicitly.
Looks like there's a strong risk that no version of the spawn patch will
get into 4.0 which would be a shame IMHO.
-David
On Tue, Sep 24, 2013 at 7:37 AM, Frank Heckenbach
f.heckenb...@fh-soft.dewrote:
Try this patch. I don't
On Mon, Sep 30, 2013 at 3:12 PM, Frank Heckenbach
f.heckenb...@fh-soft.dewrote:
I tested the new version and found no new issues, so as far as I'm
concerned this feature can now be considered finished. Thanks for
the initial patch, David, and the integration into GNU make, Paul!
And special
Follow-up Comment #12, bug #33034 (project make):
I'm uploading a patch that adds an --allow-mixed-rules option which converts
the fatal error to a warning. This is the only testing it's been subjected
to:
% cat Makefile
all %.o:
@echo Making $@
% make-4.0
Makefile:1: *** mixed implicit
Follow-up Comment #14, bug #33034 (project make):
Yes, I realize it's a bit of a wing and a prayer but from the git log it looks
like this fix got into the same commit as a rewrite of major sections of
read.c. Without reading and thinking through all of it, I figured there was a
chance that
Paul.
Thank you very much! This means I'll be able to make professional use
the many features and bugfixes which have arrived post-3.81 at some
point. Given the flurry of other fit-and-finish fixes lately, would it
be safe to assume there will be a 4.01 or equivalent upcoming in the
foreseeable
Sorry for the side-track but for future reference when discussing the
hypothetical rigorous output format:
On Sun, Dec 15, 2013 at 5:38 AM, Tim Murphy tnmur...@gmail.com wrote:
I'm not an XML fan really
Agree.
JSON might be an alternative.
IMHO, YAML is to JSON what JSON is to XML (oh, and
On Tue, Jan 14, 2014 at 12:41 PM, Eli Zaretskii e...@gnu.org wrote:
Thanks, but does EMX support output-sync?
Didn't he just say The purpose of this piece is to add missing
support for output-sync option to [...] EMX?
David
___
Bug-make mailing list
On Sat, Jan 18, 2014 at 4:17 PM, Paul D. Smith invalid.nore...@gnu.org wrote:
There are limits to the size of command lines that can be invoked. On newer
systems
like Linux that limit is pretty large (I think it's 16K or so on Linux) but it
exists, and on other systems it's much less.
It's
On Tue, Jan 28, 2014 at 7:31 AM, Gisle Vanem gva...@yahoo.no wrote:
Paul Smith psm...@gnu.org wrote:
Then make invokes the shell with the results of the expansion, which are
the rm and echo commands (and some empty strings which are ignored).
So, the rm is running AFTER the file is created,
On Tue, Jan 28, 2014 at 1:20 PM, Paul Smith psm...@gnu.org wrote:
I'm not sure I'd go that far. $(shell ...) really _is_ useless in a
recipe because make will invoke a shell to run the recipe anyway, so why
have it invoke two shells? It's just redundant.
However, $(file ...) can be useful
Paul has already demonstrated later in the thread that I was wrong.
Nothing to see here, move along.
David
On Wed, Feb 5, 2014 at 7:42 AM, wpmcnamara wpmcnam...@yahoo.com wrote:
David Boyce-3 wrote
I think the headline here is that $(file) is analogous to $(shell) in
that it's intended
I believe it's theoretically possible to have a case-sensitive
filesystem on Windows though it would primarily benefit masochists.
On Mon, Jul 7, 2014 at 5:00 PM, Paul Smith psm...@gnu.org wrote:
On Mon, 2014-07-07 at 21:15 +0100, Jonny Grant wrote:
+#ifdef WINDOWS32
+ { GNUmakefile, makefile,
The obvious compromise would be to change the behavior only in the
presence of the .POSIX: special target.
On Thu, Aug 21, 2014 at 9:13 AM, Paul Eggert egg...@cs.ucla.edu wrote:
Eric Blake wrote:
You may want to check out http://austingroupbugs.net/view.php?id=857 and
add comments and/or
On Thu, Aug 21, 2014 at 12:27 PM, Ray Donnelly mingw.andr...@gmail.com wrote:
On Thu, Aug 21, 2014 at 8:03 PM, David Boyce david.s.bo...@gmail.com wrote:
The obvious compromise would be to change the behavior only in the
presence of the .POSIX: special target.
Sounds pragmatic; the repeatable
I just noticed that while assigning to SHELL suppresses the fast-path
algorithm, assigning to .SHELLFLAGS does not. Feature or bug?
David
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
On Wed, Feb 11, 2015 at 12:22 PM, Paul Smith psm...@gnu.org wrote:
On Wed, 2015-02-11 at 10:44 -0800, David Boyce wrote:
I just noticed that while assigning to SHELL suppresses the fast-path
algorithm, assigning to .SHELLFLAGS does not. Feature or bug?
That's a good question. I'm sort
For the record, I didn’t ever suggest it was a problem with GNU make,
just that the wording in your “rules” doesn’t map perfectly to
reality. It’s your call, of course, whether that wording needs to be
updated or whether fixing it would muddy the message.
Separately: this situation is is not
Follow-up Comment #1, bug #45275 (project make):
Sorry, ignore the via variables in the title string.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?45275
___
Message sent via/by
URL:
http://savannah.gnu.org/bugs/?45275
Summary: 4.0+ core dumps with long .PHONY targets via
variables
Project: make
Submitted by: boyski
Submitted on: Mon 08 Jun 2015 01:45:44 PM GMT
Severity: 3 - Normal
Follow-up Comment #2, bug #45311 (project make):
I think the confusion here has to do with the value of $@. One might
reasonably expect, in a multi-target pattern rule, that $@ would be the list
of all matching out-of-date targets but in fact, according to the
documentation:
In a pattern rule
1 - 100 of 193 matches
Mail list logo
