On Mon, 2014-08-04 at 11:43 -0700, Gregory Fong wrote:
When I select any of the other commits, the commit info is shown as
expected. Not sure why these two have mysteriously decided not to
work. Maybe the cgit cache got into a bad state? Hopefully someone
can help get this sorted out.
I
On Thu, 2014-06-26 at 16:19 -0400, Patrick Donnelly wrote:
Updating makefiles
Considering target file 'test.mk'.
Looking for an implicit rule for 'test.mk'.
[...]
Why is it trying to build target test.mk...???
See
On Thu, 2014-06-26 at 16:19 -0400, Patrick Donnelly wrote:
I'm bringing this problem up because targets are not being created (as
expected) by implicit rules but I don't know this because make claims
success.
This part doesn't make sense to me; maybe you can provide more info
here.
An
On Thu, 2014-06-26 at 17:00 -0400, Patrick Donnelly wrote:
This is a little inconvenient when you're relying on implicit rules.
e.g.
%.o: %.c
cc -o $@ $
%: %.o
ld $@ $^
foo: bar.a
Even if foo.c is missing, Make still succeeds. This is actually what
I'm dealing with and I'd
On Tue, 2014-06-24 at 17:24 -0700, Renewal Computer Services wrote:
make -j 4 (or whatever number, I use -j 12) is broken, with mingw-w64
a *nix-based project will cause a long list of compilation errors
whereas without -j project will compile fine.
No it's not. Your makefile is wrong.
On Tue, 2014-06-10 at 16:01 -0700, Corey Brenner wrote:
I've run into a situation where I want to control the include dirs in
a recursive make. I am adding include paths to recursive invocations
via --include-dir=, when I find one which matches my criteria.
However, GNU Make seems to be
On Wed, 2014-06-11 at 13:45 -0400, Paul Smith wrote:
Unfortunately in older versions of make the option and argument
are left as two separate words:
$ echo 'a:;: $(MAKEFLAGS)' | make-3.81 -f- -I/usr/include -I/bin
: I /usr/include -I /bin
which makes it much more difficult to remove
On Wed, 2014-05-28 at 14:29 +0530, chandrababu nallani wrote:
Hi,
Could you send me the link to get the known bugs and issues for GNU
Make 3.80.
Sorry, but we don't spend the effort to keep detailed information on
this. You can look at the bugs that were listed as fixed in the GNU
make
On Wed, 2014-05-21 at 11:12 +, Van der Zaag, Paul wrote:
We use your make utility on Tandem. Does the –j option have any
effect, or is does it not on Tandem?
I'm sorry but I have no experience with Tandem.
The -j option will basically work on all systems. However, it works
better on some
On Thu, 2014-05-01 at 17:41 +0200, Houder wrote:
Below, besides the specified target (bla), the output of make also
outputs the name of the makefile (M) ... AS IF THE MAKEFILE IS A
TARGET.
Can anybody explain this to me? Thank you.
On Wed, 2014-04-30 at 18:19 +0200, Guillem Jover wrote:
build-stamp:
echo $@
build-arch: build-stamp
$ make --version | head -n1
GNU Make 4.0
$ make -f detect.mk -qn build-arch; echo $?
2
This is definitely a bug in GNU make 4.0 in handling -q (note the -n is
not relevant: you
On Mon, 2014-04-07 at 21:26 -0700, Philip Guenther wrote:
I am unable to reproduce this:
Based on the offer of MSVC project files I would guess Rob is running on
Windows.
I expect this is a result of the buggy snprintf()/vsnprintf()
implementations in the Windows MSVC compiler (well, by buggy I
On Tue, 2014-04-08 at 20:15 +, Rob Juergens wrote:
Note that in Unix, vsnprintf() returns the TOTAL number of chars
needed (add 1 for the null). If the output would overflow the buffer,
then you would get a return value larger than the specified buffer
size.
In Windoze, vsnprintf()
On Tue, 2014-04-08 at 21:01 +, Rob Juergens wrote:
Attached is a rewrite of the method vfmtconcat() in output.c. It seems
to fix the problem.
Thanks, but as Philip mentioned earlier I've completely rewritten the
output.c file and callers of it so they use only C89 compliant functions
(so no
On Sun, 2014-03-16 at 21:43 -0500, John E. Malmberg wrote:
With that correction, I am back to 60 tests failing in 29 categories
failing if I use the -keep option.
You should never use -keep when invoking the full test suite. Using
-keep will cause other tests to fail, on all platforms: it's
On Thu, 2014-02-27 at 10:53 +0900, Mike Hommey wrote:
I have no problems with your original patch. I think I said that
right there and then. If Paul agrees, I will commit it.
Paul?
I'll reiterate my position that (a) I've seen nothing showing that it's
inherently impossible for make to
On Mon, 2014-02-24 at 18:50 +0100, Bjoern Michaelsen wrote:
Yes. But of course for any bigger C/C++ project, although a rather
specific usecase, it makes up the majority of the source to parse.
_If_ LibreOffice wouldnt already do some tricks, parsing the 13GB of
generated dependencies would
On Mon, 2014-02-24 at 18:51 +, Tim Murphy wrote:
On 24 February 2014 18:33, Paul Smith psm...@gnu.org wrote:
I would definitely want this to be totally invisible to the user and not
require any magic in makefiles (so no special include operator, etc.)
Basically it should either be so
On Tue, 2014-02-04 at 10:33 +, Ray Donnelly wrote:
I can't see it in the git repository yet.
.. am I being too impatient?
Sorry, it's committed in my local repo at home but I haven't pushed.
I'll do that tonight.
___
Bug-make mailing list
On Tue, 2014-02-04 at 18:54 +0200, Eli Zaretskii wrote:
Another issue is with backslashes in paths.
For example:
$ cat EOF foo.mk
foo:
grep foo foo\\bar
EOF
(Note the is just there to trigger sh -c)
This executes sh -c grep foo foo\\bar, which fails with:
On Sun, 2014-01-26 at 16:35 +, Ray Donnelly wrote:
I missed a few assert cases in the previous patch. Please find a fixed
version attached.
I applied this change. Thanks!
___
Bug-make mailing list
Bug-make@gnu.org
On Fri, 2014-01-31 at 16:55 +0200, Eli Zaretskii wrote:
An option as command line argument, or as a special target as the
original patch did?
The former, as Paul objected to the latter.
I didn't object, per se. I just prefer my tools to DTRT in all cases
without me having to use any
On Thu, 2014-01-30 at 19:29 +0200, Eli Zaretskii wrote:
I will review the patch some more in a day or two. (And I hope Paul
will as well.)
Yes, definitely, but it won't be until the weekend I expect. Life is
intruding on hacking this month.
___
On Tue, 2014-01-28 at 09:52 -0800, David Boyce wrote:
I think the headline here is that $(file) is analogous to $(shell) in
that it's intended specifically for use _outside_ of recipes. If you
find yourself using either one in a recipe it's probably a sign you're
on the wrong track.
I'm not
On Sun, 2014-01-26 at 16:35 +, Ray Donnelly wrote:
I missed a few assert cases in the previous patch. Please find a fixed
version attached.
Thanks Ray; I'm utterly swamped for the last week or so with real life
but I should have a bit more free time later this week; I'll check out
your fix.
On Sun, 2014-01-26 at 16:22 -0800, Mark Brown wrote:
That example method is a device to perform this .FEATURES test
without inserting it into an existing Makefile.
The syntax errors I was seeing were occurring when attempting to insert this
test into an existing Makefile, full of Targets and
On Fri, 2014-01-24 at 11:03 -0800, Mark Brown wrote:
I had a make.exe 3.80 and it had problems with else ifeq
constructs, so that forced me to seek a more recent version for win32.
Yes that version didn't support it. You can look at the latest NEWS
file for info on what appeared when:
On Tue, 2014-01-14 at 11:00 +0400, Pavel Fedin wrote:
Hello!
I am trying to rebuild GIT version of Make, however .po files are missing
in the repository. Is this intentional ? I have copied them over from my
4.0-2 archive. But where are they originally stored ?
The PO files are
On Tue, 2014-01-14 at 11:58 +0200, Eddy Petrișor wrote:
I understand the interest in the amount of time a given job takes to
run, but I guess I don't understand the need for a start time
offset
at all. Isn't it sufficient to record the start time of a job, then
when it's complete show
On Tue, 2014-01-14 at 06:56 +0100, Christian Eggers wrote:
Am Montag, 13. Januar 2014, 17:20:43 schrieb Paul Smith:
On Mon, 2014-01-13 at 22:23 +0100, Christian Eggers wrote:
In Makefile 2 my intention was to state that foo.o depends on some
generated header which must be generated first
On Mon, 2014-01-13 at 18:21 +0200, Eli Zaretskii wrote:
From: Mark Brown mkbrown_...@hotmail.com
Date: Mon, 13 Jan 2014 06:04:24 -0800
I was able to compile the make 4.0 source code downloaded from the
gnu make site using Visual C++ 2005 under Windows 7 64 (generated 0 errors,
259
On Mon, 2014-01-13 at 19:37 +0200, Eli Zaretskii wrote:
On Windows, GNU make can be compiled in a quite a number of different
ways. It would be helpful if you gave us an idea of which method you
used.
He said that: he used Microsoft Visual C++ version 2005.
But I meant, how? Through
On Mon, 2014-01-13 at 22:23 +0100, Christian Eggers wrote:
In Makefile 2 my intention was to state that foo.o depends on some
generated header which must be generated first (might be in another
rule). But I didn't want to change the be behaviour if foo.o cannot be
built because e.g. there's no
I fixed this one locally a couple of days ago; sorry for not pushing.
I'll do that shortly.
I don't think this change is sufficient because if output_sync !=
make_sync then make_sync is never dumped with the change below.
On Tue, 2014-01-14 at 06:21 +0100, Frank Heckenbach wrote:
Oliver Kiddle
Sorry, I've been mostly away from my systems recently.
On Wed, 2013-12-18 at 13:28 +0200, Eddy Petrișor wrote:
Thanks for clarifying this. Could you please confirm if the general
direction of the the is OK in the latest patch I sent?
I will take a look.
What it is in scope and what I would
On Wed, 2013-12-18 at 13:28 +0200, Eddy Petrișor wrote:
Could you please confirm if the general direction of the the is OK in
the latest patch I sent?
Conceptually it seems OK. I'm still not jazzed about having any more
than one output format, and I'd prefer that format to be in a
more-or-less
On Sun, 2013-12-15 at 13:38 +, Tim Murphy wrote:
I suppose I'm skirting around saying that I think gnu make needs an
output format in the same way that valgrind has --xml=yes. I'm not
an XML fan really - JSON might be an alternative.
It isn't your problem to provide such a mechanism and
On Mon, 2013-11-25 at 19:39 -0800, Stephan T. Lavavej wrote:
#1:
OSN (fatal, NILF,
^
Fixed, thanks.
#2:
w32err.c: In function 'map_windows32_error_to_string':
w32err.c:70:3: warning: passing argument 2 of 'fatal' makes integer from
pointer without a cast [enabled by
On Tue, 2013-11-26 at 12:21 +, Ray Donnelly wrote:
Instead of adding the MS-specific %Ix, could you not add (in the
batch file) the define of __MINGW_USE_ANSI_STDIO=1, otherwise I
suspect you'd be breaking people who prefer the stdio a bit more ansi
(mingw-builds for example).
I went with
On Mon, 2013-11-25 at 13:48 +0400, Pavel Fedin wrote:
I am restarting work on spawn-patch for Cygwin. Actually, i have the very
first version working, but want to try to do some face-lift and get rid of
some #ifdef's.
My first question is: is VMS port maintained, or dead long ago ?
The VMS
On Sun, 2013-11-24 at 12:35 +0200, Eddy Petrișor wrote:
Since you just worked on this, and the new type overwrites in case of
repetition, does it make sense to overwrite instead of error? I think
that for profiling this type of behaviour would be better.
Sorry, but I didn't understand that.
On Mon, 2013-10-21 at 17:36 +0100, Ken Moffat wrote:
I haven't even figured out where quiet-command is located. I'm
only an integration monkey, checking that everything in our distro
(BLFS) will build with make-4.0. Will take a look.
Please see my second email, from earlier today.
Based on
On Mon, 2013-10-21 at 18:03 +0100, Ken Moffat wrote:
2. Unfortunately, rules.mak *is* adding -rR to the MAKEFLAGS -
# Don't use implicit rules or variables
# we have explicit rules for everything
MAKEFLAGS += -rR
I'll attach rules.mak. Is this a qemu bug which just happened to
work in
On Mon, 2013-10-21 at 16:02 +0100, Ken Moffat wrote:
# command line
ARFLAGS =
So this tells us that the empty value is being set from the command
line.
I then ran it in the directory where the build fails (dtc/) -
# makefile (from 'Makefile', line 51)
ARFLAGS = rc
This is not
On Mon, 2013-10-21 at 18:48 +0100, Ken Moffat wrote:
Thanks. Is it OK if I quote this whole reply to the qemu devs ?
Of course. This mailing list is publicly archived; quote away.
Or point them to the thread:
http://lists.gnu.org/archive/html/bug-make/2013-10/msg00151.html
On Sun, 2013-10-20 at 20:15 -0700, David Boyce wrote:
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
On Mon, 2013-10-21 at 04:05 +0100, Ken Moffat wrote:
With GNU Make 4.0 on x86_64-unknown-linux-gnu I am unable to build
qemu 1.6.{0,1} because it fails with
AR libfdt/libfdt.a
ar: two different operation options specified
Makefile:234: recipe for target 'libfdt/libfdt.a' failed
On Sat, 2013-10-05 at 16:34 +0300, Eli Zaretskii wrote:
EXPORT int mk_test_gmk_setup (const gmk_floc *flocp)
{
gmk_add_function (hello_world, hello_world, 0, 255, 0);
^^^
Make functions cannot have the '_' character in their names, so it
seems.
On Wed, 2013-09-25 at 11:30 +0200, Denis Excoffier wrote:
Still experimenting 'make check' with Cygwin (without the spawn-patch,
with --disable-load):
1) In test_driver.pl, line 486 (look for Test returned), a comparison
of $code against the value -1 is performed. However, 3 lines above the
On Tue, 2013-10-01 at 11:04 +0200, Denis Excoffier wrote:
Hello,
Thank you for this new RC.
I have tested make-3.99.93 under cygwin 32 bits with --disable-load
(and without the spawn-patch).
Several items that i had reported in
On Tue, 2013-10-01 at 10:21 +0200, Stephan Beal wrote:
On Tue, Oct 1, 2013 at 7:06 AM, Paul Smith psm...@gnu.org wrote:
Note, no changes to translatable strings were introduced in
this
release.
i'm not sure if this counts as a translatable string, but i'm seeing
On Sun, 2013-09-22 at 22:16 +0200, Denis Excoffier wrote:
On 2013-09-22 06:50, Paul Smith wrote:
Just curious: did you build with --disable-load because something failed
otherwise? Or just because you wanted to?
I didn't investigate the errors produced with --enable-load. Here they are:
I
Hi all. The fourth release candidate, 3.99.93, for the next version of
GNU make is now available on alpha:
ftp://alpha.gnu.org/gnu/make/make-3.99.93.tar.bz2
81e1f8693c50bf485382c31f0e827d91
ftp://alpha.gnu.org/gnu/make/make-3.99.93.tar.gz
fc854c46fb60d8ffb1066dc46026aa4c
There are a number
As always thanks for your thorough testing Frank.
On Tue, 2013-09-24 at 20:41 +0200, Frank Heckenbach wrote:
Paul Smith wrote:
On Thu, 2013-09-19 at 14:47 +0200, Frank Heckenbach wrote:
Paul Smith wrote:
I didn't fix it this way. Instead I used the existing MAKE_RESTART
On Wed, 2013-09-25 at 13:51 +0200, Boris Kolpackov wrote:
Paul D. Smith psm...@gnu.org writes:
I'm not sure I fully understood the situation.
This comment makes it sound like same version of make (same code) is 50%
slower on the new system. Is that what you meant?
Yes, the same make
On Mon, 2013-09-23 at 11:02 +0300, Eli Zaretskii wrote:
There's also another problem: you added a test script dash-w, where we
already had a dash-W. On Windows, these two map to the same file, so
git overwrites the same file, and the file is always marked as
modified. Please rename one of
On Sat, 2013-09-21 at 07:28 +, Edward Welbourne wrote:
I've never understood why someone would use $(shell ...) in a recipe...
I mean, the recipe will be run in the shell!!
I remember we once had a library where the command-line to the archiver
was too long (about a quarter megabyte,
On Tue, 2013-09-17 at 23:46 +0200, Denis Excoffier wrote:
I have configured with --disable-load. I had to apply the patch below
(self explanatory i think) for 'make check' to return with no error.
Moreover:
1) when configured with --disable-job-server, the tests in
features/parallelism
are
On Tue, 2013-09-17 at 10:23 +0200, Dagobert Michelsen wrote:
Unfortunately I don't have a copy of Sun Studio and I don't have any
SPARC hardware. I'll need someone with access to these to assist.
That is no problem. There are already a number of GNU projects that use
our buildfarm to
On Mon, 2013-09-16 at 08:48 +0300, Eli Zaretskii wrote:
In this thread:
http://lists.gnutls.org/pipermail/gnutls-devel/2013-September/006453.html
and specifically in this message and its followups:
http://lists.gnutls.org/pipermail/gnutls-devel/2013-September/006460.html
there's
On Mon, 2013-09-16 at 20:52 +0200, Dagobert Michelsen wrote:
/opt/SUNWspro/bin/cc -D_REENTRANT -pthreads
-I/opt/csw/include/guile/2.0 -I/opt/csw/include -xO3 -m32
-xarch=sparc -m32 -xarch=sparc -L/opt/csw/lib -o make ar.o arscan.o
commands.o default.o dir.o expand.o file.o function.o
On Thu, 2013-09-12 at 04:19 -0400, Paul Smith wrote:
I think there may still be some change needed for directory tracking
for the -Orecurse mode. If we're collecting output for an entire
recursive make invocation we don't need enter/leave notifications
around each individual target or line
On Wed, 2013-09-04 at 18:15 -0400, David Boyce wrote:
On Wed, Sep 4, 2013 at 4:42 PM, Paul D. Smith
invalid.nore...@gnu.org wrote:
Follow-up Comment #1, bug #39943 (project make):
IMO _any_ editor which automatically replaces TABs with spaces
should never be
On Fri, 2013-08-16 at 20:59 +0400, Pavel Fedin wrote:
Friday, August 16, 2013, 19:19:58 you wrote:
Also, when I'm making changes to the exec() code I don't spend a lot of
time worrying about spawn() so it is possible that it will be broken
from time to time and, in fact, I think you
On Fri, 2013-08-16 at 13:30 -0400, Christopher Faylor wrote:
On Fri, Aug 16, 2013 at 01:12:28PM -0400, Paul Smith wrote:
On Fri, 2013-08-16 at 20:59 +0400, Pavel Fedin wrote:
Friday, August 16, 2013, 19:19:58 you wrote:
Also, when I'm making changes to the exec() code I don't spend a lot
On Fri, 2013-08-16 at 22:52 +0400, Pavel Fedin wrote:
Exactly, hence the reason for my question. I'm not interested in adding
this if, when it's enabled, things don't work correctly.
On the other hand I'm not sure it's not possible to get things working
correctly. Or, perhaps it's
On Mon, 2013-08-05 at 10:56 -0400, Christopher Faylor wrote:
Then maybe really add something like --enable-dos-paths which
defaults to
no on Cygwin and Yes on MinGW ?
ac_cv_dos_paths=no configure
works just fine and does not require a command-line switch.
If this is a common/necessary
On Wed, 2013-07-31 at 10:37 +0400, Pavel Fedin wrote:
Looks like, if you want DOS paths, and running under Cygwin, an
explicit conversion has to be performed on getcwd() result using
cygwin_conv_path(). However i did not test this further because i
follow official Cygwin way of doing things,
On Tue, 2013-07-30 at 18:39 +0300, Eli Zaretskii wrote:
In general, I feel it's wrong to do this: Cygwin is a Posix platform,
so it should be using the Posix code, to be as compatible with other
Posix platforms as possible. EMX is not a Posix platform, so using
its code will likely make the
On Tue, 2013-07-09 at 10:43 -0400, Jay Lawrence wrote:
My bad, I see that patch now, please disregard...
In your comment below you mentioned you'd tried the latest source but it
still failed. I believe I fixed this bug with a commit in April. Can
you reproduce the issue with the latest source
On Mon, 2013-05-27 at 20:13 +0300, Eli Zaretskii wrote:
and if so, does it guarantee non-conflicting writes?
Not sure I understand what you are asking here. Can you elaborate?
The original issue reported is that if you do something like this:
make -j make.out
and your make environment
On Sun, 2013-05-26 at 22:05 +0200, Stefano Lattarini wrote:
On 05/26/2013 09:57 PM, Paul Smith wrote:
[SNIP]
Might be worthwhile checking the FreeBSD code for their make, to see if
they do something like this.
Nope, Frank was right: when run in parallel mode, FreeBSD make
On Mon, 2013-05-20 at 19:06 +0300, Eli Zaretskii wrote:
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
On Thu, 2013-05-23 at 04:10 -0400, bug-make-ow...@gnu.org wrote:
define PROGRAM_template =
This syntax is not available in GNU make 3.81. It was introduced in GNU
make 3.82. Thus the PROGRAM_template variable is not defined, and
expands to the empty string, and thus your eval does nothing.
On Wed, 2013-05-22 at 22:09 +0200, Stefano Lattarini wrote:
On 05/22/2013 06:56 PM, Paul Smith wrote:
I've reworked the MFLAGS / MAKEFLAGS generation to be more regular and
rigorous yesterday, for 4.0, and to preserve _some_ backward-compat; I
had thought about this issue when I did so
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
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
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
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
On Sun, 2013-05-05 at 04:37 +0200, Frank Heckenbach wrote:
COMMANDS_RECURSE _does_ mean to recurse. The reason for the '+'
prerequisite is to tell make that this line, even though it may not look
like it, will run a recursive make.
OK, let me just say that the meaning of recursive may
On Sun, 2013-05-05 at 00:44 +0200, Stefano Lattarini wrote:
The test 'features/output-sync' now fails for me:
Test timed out after 6 seconds
Error running /storage/home/stefano/src/gnu/make/tests/../make \
(expected 0; got 14): /storage/home/stefano/src/gnu/make/tests/../make \
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 make -j, as in make -j8
check; and even in that case, the failure is racy. With a bare make
check, things work for me as well.
On Sun, 2013-05-05 at 19:36 +0300, Eli Zaretskii wrote:
However, I wonder what was the reason for splitting the definition of
GMK_EXPORT in two, and putting each part in a different file.
Well, because the gnumake.h file is intended to be installed into the
user's /usr/include or similar, and
Hi all. I've recently pushed changes to solve the last open issues that
I'm aware of with the --output-sync feature:
* If command line printing is not suppressed (@ is not used) the
command line is attached to the output.
* Extraneous enter/leave lines are not printed any
On Sat, 2013-05-04 at 09:57 +0300, Eli Zaretskii wrote:
From: Paul Smith psm...@gnu.org
Cc: reinp...@win.tue.nl, bug-make@gnu.org
Date: Fri, 03 May 2013 16:51:47 -0400
I think enabling [-O] by default will be a no-brainer if/when we come up
with a way to get it to produce the same
On Sat, 2013-05-04 at 08:57 +0200, Frank Heckenbach wrote:
I shouldn't have written that. :-( Shortly afterwards, I found a bug
or perhaps two:
foo:
@echo foo
+@echo bar
(a)
% make -Ojob
foo
bar
foo
(b)
% make -Otarget
bar
foo
As you see, (a) -Ojob writes foo
On Fri, 2013-05-03 at 12:55 -0400, Paul Smith wrote:
Suppose we do this: if we're about to invoke a line marked recursive
and we're in -Otarget mode, then before we run it we'll show the
current contents of the temp file (using the normal synchronized
output function).
I've implemented
On Fri, 2013-05-03 at 09:50 +0300, Eli Zaretskii wrote:
From: Paul Smith psm...@gnu.org
Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
Date: Thu, 02 May 2013 16:21:36 -0400
The one and only difference between them is that when running a
recursive make, -Otarget WILL NOT capture
I have a solution for this problem that I think will work well, and will
be simple to implement.
Suppose we do this: if we're about to invoke a line marked recursive and
we're in -Otarget mode, then before we run it we'll show the current
contents of the temp file (using the normal synchronized
On Wed, 2013-05-01 at 20:38 -0700, Jim Michaels wrote:
again, problem solved with what I proposed. think. separate shell
window for each job.
You can do that today by just writing your recipes such that they start
a screen session or xterm or whatever. Those tools allocate and manage
their
Eli Zaretskii e...@gnu.org writes:
If you want different behavior you can change your rule to use + on
the two echo lines, so that they're also considered recursive and not
saved up.
If I do that, the echo from rec1 and rec2 mix up:
D:\gnu\make-3.82.90_GIT_2013-05-01gnumake -f
On Thu, 2013-05-02 at 20:30 +0300, Eli Zaretskii wrote:
With this simple Makefile:
all:
@echo foobar!
true
Yes this is a bug. I thought of this while we were having our
discussion yesterday. Unfortunately in all our tests we were using @
to silence make's output of the
On Thu, 2013-05-02 at 20:24 +0300, Eli Zaretskii wrote:
The desired results in my original use case are that the output of
remaking each target is shown as one chunk in the order in which it is
expected, i.e. from the first command to the last. Remaking a
target, a.k.a. recipe in this context
On Tue, 2013-04-30 at 17:20 -0700, Jim Michaels wrote:
I wasn't digressing. I was explaining the point. the concept I am
trying to present as a solution to the problem of making parallel
stdin for --jobs in gnu make (which currenty doesn't work and is I
guess single-threaded) is to make a
On Wed, 2013-05-01 at 00:59 +0200, Stefano Lattarini wrote:
# With make 3.82, compiled from official tarball:
$ make -f- 'all:; @echo $(MFLAGS)' -I none
-I none
# With development version of make:
$ make -f- 'all:; @echo $(MFLAGS)' -I none
-Inone
I think MFLAGS is
On Tue, 2013-04-30 at 10:39 -0400, Paul Smith wrote:
On Tue, 2013-04-30 at 16:04 +0200, Stefano Lattarini wrote:
On 04/30/2013 03:37 PM, Paul Smith wrote:
Just to be clear, you're saying that the testsuite runs as one long
operation, updating one target, and the recipe invokes one test
On Wed, 2013-05-01 at 18:26 +0300, Eli Zaretskii wrote:
You forgot to make the same change in the WINDOWS32 branch. I did
that in commit a87ff20.
Sorry, I missed that.
This should be fixed now. Those who use recursive makefiles and were
seeing annoying delays in output with -O, please
On Wed, 2013-05-01 at 22:08 +0300, Eli Zaretskii wrote:
Yes. But I thought the change was about -Otarget, not -Ojob. Stefano
was complaining about a plain -O, so -Ojob is not what was his
problem.
Yes, it is about -Otarget. As I said, I added -Ojob output just for
completeness. The
On Tue, 2013-04-30 at 11:19 +0200, Stefano Lattarini wrote:
The above has been obtained with GNU make built from latest
git version (commit 'moved-to-git-46-g19a69ba').
Yes. I know the email lately has been daunting but if you wade through
it you'll see a number of emails discussing this
Just to be clear, you're saying that the testsuite runs as one long
operation, updating one target, and the recipe invokes one test script,
right? I can see how that environment might be problematic for this new
feature. It works much better for lots of smaller targets.
However, you could avoid
901 - 1000 of 1337 matches
Mail list logo