From: Paul Smith psm...@gnu.org
Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
Date: Wed, 01 May 2013 16:27:58 -0400
If your recipe normally runs for 5 seconds (say) and it continually
generates output during that time, then yes, certainly the -O feature
will result in choppiness
From: Paul Smith psm...@gnu.org
Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
Date: Thu, 02 May 2013 08:21:23 -0400
Now, if you do nothing special for recursive make, you'll get no output
from the entire build until it is completely done, because all the
output from the recursive
With this simple Makefile:
all:
@echo foobar!
true
I get:
D:\gnu\make-3.82.90_GIT_2013-05-01gnumake -j -f mkfsync1
foobar!
true
which is expected, but:
D:\gnu\make-3.82.90_GIT_2013-05-01gnumake -j -f mkfsync1 -O
true
foobar!
Is this also expected? (I see the same
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 the output of the sub-make,
leaving whatever it prints going to
From: Paul Smith psm...@gnu.org
Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
Date: Fri, 03 May 2013 07:47:09 -0400
The way the user experiences the -Ojob option's results is that the
output of every line of each recipe is dumped as soon as that line is
complete.
I would suggest
From: Paul Smith psm...@gnu.org
Date: Fri, 03 May 2013 08:57:57 -0400
Cc: bug-make@gnu.org
I think having this facility built into make is a win, especially as
parallel builds become predominant. I would be even more happy about it
if we can get it to the point where it can be enabled by
From: Paul Smith psm...@gnu.org
Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
Date: Fri, 03 May 2013 09:08:27 -0400
You're concentrating on the one recursive make target and saying
this doesn't follow the rule, while I'm concentrating on all
targets in the sub-make and saying let's
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 output as without -j. IOW,
run a parallel build, but output
From: Paul Smith psm...@gnu.org
Cc: stefano.lattar...@gmail.com, bug-make@gnu.org
Date: Fri, 03 May 2013 17:17:44 -0400
-O in no way changes that behavior, all it does is ensure that output
from any individual line or target of the recipe will not interfere with
any other individual line
Date: Sat, 04 May 2013 04:42:32 +0200
Cc: e...@gnu.org, david.s.bo...@gmail.com, bug-make@gnu.org
From: Frank Heckenbach f.heckenb...@fh-soft.de
: /* This is needed to avoid the label at end of compound statement
: diagnostics on Posix platforms. */
I don't think that's a POSIX
From: Paul Smith psm...@gnu.org
Cc: reinp...@win.tue.nl, bug-make@gnu.org
Date: Sat, 04 May 2013 09:04:24 -0400
you may see this:
xa
xb
a
$(MAKE) foo
xc
xd
b
If a appears before xb, then that's all I ask for.
If we want it to be no worse, then why do we need it at
Should the Make manual include instructions, however short, about
building extensions? Not writing the code (that is covered), but
actually compiling the extensions so that Make will be able to load
them.
___
Bug-make mailing list
Bug-make@gnu.org
From: Paul Smith p...@mad-scientist.net
Cc: bug-make@gnu.org
Date: Sat, 04 May 2013 17:51:05 -0400
Eli, I did some cleanup in job.c to try to make things simpler and
reduce duplication. I tried to be careful but it's quite possible I did
something to disrupt the Windows version again.
From: Paul Smith psm...@gnu.org
Cc: bug-make@gnu.org
Date: Sun, 05 May 2013 12:56:48 -0400
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
Date: Sun, 05 May 2013 20:17:50 +0300
From: Eli Zaretskii e...@gnu.org
Cc: bug-make@gnu.org
From: Paul Smith psm...@gnu.org
Cc: bug-make@gnu.org
Date: Sun, 05 May 2013 12:56:48 -0400
On Sun, 2013-05-05 at 19:36 +0300, Eli Zaretskii wrote:
However, I wonder what was the reason
From: Paul Smith psm...@gnu.org
Date: Sun, 05 May 2013 20:30:32 -0400
We are right on the cusp of a release candidate for the next GNU make
version.
If the next release is close, then what about the following 2 issues,
which were discussed, but AFAIK not finalized:
. the
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:
http://alpha.gnu.org/gnu/make/make-3.99.90.tar.gz
37c2d65196a233a8166d323f5173cdee
Update of bug #30714 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
Component Version:3.81 = SCM
Fixed Release:
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
Date: Sat, 18 May 2013 14:00:44 -0400
From: Boris Kolpackov bo...@kolpackov.net
Cc: bug-make@gnu.org
I've also tested the up-to-date check time compared to 3.81
and the new version is significantly faster (5.63s vs 8.15s).
Can you show a Makefile to test that? I'd like to measure this on
Date: Mon, 27 May 2013 00:42:34 +0200
From: Frank Heckenbach f.heckenb...@fh-soft.de
Cc: bug-make@gnu.org
One issue, though it might seem strange that I'm the one to mention
it, is that it might be POSIX specific. How do other systems behave,
can they set O_APPEND via fcntl or otherwise
Date: Fri, 31 May 2013 05:36:24 +0200
Cc: psm...@gnu.org, stefano.lattar...@gmail.com, bug-make@gnu.org
From: Frank Heckenbach f.heckenb...@fh-soft.de
Eli Zaretskii wrote:
From: Frank Heckenbach f.heckenb...@fh-soft.de
However, there may still be a problem. The trick about
Date: Fri, 31 May 2013 16:58:21 +0200
Cc: psm...@gnu.org, stefano.lattar...@gmail.com, bug-make@gnu.org
From: Frank Heckenbach f.heckenb...@fh-soft.de
void write (int fd, void *data, size_t size)
{
if (getflags (fd) O_APPEND)
{
lock_mutex (get_mutex (fd));
From: Steve Taylor steve.tay...@aut.ac.nz
Date: Thu, 6 Jun 2013 22:04:59 +
Is there a fix for this?
I'm using GNU Make 3.81 on Windows 7.
Lines like this...
CD D:\Steve\data
MOVE prog1.log ..
... cause an error like this...
process_begin: CreateProcess(NULL, CD
From: Pavel Fedin p.fe...@samsung.com
Date: Tue, 30 Jul 2013 14:44:58 +0400
Currently make's configure suggests that it should use DOS-style paths on
Cygwin. This is not true, and this assumption makes path-related mechanisms
to work incorrectly. Currently Cygwin package supplies manual
From: Pavel Fedin p.fe...@samsung.com
Date: Tue, 30 Jul 2013 14:42:23 +0400
Please take this patch, Cygwin team told that they would like to integrate
with upstream. I have already posted it some time ago but got no reply.
The patch significantly improves performance of Make under Cygwin.
Cc: bug-make@gnu.org, Pavel Fedin p.fe...@samsung.com
From: Roland Schwingel roland.schwin...@onevision.com
Date: Tue, 30 Jul 2013 18:29:07 +0200
I clearly think the DOS paths mode should remain in even for cygwin. I
know that there are objections in cygwins top level management against
Date: Tue, 30 Jul 2013 11:52:58 -0500
From: Norbert Thiebaud nthieb...@gmail.com
Cc: Pavel Fedin p.fe...@samsung.com, bug-make@gnu.org
fork() is a very expensive operation in cygwin.
Yes, I know. But without it, some things that are expected of a Posix
behavior will not work. A notable
Date: Wed, 31 Jul 2013 01:24:45 +0400
From: Pavel Fedin pavel_fe...@mail.ru
Cc: bug-make@gnu.org
There was a short discussion in Cygwin ML with test results, sorry, i
cannot find the URL, Google fails to find it.
Can you at least tell when (year and month) this discussion took
place?
In
Date: Fri, 2 Aug 2013 22:49:31 -0400
From: Christopher Faylor m...@cgf.cx
On Tue, Jul 30, 2013 at 08:02:54PM +0300, Eli Zaretskii wrote:
Date: Tue, 30 Jul 2013 11:52:58 -0500
From: Norbert Thiebaud nthieb...@gmail.com
Cc: Pavel Fedin p.fe...@samsung.com, bug-make@gnu.org
fork
From: Pavel Fedin p.fe...@samsung.com
Date: Mon, 05 Aug 2013 09:19:18 +0400
IMHO it's a little bit inconvenient that you have to use config.cache trick
in order to build a fully working Make for Cygwin, and this is not
documented anywhere. First time, when i didn't know about this, i've
Date: Mon, 5 Aug 2013 21:34:31 +0400
From: Pavel Fedin pavel_fe...@mail.ru
fork()-based code temporary sets 'environ' variable to child's environment,
which appears to contain current directory. EMX code didn't do that.
The problem gets triggered only if you try to call something which
Date: Mon, 5 Aug 2013 22:04:44 +0400
From: Pavel Fedin pavel_fe...@mail.ru
CC: m...@cgf.cx, bug-make@gnu.org
I don't yet understand why you have a problem in the first place. It
sounds like the single issue is with the 'abspath' function, is that
correct?
Yes, correct.
In that
From: Pavel Fedin p.fe...@samsung.com
Cc: m...@cgf.cx, bug-make@gnu.org
Date: Tue, 06 Aug 2013 17:46:14 +0400
1. abspath on Cygwin returns UNIX-style paths and on pure DOS/Windows -
DOS-style.
This is what I'd expect.
If DOS-style absolute path is already supplied, it will leave it as
From: Pavel Fedin p.fe...@samsung.com
Cc: bug-make@gnu.org
Date: Tue, 06 Aug 2013 10:46:51 +0400
Runtime ??? I am sorry, but what's the sense ?
I tried to explain that in my first response: 'fork' has a certain
semantics and implements requirements that 'spawn' does not. Since
Cygwin is a
From: Pavel Fedin p.fe...@samsung.com
Cc: m...@cgf.cx, bug-make@gnu.org
Date: Wed, 07 Aug 2013 10:22:31 +0400
2. PATH_SEPARATOR on Cygwin is ':' and on pure DOS/Windows is ';'.
This is true, but how is this relevant to the issue at hand?
'abspath' does not deal with PATH-style
From: Paul Smith psm...@gnu.org
Date: Fri, 16 Aug 2013 14:18:31 -0400
Cc: bug-make@gnu.org
So, the question is very simple: is it technically possible to ensure
that the operations make takes today in the child between fork and exec
can be handled properly in a spawn-based
Follow-up Comment #1, bug #39825 (project make):
I'm sorry, but what does objdump have to do with Make?
Is there any problem with Make? If so, please describe it.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?39825
Follow-up Comment #3, bug #39825 (project make):
Yes, it's clear now, thanks.
However, I cannot reproduce this problem on my machine, neither with Make 3.80
nor with 3.81. Redirection or not, objdump works fine for me here.
Is the problem specific to objdump, or does any program fail when
Follow-up Comment #5, bug #39825 (project make):
I can explain why sh.exe makes the difference. GNU Make on Windows always
prefers a Unixy shell if it can find it. If it cannot find it, it uses
cmd.exe.
Also, Make does not invoke the shell if there are no shell features, such as
quoting and
From: Paul Smith psm...@gnu.org
Cc: l...@gnu.org, bug-make@gnu.org
Date: Mon, 16 Sep 2013 08:11:25 -0400
there's evidence that GNU Make no longer treats suffix rules with
prerequisites as normal files with funny names, as described in the
manual.
Did the behavior indeed change, and
From: Denis Excoffier bug-...@denis-excoffier.org
Date: Tue, 24 Sep 2013 12:34:35 +0200
Cc: Eli Zaretskii e...@gnu.org,
pavel_fe...@mail.ru
On 2013-09-24 07:40, Eli Zaretskii wrote:
Could be, as I don't think I've seen any EMX-related changes for a
long time.
On the contrary
From: Pavel Fedin p.fe...@samsung.com
Cc: bug-make@gnu.org
Date: Wed, 25 Sep 2013 16:12:10 +0400
Just a reminder. I have followed your suggestion and fixed this a month
ago. Please try this:
http://lists.gnu.org/archive/html/bug-make/2013-08/msg00031.html
I didn't forget, I just don't
From: Pavel Fedin p.fe...@samsung.com
Cc: bug-...@denis-excoffier.org, bug-make@gnu.org
Date: Thu, 26 Sep 2013 10:47:15 +0400
There must be a better way, since the only difference between Posix and
Windows file
names is the X: prefix of every absolute file name.
Yes. But in certain
From: Gisle Vanem gva...@yahoo.no
Date: Thu, 3 Oct 2013 22:03:14 +0200
VERSION = 3.99.93
ifeq ($(MAKE_VERSION),$(VERSION))
-load ./mk_test.dll
endif
The above was needed since I needed to use mingw-make version 3.82.90
to build this new make.exe. Windows doesn't allow make.exe to be
From: Gisle Vanem gva...@yahoo.no
Date: Sat, 5 Oct 2013 14:33:26 +0200
Eli Zaretskii e...@gnu.org wrote:
Well, the tests in the test suite that test this feature did work for
me at some point, so you may wish first to verify they do for you, and
then compare your extension
Date: Sat, 05 Oct 2013 16:34:11 +0300
From: Eli Zaretskii e...@gnu.org
Cc: bug-make@gnu.org
Paul, if this limitation is deliberate, I suggest to document it where
we explain the arguments of gmk_add_function.
One other important thing that doesn't seem to be covered in the
manual
Follow-up Comment #3, bug #40225 (project make):
Just a nit: on MS-Windows, $wildcard always returns file names in sorted
order, because that's how the underlying filesystem behaves.
___
Reply to this item at:
Follow-up Comment #2, bug #40226 (project make):
Could you please provide a minimal Makefile and a test case to reproduce the
problem you saw? I'm sorry, but I have a difficulty understanding your
description of the bug you found in the code; hopefully a test case will help
me see the light.
Follow-up Comment #5, bug #40226 (project make):
Paul: If you already see and understand the problem, by all means take it. I
didn't yet have time to even build the release ;-).
Thanks.
___
Reply to this item at:
Follow-up Comment #7, bug #40226 (project make):
Christian: Thanks for the extended explanations.
For the record: I don't see this on my system, at least not with the simple
recipe you provided. Moreover, the (second) call to `decode_switches`, after
`prepare_mutex_handle_string`, never
Follow-up Comment #8, bug #40226 (project make):
Are we going to release 4.01 soon? If not, is the problem serious enough to
fix it in the present code? Or can I safely use the Windows binary of 4.0
unaltered? (As I wrote, the problem does not happen in my usage.)
Follow-up Comment #4, bug #40227 (project make):
Please provide a minimal Makefile that can be used to reproduce the problem.
Thanks.
I also don't understand why you needed to define va_copy for MinGW. AFAICS,
MinGW does have a proper definition for it (MSVC indeed doesn't, AFAIK).
Follow-up Comment #5, bug #40227 (project make):
Moreover, MinGW does not provide _vsnprintf_s (or any of the *_s functions),
so I don't see how did Make compile for you after the change. It fails for
me.
___
Reply to this item at:
Follow-up Comment #7, bug #40227 (project make):
You are using MinGW64. I use MinGW32 from mingw.org, a different distribution
with a different set of headers.
The tests you propose on __MINGW32_MAJOR_VERSION etc. will not distinguish
between MinGW64 and MinGW32. So we need some other
Follow-up Comment #14, bug #40227 (project make):
Please show me the debugging session where you saw the problem, with all the
details. I need to see that to make sure we understand the problem
completely. Just see how many different hypotheses and suggestions were
offered in this discussion,
Follow-up Comment #16, bug #40227 (project make):
Thanks.
My debugging shows that the problem does not happen with the MinGW32 build,
because vsnprintf is replaced by a conforming implementation in libmingwex.a,
which is linked in by default. (So I guess mingw.org's distribution is not as
bad
Follow-up Comment #1, bug #40241 (project make):
Can you show a Makefile recipe that fails in this way?
Does it fail because /usr/bin/install is actually mapped to some directory
like C:\MSYS\bin, and /usr/bin does not really exist in the filesystem? Or
does it fail because you think
Follow-up Comment #3, bug #40241 (project make):
Thanks for the test case.
I'm reluctant to go slow in this case, because that would change the
semantics of the command, as it doesn't have any shell-specific features.
Instead, could you please try the attached patch?
(file #29405)
Date: Thu, 10 Oct 2013 17:42:11 +0200
From: Bob Shark bobshar...@gmail.com
Contrary to the Statement in readme.w32 Make 4.0 does not comile with
MSVC7.1.
It looks like no one who does have MSVC 7 installed (I don't) is
tracking the release candidates. So, unfortunately, these problems
are
Date: Sat, 19 Oct 2013 11:48:44 +0300
From: Eli Zaretskii e...@gnu.org
Cc: bug-make@gnu.org
1) _TRUNCATE is unknown
Workaround: use (size_t)-1
2) vsnprintf unknown
Workaround: use _vsnprintf
3) _vsnprintf_s unknown
Workaround: replace
len = _vsnprintf_s (str
Follow-up Comment #5, bug #40241 (project make):
It worked for me, but of course I don't have your exact setup. I will have
another look.
(Don't worry about leaking memory, I just wanted to see if this kind of change
fixes your problem. The actual change will have all this straightened up.)
Follow-up Comment #1, bug #40322 (project make):
This doesn't happen for me. Does it happen for you always, or just with some
Makefile's? Can you show an example of a Makefile and a session where Ctrl-C
does not interrupt the Make run?
There's special code in Make to handle the Ctrl-C
Follow-up Comment #4, bug #40322 (project make):
That is not what is supposed to happen.
When you press Ctrl-C, the SIGINT handler is invoked, this is the function
fatal_error_signal defined on command.c. (Please verify that the signal
handler is indeed invoked.) Since on Windows SIGINT
Update of bug #26075 (project make):
Status:None = Works for me
Open/Closed:Open = Closed
Fixed Release:None = 4.0
Follow-up Comment #6, bug #40241 (project make):
My patch did had 2 conceptual problems, sorry.
Please try this patch instead.
(file #29434)
___
Additional Item Attachment:
File name: w32_unixy_shell.difSize:2 KB
Follow-up Comment #8, bug #40241 (project make):
What does doesn't handle quotes right mean? It's a Unixy shell, right?
What kind of shell are you using?
BATCH_MODE_ONLY_SHELL cannot be catered to at this stage, it's something
considered at a higher level. But that higher level doesn't know
Follow-up Comment #10, bug #40241 (project make):
I actually tested the patch with MSYS Bash. Can you show me one or two
examples of it mishandling quotes? I use MSYS Bash quite a lot (although not
from the native Make), and never saw any problems with quotes.
And, btw, if you use MSYS Bash,
Follow-up Comment #14, bug #40241 (project make):
Indeed, that's what I see as well.
Can you use the MSYS file name notation instead, as in
/c/full/path/to/python.exe? My testing indicates that the problem
disappears when this format of file names is used.
Btw, these are exactly the problems
Follow-up Comment #4, bug #40344 (project make):
Make does not necessarily prepend the current directory, but the library
functions it calls might do that internally, as part of file-name
normalization. (So it's not the current directory that counts, but
CURRENT_DIR/../../../../../../ in your
Follow-up Comment #17, bug #40241 (project make):
MSYS Make 3.82.90 from the URL below does work well with -jN:
https://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/
I use that build all the time.
Yes, using single quotes are also a possibility.
Eventually, I need to
Update of bug #40241 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
Fixed Release:None = SCM
Triage Status:
Update of bug #20542 (project make):
Item Group: Enhancement = None
Open/Closed:Open = Closed
___
Follow-up Comment #3:
6 years have passed
Update of bug #15968 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
Fixed Release:None = 4.0
Summary: make
Update of bug #37648 (project make):
Item Group: Bug = Enhancement
Triage Status: Need Info = Major Effort
___
Follow-up Comment #2:
No further info is
Update of bug #40227 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
Fixed Release:None = SCM
From: Pavel Fedin p.fe...@samsung.com
Date: Mon, 25 Nov 2013 16:44:20 +0400
Cc: bug-make@gnu.org
Actually, i want to fix output-sync for spawn()-based flavor. This includes
EMX, DOS and potentially Cygwin. Currently output-sync option will not work
in that ports, because the related
Date: Tue, 26 Nov 2013 12:21:10 +
From: Ray Donnelly mingw.andr...@gmail.com
Cc: bug-make@gnu.org
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
Follow-up Comment #7, bug #40322 (project make):
Any news on this one? Should I close it?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?40322
___
Message sent via/by Savannah
Follow-up Comment #8, bug #40344 (project make):
One other thing: such a patch will probably be quite substantial, so you will
need legal paperwork to assign the copyright to the FSF, before the patch can
be admitted. If that's fine with you, I suggest to start the paperwork ASAP,
as it can take
Update of bug #40322 (project make):
Status:None = Not A Bug
Open/Closed:Open = Closed
___
Reply to this item at:
From: Pavel Fedin p.fe...@samsung.com
Date: Fri, 10 Jan 2014 15:49:35 +0400
Cc: cyg...@cygwin.com
Hello! I've just discovered one more bug in GNU Make under Cygwin.
Make is able to understand -lfoo as depencencies and tries its best to look
up libraries correctly. However in some
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 warnings)
but executing the resulting make command file from
From: Paul Smith psm...@gnu.org
Date: Mon, 13 Jan 2014 11:47:54 -0500
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
From: Paul Smith psm...@gnu.org
Cc: bug-make@gnu.org
Date: Mon, 13 Jan 2014 12:44:12 -0500
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
From: Mark Brown mkbrown_...@hotmail.com
Cc: bug-make@gnu.org
Date: Mon, 13 Jan 2014 14:06:16 -0800
As mentioned I used Visual C++ 2005,
loading the project file and building it:
make_msvc_net2003.vcproj .
This results in a make_msvc.net2003.exe of length 892 KB
being created in
From: Mark Brown mkbrown_...@hotmail.com
Cc: psm...@gnu.org,
bug-make@gnu.org
Date: Mon, 13 Jan 2014 22:56:10 -0800
I showed some of the output when this new windows/dos make is run
from the command prompt, in the original message.
Sorry, I thought that was from the Cygwin shell,
From: Pavel Fedin p.fe...@samsung.com
Date: Tue, 14 Jan 2014 11:53:15 +0400
Cc: bug-make@gnu.org
Obviously, you are trying to execute Makefile written for UNIX systems, are
you ? This makefile relies on UNIX shell commands like uname, pwd, basename,
etc. Right ?
In order to run this
From: Pavel Fedin p.fe...@samsung.com
Date: Tue, 14 Jan 2014 11:11:35 +0400
This is part of my spawn-patch for Make. The purpose of this piece is to
add missing support for output-sync option to spawn()-based flavors
(currently only EMX).
Thanks, but does EMX support output-sync? If not,
From: David Boyce david.s.bo...@gmail.com
Date: Tue, 14 Jan 2014 13:13:13 -0500
Cc: Pavel Fedin p.fe...@samsung.com, bug-make bug-make@gnu.org
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
From: Pavel Fedin p.fe...@samsung.com
Cc: bug-make@gnu.org
Date: Wed, 15 Jan 2014 10:23:58 +0400
I have rechecked. Actually NO_OUTPUT_SYNC is defined only by handmade
config.h files for DOS, VMS and Amiga. EMX uses configure script, so
NO_OUTPUT_SYNC will not be defined.
However, indeed,
From: Pavel Fedin p.fe...@samsung.com
Cc: bug-make@gnu.org
Date: Thu, 16 Jan 2014 10:03:38 +0400
Thanks, this variant is fine with me.
Good. I'm waiting for it to be committed
Done.
In order to make it switched at runtime, i would like to refactor
child_execute_job(). I have
Follow-up Comment #2, bug #41246 (project make):
The changes seem simple enough and non-controversial. However, this
introduces a new special target, .BATCH_MODE_SHELL (why not
.BATCH_MODE_ONLY_SHELL, btw?), which should at least be documented in the
manual.
Paul, do you agree with adding a new
Date: Thu, 30 Jan 2014 01:16:34 +0400
From: Pavel Fedin pavel_fe...@mail.ru
Hello! This is my long-promised refactor. After this it's much easier
to apply runtime selection between spawn() and fork() on Cygwin,
because all differences are now consolidated in two functions:
From: Paul Smith psm...@gnu.org
Cc: Pavel Fedin pavel_fe...@mail.ru, bug-make@gnu.org
Date: Thu, 30 Jan 2014 12:33:41 -0500
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
Date: Fri, 31 Jan 2014 09:14:32 +
From: Mike Hommey invalid.nore...@gnu.org
This is a different approach to the problem, as suggested by Paul: this
triggers batch mode shell when there are double quotes in the recipe.
This cannot be automatic, as we have deliberately made the double
Date: Fri, 31 Jan 2014 22:15:56 +0900
From: Mike Hommey m...@glandium.org
Cc: psm...@gnu.org, mh+savan...@glandium.org, bo...@kolpackov.net,
bug-make@gnu.org
On Fri, Jan 31, 2014 at 11:37:47AM +0200, Eli Zaretskii wrote:
Date: Fri, 31 Jan 2014 09:14:32 +
From: Mike Hommey
From: Paul Smith psm...@gnu.org
Cc: Mike Hommey m...@glandium.org, mh+savan...@glandium.org,
bo...@kolpackov.net, bug-make@gnu.org
Date: Fri, 31 Jan 2014 10:59:13 -0500
My question, or _challenge_ if you like, is whether we can find a way to
know, without any hints from the user,
From: Paul Smith psm...@gnu.org
Cc: Mark Brown mkbrown_...@hotmail.com, bug-make@gnu.org
Date: Sun, 02 Feb 2014 10:28:01 -0500
On Tue, 2014-01-14 at 18:02 +0200, Eli Zaretskii wrote:
===
process_begin: CreateProcess(NULL, uname
From: Gisle Vanem gva...@yahoo.no
Date: Sun, 2 Feb 2014 15:06:23 +0100
According to:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682653(v=vs.85).aspx
the total size of the environment is 32kByte. This has hit me several
times in GNU-make when CreateProcess() triggers
301 - 400 of 733 matches
Mail list logo
