Re: Some serious issues with the new -O option

> From: Paul Smith > Cc: stefano.lattar...@gmail.com, bug-make@gnu.org > Date: Wed, 01 May 2013 14:41:25 -0400 > > > Unfortunately, the delays are still here. > > Very odd. This is the test program I used; can you verify: > > recurse: ; $(MAKE) -f $(firstword $(MAKEFILE_LIST)) all > all: 2

Re: Some serious issues with the new -O option

> From: Paul Smith > Date: Wed, 01 May 2013 08:04:08 -0400 > Cc: bug-make@gnu.org > > > This should work very well with -Otarget then, except for the > > colorization/highlighting issue... once it works as expected. I'll look > > into this issue later and I would be interested to see your experi

Loading dynamic objects on Windows

I ran all of the load and loadapi tests in the test suite and found a couple of problems in the current implementation that were based on unportable assumptions. The solutions touch to some extent the platform independent code and build requirements, so I'd like to discuss them here before I actua

Re: dynamic object searching (was: Re: Dynamic objects)

> Date: Tue, 30 Apr 2013 17:48:42 +0100 > From: Tim Murphy > Cc: "Paul D. Smith" , "bug-make@gnu.org" > > > That's unrelated. I was talking about the fact that > > > > load foo.so > > > > is inherently non-portable, whereas > > > > load foo > > or > > load foo$(SOEXT) > > > >

Re: dynamic object searching (was: Re: Dynamic objects)

> Date: Tue, 30 Apr 2013 08:57:23 +0100 > From: Tim Murphy > Cc: "Paul D. Smith" , "bug-make@gnu.org" > > Since you can't (in my recent experience) load a 64-bit DLL into a 32-bit > program, the real issue is what architecture was make itself built with. That's unrelated. I was talking about t

Re: dynamic object searching

> From: Paul Smith > Cc: Eli Zaretskii , bug-make > Date: Mon, 29 Apr 2013 19:53:26 -0400 > > I'm not saying make_host is wrong. I do wish there was something more > generic available (maybe in addition) that let people know "posix" vs > "windows"

Re: dynamic object searching (was: Re: Dynamic objects)

> From: Paul Smith > Cc: Tim Murphy , bug-make@gnu.org > Date: Mon, 29 Apr 2013 16:34:01 -0400 > > 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

Re: memory allocation

> From: Paul Smith > Cc: Eli Zaretskii , "bug-make@gnu.org" > Date: Mon, 29 Apr 2013 16:16:40 -0400 > > 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 gmk_*()

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

> Date: Mon, 29 Apr 2013 22:34:51 +0300 > From: Eli Zaretskii > Cc: bug-make@gnu.org > > > Also we don't really have a precedent of a "make-specific" directory > > like that. > > Gawk puts them into ${prefix}/lib/gaw

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

> Date: Mon, 29 Apr 2013 20:40:46 +0100 > From: Tim Murphy > Cc: "Paul D. Smith" , "bug-make@gnu.org" > > > How can one deal with them? The underlying OS is not easily > > detectable by Make. > > > > the same way one creates 1 makefile that can build the same code for 2 > operating systems - s

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Mon, 29 Apr 2013 13:59:16 -0400 > > > 1. Doesn't the FSF frown upon capability to load _any_ dynamic > >objects? I think they like the GCC method whereby each extension > >is required to define a symbol with a certain name > >(plugin_

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

> Date: Mon, 29 Apr 2013 19:33:10 +0100 > From: Tim Murphy > Cc: Eli Zaretskii , "bug-make@gnu.org" > > Come now - the broken excuse is an excuse. There's plenty of crap free > software out there and some poor bastard trying to build it who can't > cha

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

> Date: Mon, 29 Apr 2013 18:30:37 +0100 > From: Tim Murphy > Cc: "bug-make@gnu.org" > > cc fred.c -c -o fred.o > cc bob.c -c -o bob.o > error on line 20 -X > error on line 30 - > error on line 330 - > makefile:342: recipe for target 'fred.o' failed > makefile:350: recipe for target '

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

> Date: Mon, 29 Apr 2013 18:19:09 +0100 > From: Tim Murphy > Cc: "Paul D. Smith" , "bug-make@gnu.org" > > > 2. The fact that the dynamic object's file extension (.so) is exposed > >to the Makefile is unfortunate, because it will hurt portability of > >Makefiles: the extension on Windows

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

> Date: Mon, 29 Apr 2013 16:40:03 +0100 > From: Tim Murphy > Cc: "bug-make@gnu.org" > > cc fred.c -c -o fred.o > cc bob.c -c -o bob.o > error on line 20 -X > > Which one? Make will actually tell you which one, something like: makefile:342: recipe for target 'oo/i386/acl-errno-valid.o' f

Re: Dynamic objects (was: .ONESEHLL not working as expected in 3.82)

> From: Paul Smith > 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. You should be able to simply write a new load_objects() > function and dro

Re: .ONESEHLL not working as expected in 3.82

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 28 Apr 2013 14:37:29 -0400 > > > My plan was to write dlopen and dlsym, and add them to > > w32/compat/posixfcn.c. But I need to understand the semantics of > > global_dl in order to do that correctly. > > It's up to you how you think it be

Re: .ONESEHLL not working as expected in 3.82

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 28 Apr 2013 15:15:09 -0400 > > I think it pseudo-code it would look something like this: > > if (posix-shell) > { > ...strip out @-+ from LINE... > } > #ifdef WINDOWS32 > if (need a batch file) > { > ...write LINE

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

> Date: Mon, 29 Apr 2013 09:58:50 +0100 > From: Tim Murphy > Cc: "bug-make@gnu.org" > > try interpreting error messages from compiler/tool X when they're 10 > lines from the file that they refer to and don't include the > filename in the error message. That's unrelated: interpreting such output

Re: Default output-sync setting (was: Re: [bug #33138] .PARLLELSYNC enhancement with patch)

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 28 Apr 2013 22:03:39 -0400 > > 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.

Re: .ONESEHLL not working as expected in 3.82

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 28 Apr 2013 16:01:05 -0400 > > I guess I thought you were writing a batch file, > then invoking the shell with the batch file name as the command to run. > E.g., "command.com " vs. "perl " etc. I am naive > but it seems like that should work

Re: .ONESEHLL not working as expected in 3.82

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 28 Apr 2013 15:15:09 -0400 > > The goal of this code in the if-statement is to implement a special case > allowing ONESHELL to be easier to add in the case where you DO have a > standard shell. In that case, and ONLY in that case, we remove

Re: .ONESEHLL not working as expected in 3.82

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sun, 28 Apr 2013 14:37:29 -0400 > > On Sun, 2013-04-28 at 20:19 +0300, Eli Zaretskii wrote: > > > From: Paul Smith > > > Cc: bug-make@gnu.org > > > Date: Sat, 27 Apr 2013 16:58:54 -0400 > >

Re: .ONESEHLL not working as expected in 3.82

> From: Paul Smith > 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, for the default > > Windows shell (cmd.exe) or comp

[bug #37065] $(wildcard dir/*/.) is wrong (worked fine in 3.81)

Update of bug #37065 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM Triage Status:

Re: .ONESEHLL not working as expected in 3.82

> From: Paul Smith > 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 global_dl and the call to dlopen with the 1st

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Sun, 28 Apr 2013 10:22:40 -0400 > From: David Boyce > Cc: Frank Heckenbach , Eli Zaretskii , > bug-make > > So I'd argue for: > > -O line (new) > -O job (current -O target) > -O make Agree about "line" (assuming I understood what it means)

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> From: Paul Smith > Cc: e...@gnu.org, david.s.bo...@gmail.com, bug-make@gnu.org > Date: Sun, 28 Apr 2013 01:34:44 -0400 > > 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 "[En

Re: .ONESEHLL not working as expected in 3.82

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sat, 27 Apr 2013 15:32:22 -0400 > > Well, we already maintain a list of modules that are loaded in > the .LOADED variable. Although it's not written like that today, I have > no problem changing the code to check that variable to see whether the

Re: .ONESEHLL not working as expected in 3.82

> From: Paul Smith > Cc: make-...@gnu.org, bug-make@gnu.org > Date: Sat, 27 Apr 2013 14:28:18 -0400 > > 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 availabl

Re: .ONESEHLL not working as expected in 3.82

> From: Paul Smith > Cc: make-...@gnu.org, bug-make@gnu.org > Date: Sat, 27 Apr 2013 12:54:10 -0400 > > Also, I wonder if you have a few minutes to go through the open Windows > bugs in Savannah and make a comment or whatever to those which are still > waiting (some are waiting for other people,

[bug #7201] Windows Path search works incorrectly

Update of bug #7201 (project make): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #4: I'm closing this bug be

[bug #16476] WINDOWS32 vs. HAVE_ANSI_COMPILER macros

Update of bug #16476 (project make): Open/Closed:Open => Closed Fixed Release:None => 3.82 ___ Follow-up Comment #6: I'm closing this bug b

[bug #17277] Pathes longer than 128 Chars fail with make under windows

Update of bug #17277 (project make): Open/Closed:Open => Closed Fixed Release:None => 3.82 Triage Status:None => Verified

[bug #17433] Enhancement in process creation functions in sub_proc.c

Update of bug #17433 (project make): Severity: 3 - Normal => 1 - Wish Status:None => Fixed Open/Closed:Open => Closed Fixed Release:

[bug #20542] Regression: windows gnumake + MKS shell + Special Shell Chars

Update of bug #20542 (project make): Item Group: Bug => Enhancement Status:None => Works for me Triage Status:None => Need Info

[bug #20550] Crash with setting SHELL from the commandline

Update of bug #20550 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => 3.82 Triage Status:

[bug #24405] BATCH_MODE_ONLY_SHELL configuration fails with unixy shells

Update of bug #24405 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => 3.82 Triage Status:

[bug #30730] SHELL does not work correctly on Windows

Update of bug #30730 (project make): Severity: 3 - Normal => 1 - Wish Item Group: Bug => Enhancement Status:None => Later Triage Status:

[bug #31150] The make doesn't work on Windows x64 platforms

Update of bug #31150 (project make): Triage Status:None => Need Info ___ Follow-up Comment #1: Hi, Could you perhaps show a minimal Makefile that reproduces the problem? Also, is this a 64-bit

[bug #37065] $(wildcard dir/*/.) is wrong (worked fine in 3.81)

Update of bug #37065 (project make): Triage Status:None => Need Info ___ Reply to this item at: ___ Messag

[bug #38626] make fails on windows with antivirus software

Update of bug #38626 (project make): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => SCM Triage Status:

Re: .ONESEHLL not working as expected in 3.82

> Date: Mon, 30 Aug 2010 17:09:51 +0100 > From: "Anjum Naseer" > > I have built the 3.82 version of GNU Make using the Microsoft Visual C++ > compiler and it seems to work fine. > However, I cannot get it to work correctly with the .ONESHELL option. > I created a dummy makefile (dummy.mak) with t

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Sat, 27 Apr 2013 13:09:02 +0300 > From: Eli Zaretskii > Cc: f.heckenb...@fh-soft.de, bug-make@gnu.org > > > The basic feature can be tested trivially like this: > > > > all: one two > > > > one two: > > @echo start $@

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> From: Paul Smith > Cc: Frank Heckenbach , bug-make@gnu.org > Date: Sun, 21 Apr 2013 19:30:05 -0400 > > 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

Re: Fwd: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Fri, 26 Apr 2013 09:05:18 +0100 > From: Tim Murphy > Cc: "Paul D. Smith" , "bug-make@gnu.org" > > > How much would you use for the timeout, though? A sub-Make could > > legitimately run for a very long time, depending on what's in the > > Makefile. > > > > FWIW, I currently let Make wai

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Thu, 25 Apr 2013 02:16:33 +0200 > Cc: e...@gnu.org, bug-make@gnu.org > From: Frank Heckenbach > > > > On Windows, you said fstat was very expensive, didn't you? Or is > > > lseek even worse? > > > > I think anything that potentially moves the file pointer can be > > sometimes expensive a

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Wed, 24 Apr 2013 21:19:45 +0300 > From: Eli Zaretskii > Cc: bug-make@gnu.org > > > Date: Wed, 24 Apr 2013 19:14:01 +0200 > > Cc: bug-make@gnu.org > > From: Frank Heckenbach > > > > > Testing clearly shows it doesn't: GetFileInformat

Re: Fwd: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Thu, 25 Apr 2013 19:36:28 +0100 > From: Tim Murphy > Cc: "bug-make@gnu.org" > > 1) sem_timedwait() in posix lets you timeout so in a big build when > something crashes or just sits around, there is at least the option of > printing an error message or giving up on locking from that poin

Suspicious compiler warnings

FYI: when compiling git head of a few days ago, I see several warnings. They are mostly harmless, but these two look real, especially the first one: implicit.c: In function 'pattern_search': implicit.c:225:15: warning: variable 'deps' set but not used [-Wunused-but-set-variable] job.c: In

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Thu, 25 Apr 2013 05:14:41 +0200 > Cc: psm...@gnu.org, bug-make@gnu.org > From: Frank Heckenbach > > My suggestion was under the assumption that we use different > declarations because of different types anyway -- which I still > recommend, though Paul might have to decide this one. Yes,

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Thu, 25 Apr 2013 02:16:33 +0200 > Cc: e...@gnu.org, bug-make@gnu.org > From: Frank Heckenbach > > > > I can't follow you here. On POSIX, we don't need to pass a fd > > > because it's always stdout/stderr. Or do mean something else? > > > > I meant the file descriptor passed to fcntl to p

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Wed, 24 Apr 2013 22:55:59 +0100 > From: Tim Murphy > Cc: "bug-make@gnu.org" > > trying to pass kernel object handles around (seems a bit nasty to > me)? Why is that nasty? The handle is returned by a documented interface, and communicating it to another process is an officially documen

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> From: Paul Smith > Cc: Frank Heckenbach , bug-make@gnu.org > Date: Wed, 24 Apr 2013 16:03:56 -0400 > > > Or maybe we should abandon this optimization and take the lock > > regardless. How bad can that be? > > Well, we want to know if the file has any content anyway: for example we > don't wan

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Wed, 24 Apr 2013 20:46:14 +0200 > Cc: p...@mad-scientist.net, bug-make@gnu.org > From: Frank Heckenbach > > > > I don't see why it would terminate prematurely > > > > It was long ago, but I presume I thought about the ^Z character that > > some programs write or interpret to signal end o

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> From: Paul Smith > 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 talking about temp > files, not NFS files or something, it's probably n

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Wed, 24 Apr 2013 10:34:20 -0700 > From: David Boyce > Cc: Frank Heckenbach , > "bug-make@gnu.org" > > On Wed, Apr 24, 2013 at 10:26 AM, Tim Murphy wrote: > > > I would suggest pretending that one has semaphores first with some nice > > little abstraction and then implementing th

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Wed, 24 Apr 2013 19:14:01 +0200 > Cc: bug-make@gnu.org > From: Frank Heckenbach > > > Testing clearly shows it doesn't: GetFileInformationByHandle simply > > fails for handles open on console devices and the null device. And we > > will be comparing handles for console devices in the maj

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Wed, 24 Apr 2013 18:50:15 +0200 > Cc: bug-make@gnu.org > From: Frank Heckenbach > > > That's one way. Another one is to discuss the design more thoroughly > > before the patches are accepted. > > I think it was discussed quite extensively. Also in retrospect, I > don't see how the desig

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Thu, 18 Apr 2013 21:57:56 +0300 > From: Eli Zaretskii > Cc: bug-make@gnu.org, bo...@kolpackov.net > > > Date: Thu, 18 Apr 2013 19:09:06 +0200 > > From: Frank Heckenbach > > > > > . calculation of combined_output in start_job_command will need t

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Wed, 24 Apr 2013 05:56:49 +0300 > From: Eli Zaretskii > Cc: f.heckenb...@fh-soft.de, bug-make@gnu.org > > I will see if locking works on console handles; if not, I will have > to introduce a command-line argument for passing the name or the > handle of a mutex

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> From: Paul Smith > Cc: Frank Heckenbach , bug-make@gnu.org > Date: Tue, 23 Apr 2013 16:54:33 -0400 > > Without knowing what kind of resource Windows can take locks on, we > can't really know how to help with that. The only resources that don't need their names passed to sub-Make are the standa

Re: [bug #33138] .PARLLELSYNC enhancement with patch

at least to me, and therefore it could easily happen that non-replication of some seemingly secondary detail completely breaks the design. After all, the basic models of Unix and Windows regarding processes and signals are very different. > > > On Tue, Apr 23, 2013 at 10:50 AM, Eli Zarets

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> From: Paul Smith > Cc: David Boyce , f.heckenb...@fh-soft.de, > bug-make@gnu.org > Date: Tue, 23 Apr 2013 15:04:39 -0400 > > When thinking about this, remember that it's not enough to consider how > a single make invocation will work. If you run with a single make > instance under -j, t

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Tue, 23 Apr 2013 11:29:35 -0700 > From: David Boyce > Cc: Frank Heckenbach , bug-make > > Since you asked basic questions I'm going to start this at a basic level. > Apologies if it covers some stuff you already know or if I misinterpreted > the questions. Note that I haven't actually lo

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Fri, 19 Apr 2013 11:54:05 +0200 > Cc: bo...@kolpackov.net, bug-make@gnu.org > From: Frank Heckenbach > > Eli Zaretskii wrote: > > > Initial investigation indicates that tmpfile should do the job just > > fine: the file is deleted only when the last descript

Re: Building Make out of Git: Gettext requirements

> From: Paul Smith > Cc: bug-make@gnu.org > Date: Sat, 20 Apr 2013 14:02:43 -0400 > > I believe this is only a problem building from git. If you build from a > distribution tarball then you don't need to have any particular version > of gettext installed. For developers who build from git, they

Re: Building Make out of Git: Gettext requirements

> Date: Sat, 20 Apr 2013 17:56:45 +0200 > From: Stefano Lattarini > CC: Eli Zaretskii , bug-make@gnu.org > > On 04/20/2013 05:44 PM, Paul Smith wrote: > > On Sat, 2013-04-20 at 13:50 +0300, Eli Zaretskii wrote: > >> Do we really need to require 0.18.1 or can this

Re: Building Make out of Git: Gettext requirements

> From: Paul Smith > 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? > > I hacked configure.ac to require 0.17,

Re: [PATCH 4/4] Windows: MSYS Autotools doc disabling hack

> Date: Sat, 20 Apr 2013 15:52:03 +0100 > From: Ray Donnelly > Cc: bug-make@gnu.org > > I tried with various autoconf versions, including 2.65, and also with three > different versions of m4.exe ( all from > http://sourceforge.net/projects/mingw/files/MSYS/Extension/m4/ ) with both > dos and unix

Re: [PATCH 4/4] Windows: MSYS Autotools doc disabling hack

> Date: Tue, 16 Apr 2013 17:24:42 +0100 > From: Ray Donnelly > Cc: bug-make@gnu.org > > This is all, of course, with sources from git. > > If configure contains the line continuation ('\') in AC_CONFIG_FILES, > then we end up with this lovely construct in configure: > "config/Makefile") CONF

Building Make out of Git: Gettext requirements

Trying to build the current git head, I get this: $ autoreconf -i autopoint: *** The AM_GNU_GETTEXT_VERSION declaration in your configure.ac file requires the infrastructure from gettext-0.18.1 but this version is older. Please upgrade to gettext-0.18.1 or newer. au

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Fri, 19 Apr 2013 11:54:05 +0200 > Cc: bo...@kolpackov.net, bug-make@gnu.org > From: Frank Heckenbach > > > Is there a simple enough Makefile somewhere that could be used to test > > this feature, once implemented? > > We have a test in the test suite (output-sync). Can you use that? I h

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Fri, 19 Apr 2013 00:06:52 +0300 > From: Eli Zaretskii > Cc: bo...@kolpackov.net, bug-make@gnu.org > > > > > Indeed, as you suggested earlier, it might be useful to use the main > > > > part of open_tmpfile() (i.e. without the fdopen()), though we&#

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Thu, 18 Apr 2013 22:05:33 +0200 > Cc: bug-make@gnu.org, david.s.bo...@gmail.com, psm...@gnu.org, > bo...@kolpackov.net > From: Frank Heckenbach > > Eli Zaretskii wrote: > > > > Date: Thu, 18 Apr 2013 20:39:44 +0200 > > > Cc: psm...@gnu

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Thu, 18 Apr 2013 20:39:44 +0200 > Cc: psm...@gnu.org, e...@gnu.org, bo...@kolpackov.net > From: Frank Heckenbach > > Indeed, as you suggested earlier, it might be useful to use the main > part of open_tmpfile() (i.e. without the fdopen()), though we'd have > to manually remove the file th

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Thu, 18 Apr 2013 19:09:06 +0200 > From: Frank Heckenbach > > > . calculation of combined_output in start_job_command will need to be > >reimplemented for Windows, since the reliance on st_dev and st_ino > >makes assumptions that are false on Windows. > > What we need is basicall

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> From: Paul Smith > Cc: bug-make@gnu.org, f.heckenb...@fh-soft.de > Date: Wed, 17 Apr 2013 13:11:29 -0400 > > 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&qu

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> From: Paul Smith > Cc: bo...@kolpackov.net, bug-make@gnu.org, f.heckenb...@fh-soft.de > Date: Tue, 16 Apr 2013 12:56:21 -0400 > > On Tue, 2013-04-16 at 19:20 +0300, Eli Zaretskii wrote: > > > From: Paul Smith > > > Cc: bo...@kolpackov.net, bug-make@gnu.org, f

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> From: Paul Smith > 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 of tmpfile() are on Windows. >

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> From: Paul Smith > Cc: bo...@kolpackov.net, bug-make@gnu.org, f.heckenb...@fh-soft.de > Date: Tue, 16 Apr 2013 07:47:08 -0400 > > On Tue, 2013-04-16 at 11:30 +0300, Eli Zaretskii wrote: > > > Date: Tue, 16 Apr 2013 05:54:13 + > > > From: "Paul D. Smit

Re: [PATCH 4/4] Windows: MSYS Autotools doc disabling hack

> Date: Tue, 16 Apr 2013 13:41:53 +0100 > From: Ray Donnelly > > This is just for reference for anyone who wants to build gnumake on > Windows. I don't want it to be applied as the real bugs are in Autotools. What are the bugs, and how do they manifest themselves? __

Re: [PATCH 2/4] Windows: Add 'move' to sh_cmds_dos

> Date: Tue, 16 Apr 2013 13:39:58 +0100 > From: Ray Donnelly > > 'move' is not listed as a cmd.exe builtin when it needs to be. > > > Not sure how this hasn't been spotted and fixed before now! It's not a bug, it is done on purpose: 'move' is a built-in on some versions of Windows, and a .exe

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Tue, 16 Apr 2013 09:56:01 +0100 > From: Tim Murphy > > IMHO, get it in and fix the details later because as it is it's exceedingly > useful. It's already in, that's what Paul's message was about. ___ Bug-make mailing list Bug-make@gnu.org http

Re: [bug #33138] .PARLLELSYNC enhancement with patch

> Date: Tue, 16 Apr 2013 05:54:13 + > From: "Paul D. Smith" > > I did a little bit of code rearrangement, but I still think this code will not > work on Windows and might possibly not compile on Windows. Indeed, it will not. Some cursory comments below. > Hopefully we can fix that. We sha

Re: [bug #712] GNU make can't handle spaces in pathnames

> Date: Thu, 28 Feb 2013 10:32:32 +0100 > From: Reinier Post > > I don't think make can be expected to handle spaces in filenames > because by design it relies on many other tools and scripts that > cannot handle them or handle them in very idiosyncratic ways. > You're in for a lot of trouble reg

Re: [Question] How can i stop build immediately in build fail?

> From: Oleksandr Gavenko > Date: Sat, 12 Jan 2013 11:17:17 +0200 > Cc: bug-make@gnu.org, help-m...@gnu.org > > On 2013-01-12, Eli Zaretskii wrote: > > >> Date: Fri, 11 Jan 2013 17:57:28 -0800 > >> From: David Boyce > >> Cc: help-make , bug-make

Re: [Question] How can i stop build immediately in build fail?

> Date: Fri, 11 Jan 2013 17:57:28 -0800 > From: David Boyce > Cc: help-make , bug-make > > % make -j2 > sleep 3 > while echo ok; do sleep 1; done > ok > ok > ok > ok > exit 1 > stopping make! > make: *** [job2] Terminated > make: *** [job1] Terminated > Terminated Which is dangerous, since when

Re: Dependency violation in parallel build (3.82, regression)

> Date: Sun, 30 Dec 2012 23:38:44 +0100 > From: Frank Heckenbach > > BTW, I wanted to check against the current repository version, but > when I tried to fetch it as described on > https://savannah.gnu.org/git/?group=make, I got: > > % git clone git://git.savannah.gnu.org/make.git > Cloning into

Re: need help on "make -j" parameter, it will let the system hung easily.

> Date: Sat, 15 Dec 2012 19:08:06 +0400 > From: "Dmitry V. Levin" > > gnulib has a nproc module that can "detect the number of processors": > http://git.savannah.gnu.org/cgit/gnulib.git/tree/modules/nproc > Judging from the number of #if's in its implementation it must be quite > portable. :) Bu

Re: need help on "make -j" parameter, it will let the system hung easily.

> From: Paul Smith > Cc: warner.w...@hp.com, Bug-make@gnu.org > Date: Sat, 15 Dec 2012 09:35:18 -0500 > > On Fri, 2012-12-14 at 17:07 +0200, Eli Zaretskii wrote: > > Does it even make sense to use -j with no arguments? Should we > > perhaps remove that possibility,

Re: need help on "make -j" parameter, it will let the system hung easily.

> Date: Fri, 14 Dec 2012 20:37:54 +0400 > From: "Dmitry V. Levin" > > > > make: More parallel jobs (-jN) than this platform can handle > > > requested. > > > make: Resetting to single job (-j1) mode. > > > > I see no message like this in the current Make sources. Maybe I'm > > missing

Re: need help on "make -j" parameter, it will let the system hung easily.

> From: "Wang, Warner" > CC: "Bug-make@gnu.org" > Date: Fri, 14 Dec 2012 15:42:04 + > > btw there is an internal limit, which is 4096 jobs, either on my mainframe or > PC. If I use "-j 4097" it will complain: > [root@lion linux-3.3.0-0.20.el7]# make -j 4097 > make: More parallel jo

Re: need help on "make -j" parameter, it will let the system hung easily.

> From: Paul Smith > Date: Fri, 14 Dec 2012 09:59:31 -0500 > Cc: "Bug-make@gnu.org" > > This basically says that if you use "-j" with no arguments, make will > run as many jobs as the _makefile_ allows (defined by your prerequisite > rules). It pays no attention to the limits of your system. >

[bug #37648] [Regression from 3.81] Cannot build projects having files with German/French/other specific characters

Follow-up Comment #1, bug #37648 (project make): Please attach a minimal Makefile needed to reproduce the problem. It is hard to reason about this without at least that much. Off-hand, I'd say that I find it hard to believe this is a regression. Make used a temporary batch file in version 3.81

[bug #37065] $(wildcard dir/*/.) is wrong (worked fine in 3.81)

Follow-up Comment #3, bug #37065 (project make): Could you please show a short Makefile to reproduce the problem? Thanks. ___ Reply to this item at: ___

Re: Bug: documentation suggests incorrect behavior (was: Bug: concurrent make and references to different names of a multi-target rule)

> Date: Sat, 09 Jun 2012 15:57:48 +0300 > From: Shachar Shemesh > CC: bug-make@gnu.org > > At the time I wanted to reply, but failed to find my sources. Today I > happened to stumble on them. The misleading behavior, i.e. - building > two targets with one receipt invocation, is suggested by the >

Re: It's should be mkdir .dep 2>nul under win32

> From: 罗勇刚(Yonggang Luo) > Date: Wed, 11 Apr 2012 12:36:32 +0800 > > Build of configuration Default for project catos-linux > > mingw32-make -d all > GNU Make 3.82 > Built for i386-pc-mingw32 > Copyright (C) 2010 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or

Re: Patch to allow make to load plugins that add new functions.

> From: Paul Smith > CC: David Boyce , bug-make@gnu.org > Date: Fri, 6 Apr 2012 16:13:47 -0400 > > Maybe this is just irrational prejudice but I've never had a good > experience using libtool and I'm SO uninterested in fighting with it in > GNU make. > > I will admit that my distaste is so extre

Re: Patch to allow make to load plugins that add new functions.

> Date: Fri, 6 Apr 2012 13:30:31 -0400 > From: David Boyce > Cc: tnmur...@gmail.com, bug-make@gnu.org > > Sorry, I've never used libltdl. Maybe it would have been better just > to say "libraries exist to paper over the differences between various > platforms dynamic linking APIs; consider not rei

<    1   2   3   4   5   6   7   8   9   >