On Tue, 2013-04-16 at 15:31 +0100, Tim Murphy wrote:
So this is great and you can see that there are 4 targets in my
makefile and that each one is a start X followed by an end X. I
don't see any enter/exit delimitation - have I missed out some option?
Um. Yes, the enter/leave only happens
On Tue, 2013-04-16 at 19:20 +0300, Eli Zaretskii wrote:
From: Paul Smith psm...@gnu.org
Cc: bo...@kolpackov.net, bug-make@gnu.org, f.heckenb...@fh-soft.de
Date: Tue, 16 Apr 2013 10:44:39 -0400
On Tue, 2013-04-16 at 16:43 +0300, Eli Zaretskii wrote:
I'm not sure what the semantics
On Wed, 2013-04-17 at 19:10 +0300, Eli Zaretskii wrote:
That could be a misunderstanding on my part: I didn't realize that by
handle you mean a FILE object. I thought you meant Windows specific
HANDLE objects (which underly every open file).
I'm not very familiar with Windows terminology. Is
On Wed, 2013-04-17 at 23:00 +0300, Eli Zaretskii wrote:
I'd be surprised if this were a real problem nowadays. E.g., the
Windows C runtime is documented to allow up to 512 FILE streams, which
can be enlarged to 2048 by calling a function. The max number of file
descriptors is also 2048.
GNU
On Thu, 2013-04-18 at 19:09 +0200, Frank Heckenbach wrote:
This mechanism was unaffected by my output-sync patch, and I
expected your change broke it.
I was reading your email with interest, waiting for the punch-line, but
then after all that description you just said that the change broke it,
On Thu, 2013-04-18 at 20:36 +0200, Frank Heckenbach wrote:
And with my progress mechanism, that's exactly what I want. In my
case it'd look like this:
[Start] Compiling foo.c
[Start] Compiling bar.c
# time passes
foo.c: some error
# time passes
bar.c: some error
# time passes
[End]
On Sat, 2013-04-20 at 13:50 +0300, Eli Zaretskii wrote:
Do we really need to require 0.18.1 or can this restriction be lifted?
I hacked configure.ac to require 0.17, and didn't see any problems
afterwards.
You can see this bug:
http://savannah.gnu.org/bugs/?37307
I confess I didn't get a
On Fri, 2013-04-19 at 18:07 -0600, David Sankel wrote:
In section 7.3 and 8.2 the function 'findstring' is recommended as a
means to search a space separated list for a given value. This
suggestion is problematic as findstring really searches for
substrings. So, for example $(findstring
On Sat, 2013-04-20 at 19:38 +0300, Eli Zaretskii wrote:
From: Paul Smith p...@mad-scientist.net
Cc: bug-make@gnu.org
Date: Sat, 20 Apr 2013 11:44:02 -0400
On Sat, 2013-04-20 at 13:50 +0300, Eli Zaretskii wrote:
Do we really need to require 0.18.1 or can this restriction be lifted
On Fri, 2013-04-19 at 14:09 +0300, Eli Zaretskii wrote:
Date: Fri, 19 Apr 2013 11:54:05 +0200
Cc: bo...@kolpackov.net, bug-make@gnu.org
From: Frank Heckenbach f.heckenb...@fh-soft.de
Is there a simple enough Makefile somewhere that could be used to test
this feature, once
On Fri, 2013-04-19 at 12:36 +0300, Eli Zaretskii wrote:
Also, where is the best place to put the emulated Posix functions?
Some new file in w32/compat/?
I'd like to see it there. I'm thinking I want to move the new stuff out
of job.c even for POSIX systems. The ifdefs are really getting to
On Tue, 2013-04-23 at 21:40 +0300, Eli Zaretskii wrote:
Date: Tue, 23 Apr 2013 11:29:35 -0700
From: David Boyce david.s.bo...@gmail.com
Cc: Frank Heckenbach f.heckenb...@fh-soft.de, bug-make bug-make@gnu.org
Since you asked basic questions I'm going to start this at a basic level.
On Tue, 2013-04-23 at 23:16 +0300, Eli Zaretskii wrote:
All it requires is inheriting the redirected stdout/stderr to child
processes. This was already possible under Dos (with the exception
that since there was no fork, you had to redirect in the parent
process, call the child, then
On Wed, 2013-04-24 at 21:17 +0300, Eli Zaretskii wrote:
There's one issue that perhaps needs discussing. A mutex is
identified by a handle, which on Windows is actually a pointer to an
opaque object (maintained by the kernel). As such, using just 'int'
for sync_handle is not wide enough,
I'm fully prepared to accept the blame for not doing the best job
getting buy-in etc. on this effort. Can we leave the discussion on the
process behind? I'd prefer that, unless there are real constructive
comments on how to do better next time rather than rehashing what was
done wrong. I think
On Wed, 2013-04-24 at 22:25 +0300, Eli Zaretskii wrote:
From: Paul Smith psm...@gnu.org
Cc: e...@gnu.org, bug-make@gnu.org
Date: Wed, 24 Apr 2013 15:07:21 -0400
I'm not so sure fstat() is that cheap. struct stat contains a lot of
information. Although I guess since we are only ever
On Wed, 2013-04-24 at 22:39 +0300, Eli Zaretskii wrote:
Nothing is actually read by lseek (and even if it were, it would
only need to look at the first and last part of the file, not read
all the content, if that was the worry).
Are you sure? How can lseek jump to the last byte of the
On Wed, 2013-04-24 at 22:55 +0100, Tim Murphy wrote:
why not use a named semaphore wherever possible (windows and linux)
and lock a file where not instead of trying to pass kernel object
handles around (seems a bit nasty to me)?
Hi Tim; I think you're late to the party :-). Let me summarize a
On Thu, 2013-04-25 at 07:14 +0100, Tim Murphy wrote:
To be honest, I have done all this before with named semaphores
including the file that gets left over problem and it's all solvable
quite nicely. You pass the build id in the environment which is,
after all, what it's for.
Sure. Given
On Sat, 2013-04-27 at 13:09 +0300, Eli Zaretskii wrote:
Is this intended behavior that these two messages:
mkfsync:6: recipe for target 'two' failed
gnumake[1]: [two] Error 1 (ignored)
are separated and wrapped by separate Entering...Leaving blocks,
instead of being produced together?
On Sat, 2013-04-27 at 14:39 +0300, Eli Zaretskii wrote:
The changes needed to make -O work on MS-Windows are now committed to
the master repository, see commits da7df54 and 049f8e8. Please review
and comment.
Thanks Eli!!
I'll take a look over the next few days.
On Sat, 2013-04-27 at 20:55 +0300, Eli Zaretskii wrote:
Note: there's one more major feature in current git repo that needs to
be made available on Windows: dynamic loading of extensions. That is
my highest priority for Make todo list.
Yes. I wonder if there are features of gnulib which make
I took with make-w32 list off.
On Sat, 2013-04-27 at 22:18 +0300, Eli Zaretskii wrote:
I added a similar facility to Gawk, but there a problem was much
simpler, because Gawk itself was tracking the loaded extensions in
platform-independent code. So my emulation of dlopen didn't need to
On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote:
That would be nice, indeed.
OK, pushed. You should be able to simply write a new load_objects()
function and drop it in. Or put it into a w32 file or whatever.
___
Bug-make mailing list
On Thu, 2013-04-18 at 22:36 +0200, Frank Heckenbach wrote:
This is useful (to me) because at any time, I know what's running.
([Start] messages minus [End] messages.)
Thanks, this is the reason I was looking for; that use-case wasn't clear
to me based on the previous email.
OK, so
On Fri, 2013-04-12 at 13:41 +0200, Reinier Post wrote:
Hmm, indeed:
| /tmp % cat Makefile
| %.1:; echo $*.1 for $@ $@
| %.e.1 %.f.1:; echo $*.1 for $@ $@
| %.c.1 %.d.1:; for f in $*.c.1 $*.d.1; do echo $$f for $@ $$f; done
| %.ab.2: %.a.1 %.b.1; cat $+ $@
| %.cd.2: %.c.1 %.d.1; cat $+
On Sun, 2013-04-28 at 20:19 +0300, Eli Zaretskii wrote:
From: Paul Smith psm...@gnu.org
Cc: bug-make@gnu.org
Date: Sat, 27 Apr 2013 16:58:54 -0400
On Sat, 2013-04-27 at 23:00 +0300, Eli Zaretskii wrote:
That would be nice, indeed.
OK, pushed.
Thanks! But I see you kept
On Sun, 2013-04-28 at 21:14 +0300, Eli Zaretskii wrote:
From: Paul Smith p...@mad-scientist.net
Cc: make-...@gnu.org, bug-make@gnu.org
Date: Sat, 27 Apr 2013 12:54:10 -0400
On Sat, 2013-04-27 at 19:17 +0300, Eli Zaretskii wrote:
The .ONESHELL feature is now supported on MS-Windows
On Sun, 2013-04-28 at 22:41 +0300, Eli Zaretskii wrote:
I think the implementation you have is not quite right. I think the
parsing of the @-+ stuff is common across all platforms if we have a
shell, so you don't need the else /* non-posix shell */.
I do need a separate code, because it
On Sun, 2013-04-28 at 20:00 +0300, Eli Zaretskii wrote:
I've pushed a change to add a new argument to the -O/--output-sync
option, job, to write output after each line of the recipe.
What is its purpose? To avoid mixing in the same screen line
characters from several parallel sub-makes?
On Thu, 2013-04-18 at 22:36 +0200, Frank Heckenbach wrote:
% make -Omake # same with -Otarget
m:2: recipe for target 'foo' failed
make: *** [foo] Error 1
foo:error
This seems at least strange to me: The conclusion recipe failed is
printed before the reason (the messages from the job).
Now that we seem to have a workable solution for output synchronization
for both POSIX and Windows systems, I wonder if we shouldn't consider
enabling it as the default mode when parallel builds are running.
I understand that this will be a change that could be visible (beyond
the collection of
On Mon, 2013-04-29 at 19:30 +0100, Tim Murphy wrote:
I must clarify - I think that make should provide plugins with an
allocation mechanism. Not the other way around.
It's probably a good idea for make to provide a gmk_free() function
that will free memory returned to the plugin when it calls
On Mon, 2013-04-29 at 22:34 +0300, Eli Zaretskii wrote:
Yes, that should be possible. My concern is that, at least on UNIX, the
rules for this are complex and I don't want to reimplement the runtime
linker :-). Maybe something like, first try the path as given and if
that fails, try
On Mon, 2013-04-29 at 17:00 -0400, David Boyce wrote:
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
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
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 script,
right?
No; the testsuite runs as a recursive
On Tue, 2013-04-30 at 17:48 +0100, Tim Murphy wrote:
i.e. I don't just have
load X.dll
I have to supply the recipe to build it on windows:
X.dll:
cl.exe /Fdo$@ # use microsoft's compiler
and on Linux
X.so:
gcc -o $@ ... # using gcc
Actually this supports Eli's point
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 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 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 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 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-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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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 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 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 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-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-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 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
301 - 400 of 1346 matches
Mail list logo
