From: "Andre Srinivasan" [EMAIL PROTECTED]
Date: Thu, 15 Jun 2000 10:05:18 -0700 (GMT-8:00)
I just checked that indeed bash is being invoked:
$ cat Makefile
all:
echo $$SHELL
$ make
echo $SHELL
d:/cygnus/cygwin-b20/usr/local/bin/sh.exe
I've verified on my system that suffix rules with prerequisites do
seem to work, as in this example:
.c.o: foo.h
@echo $
Assuming you have foo.c and foo.h in your directory, type "make foo.o",
and see Make echo the name "foo.c".
Is something wrong with the assertion in the docs that
On Fri, 12 Jan 2001, Paul D. Smith wrote:
Make use the creation time instead the modification time for update check.
??? Is that a question? Can we possibly have more info, including some
motivation?
___
Bug-make mailing list
[EMAIL PROTECTED]
Date: Wed, 29 Oct 2003 21:07:39 +
From: J. Grant [EMAIL PROTECTED]
ok, I've cc [EMAIL PROTECTED], so maybe someone can tell me if signal
numbers are decoded. Would you include this internally? or use a lib etc?
The signal names are decoded if the underlying library supports them.
Date: Thu, 30 Oct 2003 00:02:55 +
From: J. Grant [EMAIL PROTECTED]
I noticed on this list list they talk about it being a failed exec:
http://www.cygwin.com/ml/cygwin/2003-06/msg00674.html
I doubt if this is a signal. It's more probably an error code from a
library function that
Date: Sat, 22 Nov 2003 21:00:42 -0500
From: Paul D. Smith [EMAIL PROTECTED]
Note that this can't be done on Windows, only on UNIX. Well, anyway,
I've never done it on Windows and I've never heard of anyone who has.
The tools required to build from the CVS archive (GNU m4, Perl, GNU
effect (which I think is a feature) should be
mentioned in make.texi.
Finally, please make sure dosbuild.bat has DOS line endings after you
apply the diffs below. (Otherwise, some DOS/Windows shells will
refuse to run it.)
TIA
ChangeLog entries:
2005-02-19 Eli Zaretskii [EMAIL PROTECTED
Date: Sat, 19 Feb 2005 17:42:42 -0500
Cc: bug-make@gnu.org
From: Paul D. Smith [EMAIL PROTECTED]
ez 5. On variable.c, the function define_automatic_variables used to
ezalways export SHELL (there was a line v-export = v_export; right
ezafter SHELL was assigned the default
Date: Wed, 16 Feb 2005 01:45:41 -0500
From: [EMAIL PROTECTED]
http://make.paulandlesley.org/make-3.81beta2.tar.bz2
http://make.paulandlesley.org/make-3.81beta2.tar.gz
Here's an annoyance with this beta version when I build it with DJGPP
and GCC 3.3.3 or 3.4.3:
gcc -I. -I. -I.
Date: Mon, 21 Feb 2005 08:37:38 -0500
Cc: bug-make@gnu.org, make-w32@gnu.org
From: Paul D. Smith [EMAIL PROTECTED]
ez file.c: In function `file_timestamp_cons':
ez file.c:554: warning: comparison is always true due to limited range
of data type
Unfortunately there's not much
Follow-up Comment #6, bug #15718 (project make):
Please try the pretest version of Make 3.81 (beta4). This problem should be
fixed in that version.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718
Follow-up Comment #7, bug #15718 (project make):
Let me clarify: Comment #6 is for Doug Konrad.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=15718
___
Follow-up Comment #8, bug #15718 (project make):
Here's a response to Comments #2 and #5:
It's not true that ``SHELL variable assignment within Makefile doesn't work
for Win32 port of GNU make''. It's just that it's a bit tricky, and also
your test Makefile was too simple to force Make to
Follow-up Comment #10, bug #15718 (project make):
I'm not sure it's a bug in the Windows port that an arbitrary value of SHELL
does not immediately goto slow; after all, it's hard to imagine radically
different quoting rules for the relatively simple-minded shells we have on
WIndows.
But I will
From: David Ergo [EMAIL PROTECTED]
Date: Tue, 28 Feb 2006 13:08:10 +0100
Cc: Xavier Marichal [EMAIL PROTECTED],
=?ISO-8859-1?Q?S=E9bastien?= Frippiat [EMAIL PROTECTED]
I managed to compile a working version of make 3.81rc1 for MSYS but I
had do some modifications.
first
Follow-up Comment #14, bug #15718 (project make):
Paul is right: the Windows port does not invoke cmd.exe with the -c switch.
So there's no bug here and nothing to fix.
Here are the gory details:
If you look closer at job.c:construct_command_argv_internal, you will see
that, in the `slow'
Date: Sat, 4 Mar 2006 20:17:20 +0200
From: Eli Zaretskii [EMAIL PROTECTED]
The fact that it doesn't work with setting SHELL from the command line might
mean there's another place in the code where the special treatment of cmd
should be added. Hmmm...
Fixed thusly:
2006-03-04 Eli
Follow-up Comment #19, bug #15718 (project make):
The real bugs wrt SHELL that still need to be worked on are:
1. When the Windows port searches along PATH for a shell whose name is not
cmd, it does not try to append the executable extensions, so SHELL=foo would
not find foo.exe
2. If the
From: David Ergo [EMAIL PROTECTED]
Cc: bug-make@gnu.org, Xavier Marichal [EMAIL PROTECTED],
=?ISO-8859-1?Q?S=E9bastien?= Frippiat [EMAIL PROTECTED]
Sorry, but as a understand the code, sh_chars_sh is an intermediate
variable as sh_chars_dos is, and sh_chars is the real variable to
From: David Ergo [EMAIL PROTECTED]
Cc: bug-make@gnu.org, Xavier Marichal [EMAIL PROTECTED],
=?ISO-8859-1?Q?S=E9bastien?= Frippiat [EMAIL PROTECTED]
Date: Tue, 07 Mar 2006 09:28:46 +0100
Ok, now I understand. But for MSYS, as it uses unix code, sh_chars_sh is
not defined and the
Follow-up Comment #16, bug #15718 (project make):
Thanks.
Does it work if you put
SHELL=cmd
inside the Makefile? That does work for me.
The fact that it doesn't work with setting SHELL from the command line might
mean there's another place in the code where the special treatment of cmd
Follow-up Comment #17, bug #15718 (project make):
Okay, I've found the culprit: setting SHELL from the command-line arguments
wasn't handled as setting it from the Makefile. I think that's a bug (the
Unix version doesn't handle SHELL in any special way when it comes from the
command line), so I
Follow-up Comment #2, bug #16132 (project make):
I cannot reproduce this, either, on Windows XP. I tried with and without a
Unixy sh.exe on my PATH, and both behave as expected, identically to v3.80
and v3.80b4.
(The behavior with and without sh.exe is not identical, but that's because
the
Follow-up Comment #11, bug #16132 (project make):
The result without sh.exe is the expected one. So Make is working correctly,
and the problem is is (in)compatibility with the Cygwin shell.
When I need a Unixy shell, I use the old port of zsh. You should be able to
find it on the net (sorry,
Follow-up Comment #13, bug #16132 (project make):
Did the OP build the previous versions of Make with the same compiler as the
release candidate? If not, perhaps therein lies the reason for the
difference, especially if the other versions are Cygwin ports (as opposed to
to rc1 that was built
Follow-up Comment #18, bug #16132 (project make):
Then I suggest that you try replacing the shell as well. As I already wrote,
I cannot reproduce this with my version of sh.exe.
Alternatively, you could try to debug this and see where exactly the problem
lies. If you can afford spending some
Follow-up Comment #16, bug #16132 (project make):
Yes, I'm the same Eli Z.
Paul is correct asking you for the details of the old versions: how they were
built and with what compier.
___
Reply to this item at:
Follow-up Comment #21, bug #16132 (project make):
Thanks, Pieter. This means there's no bug at all: the comments inside
config.h.W32 clearly say to define HAVE_CYGWIN_SHELL if you are using such a
shell. (Paul, do you think we should emphasize this in README.W32?)
I don't know why echo is
Date: Sun, 26 Mar 2006 13:14:49 +0200
From: Sven Joachim [EMAIL PROTECTED]
1) Version b) lists the ``GNU General Public License'' as an Invariant
Section, but does not actually include it.
It should mention the GFDL section (which _is_ included) instead. I'm
guessing that when the
Date: Mon, 27 Mar 2006 23:05:41 +0200
From: [EMAIL PROTECTED]
I'm using gnumake 3.78 (also tried 3.8) buided with VC on W2000.
I've a problem with overriding default SHELL value from sh.exe to cmd.exe.
Yes, this is a known problem with Make on Windows. I believe it has
been corrected in
Date: Mon, 03 Apr 2006 14:25:12 +0400
From: =?KOI8-R?Q?=E4=C5=CA=D4=C5=D2_=E1=CC=C5=CB=D3=C1=CE=C4=D2_=F7=C1?=
=?KOI8-R?Q?=CC=C5=D2=C9=C5=D7=C9=DE?= [EMAIL PROTECTED]
After update GNU make from 3.80 up to 3.81 i cannot build gcc 4.0.2,
4.0.3 and 4.1.0 whith same error:
rm -f
Date: Thu, 6 Apr 2006 16:33:04 -0400
From: Paul D. Smith [EMAIL PROTECTED]
Cc:
All of the behavior you're seeing is explained in my webpages referenced
earlier.
Given the number of times this comes up in various forums and in the
bug tracker, would it be a good idea to include in the
Follow-up Comment #1, bug #16362 (project make):
Sounds like I should stop trying to maintain the Windows port, as I cause
more trouble than help.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=16362
Follow-up Comment #3, bug #16476 (project make):
AFAIK, WINDOWS32 is used because the GNU Project doesn't like to be part of
those who say that MS-Windows is ``a win''. Therefore, we cannot remove
WINDOWS32 and use _WIN32 instead.
As for its usage policy, WINDOWS32 should be used for OS- and
Follow-up Comment #1, bug #16505 (project make):
This is not a regression, but a deliberate change whose purpose is to follow
the Posix specifications. From NEWS:
- quotation --
* WARNING: Backward-incompatibility!
In order to comply with POSIX, the way in
Follow-up Comment #6, bug #16505 (project make):
The Posix behavior has its merits: without it, how does one pass a command
line with embedded newlines from a Makefile? The Posix handling of newlines
in single quotes permits this.
___
Follow-up Comment #11, bug #16505 (project make):
I can understand everything you are saying -- the backward incompatibility,
the suggestion to add an explicit warning, the works. The only thing I do
NOT understand is why do you insist on telling about the EOF error etc., when
you have at least
Date: Fri, 05 May 2006 10:14:38 -0400
From: =?ISO-8859-1?Q?Pablo_Alarc=F3n_Pavez?= [EMAIL PROTECTED]
Command: make clean
OS: Windows XP version 2002, service pack 2
make version: 3.80
It interprets rmdir /q /s lib as rmdir /q, rmdir /s and rmdir lib with
errors.
Do you have an
Follow-up Comment #3, bug #16362 (project make):
The following patch fixes this bug:
--- function.c~02006-04-01 12:36:40.0 +0300
+++ function.c 2006-05-27 15:58:26.984375000 +0300
@@ -1589,12 +1589,25 @@ func_shell (char *o, char **argv, const
int pid;
#ifndef __MSDOS__
Date: Tue, 30 May 2006 10:49:17 -0400
Cc: bug-make@gnu.org
From: Paul D. Smith [EMAIL PROTECTED]
The realpath function will resolve both absolute and relative paths
and return the absolute pathname corresponding to pathname. All but
the last component of pathname must exist when
From: Boris Kolpackov [EMAIL PROTECTED]
Date: Wed, 31 May 2006 07:48:12 + (UTC)
I just checked the page for realpath in SUS and I don't see anything
that implies this. My understanding that all components of the path
must exist.
So it's probably system-dependent.
Yes, that seems to
From: Roland Puntaier [EMAIL PROTECTED]
Date: Fri, 2 Jun 2006 17:36:00 +0200
process_easy: DuplicateHandle(In) failed is issued, when redirecting the
mingw32-make output from a parent process.
GetStdHandle returns 0, which is not an error, but also no handle to be
duplicated.
Thanks
Follow-up Comment #1, bug #17105 (project make):
This problem doesn't happen with the native Windows build of Make 3.81. If
you rewally need to use the Cygwin build, I suggest to take this up with the
Cygwin maintainers: I don't know whether the Cygwin version is supposed to
support file names
Date: Mon, 31 Jul 2006 16:16:53 +0200 (MEST)
From: Stefan Renz[EMAIL PROTECTED]
I just tried to build gnu make for win32 and got an error message like this:
syntax error vpath.c line 348
There are too many actual parameters etc.
I changed it from
n = rindex(*file,, '\\');
to
n =
Follow-up Comment #1, bug #17381 (project make):
The following patch should take care of this:
2006-08-12 Eli Zaretskii [EMAIL PROTECTED]
* job.h [__MSDOS__]: Use the same prototype for child_execute_job as
__EMX__
does.
--- job.h~0 2006-02-12 02:16:04.0 +0200
as it ought to be
Thanks.
Here's a patch to fix this:
2006-08-12 Eli Zaretskii [EMAIL PROTECTED]
* job.h [__MSDOS__]: Use the same prototype for child_execute_job
as __EMX__ does.
--- job.h~0 2006-02-12 02:16:04.0 +0200
+++ job.h 2006-08-12 15:44
Follow-up Comment #1, bug #17521 (project make):
This is not a bug, but a documented change in behavior, intended to bring GNU
Make in line with Posix specification for Make.
From the NEWS file:
* WARNING: Backward-incompatibility!
In order to comply with POSIX, the way in which GNU make
From: Dan Jacobson [EMAIL PROTECTED]
Date: Tue, 05 Sep 2006 03:15:52 +0800
In the make concept index, I hit RET upon
* :: rules (double-colon): Double-Colon.(line 6)
and I get
byte-code: No such node or anchor: : rules (double-colon): Double-Colon
here in Debian's
From: Bas Holleman [EMAIL PROTECTED]
Date: Fri, 29 Sep 2006 10:01:16 + (UTC)
Hi Sebastien,
About the problem: gmake begin_process CreateProcess failed.
I cannot find the beginning of this thread in the archives.
This is my experience: The Windows PATH variable is to long. gmake runs
From: Dan Jacobson [EMAIL PROTECTED]
Date: Sun, 29 Oct 2006 08:02:17 +0800
One can set SHELL, but there's no way to get rid of the -c in case one
wants too. E.g., one wants to make SHELL=mysql as an experiment etc.
mysql would need a -e, etc.
Doesn't it work to customize shell-file-name
From: Dan Jacobson [EMAIL PROTECTED]
Date: Mon, 06 Nov 2006 05:58:15 +0800
One can set SHELL, but there's no way to get rid of the -c in case one
wants too. E.g., one wants to make SHELL=mysql as an experiment etc.
mysql would need a -e, etc.
EZ Doesn't it work to customize
Date: Wed, 15 Nov 2006 13:23:31 +0200
From: Maxim Vexler [EMAIL PROTECTED]
To make a good starting point I'm looking for a small (tiny) open
source project, one with a few cpp files, some small .h files. A bonus
would be if this project uses a small but stable (compile wise) 3rd
party
to fix that, so if you need this
ASAP, and can rebuild Make from sources on your machine, please try
the patch below and tell me if it works for you.
2006-05-27 Eli Zaretskii [EMAIL PROTECTED]
* function.c (IS_ABSOLUTE, ROOT_LEN): New macros.
(abspath): Support systems that define
From: Paul Smith [EMAIL PROTECTED]
Date: Mon, 11 Dec 2006 19:42:51 -0500
Cc: bug-make@gnu.org
This test is kind of strange. Unless there's some specific reason the
makefile REQUIRES the CURDIR variable to be set by make, it should be
rewritten:
ifndef CURDIR
$(error Please define the
Date: Thu, 18 Jan 2007 22:28:12 +0100
From: Georg-Johann Lay [EMAIL PROTECTED]
I have some trouble with GNU make. The make comes from WinAVR, a
distribution of avr-gcc for Win32, i.e. mingw. It is the most recent
build from 2006-04-21
But the output you show from make --version, viz.
From: Dirk Heinrichs [EMAIL PROTECTED]
Date: Sat, 20 Jan 2007 22:22:04 +0100
So the left hand doesn't know what the right hand does?
??? Would you care to explain where do you see two hands that don't
know each what the other one does?
As far as I see from Paul's clear description is that
Follow-up Comment #1, bug #18872 (project make):
You are using the Cygwin build of Make 3.81, which does not support drive
letters in file names (I believe the announcement on the Cygwin mailing list
at the time they released Make 3.81 explains why they discontinued support
for drive letters.)
Date: Wed, 7 Feb 2007 11:51:56 -0500
From: Raheja, Himanshu [EMAIL PROTECTED]
gcc -I.. -I. -I./include -I./common -D_FILE_OFFSET_BITS=64
-I/usr/include -g -W -Wall -Werror -Wno-unused -g -O2
-D_FILE_OFFSET_BITS=64 -g -W -Wall -Werror -Wno-unused -DHAVE_CONFIG_H
-c ./common/linksupport.c -o
Date: Sat, 24 Feb 2007 18:04:28 +0800 (CST)
From: haibin zhang [EMAIL PROTECTED]
Cc:
Hi all:
automake-1.10 can't work with make-3.81 in Mingw in Windows XP, but
automake-1.9.6 can work with make-3.81.
I tested that automake-1.10 can work with make-3.79.1 in Mingw in Windows XP.
Date: Thu, 3 May 2007 23:20:31 +0100
From: James Youngman [EMAIL PROTECTED]
Cc: bug-make@gnu.org,
[EMAIL PROTECTED] [EMAIL PROTECTED]
[ CC += bug-make@gnu.org ]
On 5/3/07, Ulrich Drepper [EMAIL PROTECTED] wrote:
On today's call we agreed on the following proposal (names are
From: Paul Smith [EMAIL PROTECTED]
Date: Fri, 11 May 2007 15:15:34 -0400
Cc: GNU Make bug-make@gnu.org
function.c: In function 'func_shell':
function.c:1597: warning: variable 'error_prefix' might be clobbered by
'longjmp' or 'vfork'
function.c:1589: warning: argument 'o' might be
Follow-up Comment #1, bug #20550 (project make):
Thanks. I believe this was already reported, and the attached patch (already
sent to the maintainer) should fix it.
(file #13412)
___
Additional Item Attachment:
Follow-up Comment #1, bug #20549 (project make):
Thanks. I believe the attached patch should take care of this bug. Does
it?
(file #13414)
___
Additional Item Attachment:
___
Follow-up Comment #3, bug #20550 (project make):
Did you try to patch the current CVS? Because I'm not even sure it compiles
on Windows (never tried it myself), and the place GCC complains doesn't seem
to have anything in common with the patch I sent.
Anyway, can we take this to the mailing
Follow-up Comment #3, bug #20549 (project make):
Your report was relative to Make 3.81, and the diffs are relative to that
version. I don't track the CVS, and am not even sure it compiles on
Windows.
Please, let's continue discussing this on one of the Make mailing lists
([EMAIL PROTECTED],
Follow-up Comment #4, bug #20550 (project make):
Sorry, I meant bug-make, not bug-gnu-emacs, of course.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?20550
___
Message sent
Date: Fri, 3 Aug 2007 14:52:53 -0700 (PDT)
From: [EMAIL PROTECTED]
I am trying to configure GNU make from cygwin and ./configure doesn't run.
I have attached the cygwin console capture with the error.
I see no attachments.
___
Bug-make mailing
Date: Fri, 3 Aug 2007 14:55:15 -0700 (PDT)
From: [EMAIL PROTECTED]
oops, here is the attached console capture
It's much better to send this as plain text (you can capture it with
`tee' or even by copying and pasting the contents into your mailer).
My crystal ball says that somehow the
Date: Sat, 13 Oct 2007 13:59:43 -0400
From: Christopher Faylor [EMAIL PROTECTED]
Cc:
Isn't there a pure MinGW (not msys) version too?
If someone knows where to get it, please tell.
___
Bug-make mailing list
Bug-make@gnu.org
From: Paul Smith [EMAIL PROTECTED]
Date: Sat, 13 Oct 2007 12:37:46 -0400
Cc:
I'm considering switching from CVS to another form of SCM.
Can you tell why?
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
From: Benoit SIGOURE [EMAIL PROTECTED]
Date: Sat, 13 Oct 2007 19:18:42 +0200
Cc: Make Windows [EMAIL PROTECTED], bug-make bug-make@gnu.org
I frequently read Git's ML and it seems rather stable on Cygwin.
Which for me is a turn-off, because I don't want to install Cygwin.
The MSYS version
From: Benoit SIGOURE [EMAIL PROTECTED]
Date: Sat, 13 Oct 2007 20:52:58 +0200
Cc: bug-make bug-make@gnu.org
On Oct 13, 2007, at 7:59 PM, Christopher Faylor wrote:
Isn't there a pure MinGW (not msys) version too?
This sounds unlikely because many commands in git-core are shell
Cc: Make Windows [EMAIL PROTECTED],
bug-make bug-make@gnu.org
From: Benoit SIGOURE [EMAIL PROTECTED]
Date: Sat, 13 Oct 2007 22:09:56 +0200
Is there a good native Windows port of GIT?
http://git.or.cz/gitwiki/WindowsInstall
Thanks, I already found that page. However, it sounds like it
From: Paul Smith [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], bug-make@gnu.org
Date: Sun, 14 Oct 2007 12:57:20 -0400
On Sat, 2007-10-13 at 21:10 +0200, Eli Zaretskii wrote:
Can you tell why?
The main reasons are lack of functionality in CVS re renaming, removing,
and reorganizing files
Date: Mon, 15 Oct 2007 20:12:37 +0100
From: Jon Grant [EMAIL PROTECTED]
Cc: bug-make@gnu.org
Paul Smith wrote on 14/10/07 22:17:
On Sun, 2007-10-14 at 18:33 +0100, Jon Grant wrote:
Do they get free'd up when make exits?
No. It's quite difficult to do this since the variables are
Date: Mon, 15 Oct 2007 13:36:53 -0700
From: Howard Chu [EMAIL PROTECTED]
Cc: bug-make@gnu.org, [EMAIL PROTECTED]
IMO the objections to requiring MSYS/Cygwin on Windows made no sense in this
discussion.
Believe me, it does make sense to some. In a nutshell, if you use
Cygwin or MSYS, you
Date: Sat, 8 Dec 2007 21:18:55 +0100
From: Alberto Santini [EMAIL PROTECTED]
I compiled make 3.81 on Windows box Vista using MingW - gcc (GCC)
4.2.1-sjlj (mingw32-2).
I modified config.h.W32 commenting the line 412:
#define pid_t int
So it would be better to add a conditional
Date: Mon, 10 Dec 2007 17:07:36 -0800
From: Anand, CJ [EMAIL PROTECTED]
The command we use is
make OS=nto CPULIST=x86 -B install LDFLAGS=-M
The error we get is
make: invalid option - B
What does make --version say?
___
Bug-make mailing
Yes, that was silly of me. How about the patch below, then?
I think the solution is using GCC_VERSION. :(
I don't want to use GCC_VERSION, because then I'd need to know exactly
which version started defining pid_t.
2007-12-15 Eli Zaretskii [EMAIL PROTECTED]
* config.h.W32: Include sys
*/
Thanks. Could you please try the patch below, and see if it fixes
your original problem?
2007-12-15 Eli Zaretskii [EMAIL PROTECTED]
* config.h.W32 [!_PID_T_] (pid_t): Define only if not already
defined.
--- config.h.W32~0 2006-04-01 12:42:38.0 +0300
+++ config.h.W32
Date: Sun, 16 Dec 2007 11:08:41 +0100
From: Alberto Santini [EMAIL PROTECTED]
Cc: bug-make@gnu.org
I confirm you the patch works fine.
2007-12-15 Eli Zaretskii [EMAIL PROTECTED]
* config.h.W32: Include sys/types.h.
[!_PID_T_] (pid_t): Define only if not already
.
2007-12-22 Eli Zaretskii [EMAIL PROTECTED]
Suggested by Juan Manuel Guerrero [EMAIL PROTECTED]:
* Makefile.DOS.template (info_TEXINFOS): Remove unused variable.
(TEXINFOS): Value changed to `doc/make.texi'.
(.SUFFIXES): Use .texi instead of .texinfo
From: Giuseppe Scrivano [EMAIL PROTECTED]
Date: Fri, 11 Apr 2008 23:45:02 +0200
Other systems like scons already support this feature and it would be
great to have it for GNU Make too.
I attached a patch against the current CVS to add --use-checksum to
GNU Make, it is just a
Date: Thu, 17 Apr 2008 16:51:47 +0100
From: ying [EMAIL PROTECTED]
Sorry to bother you. When I installed the mingw and msys the current
make version is 3.79.1. I tried to install the make 3.80 and cover the
previous min-make file. Unfortunately no matter what I did the version
is always
Date: Wed, 25 Jun 2008 20:19:39 +0400
From: Vitaly Murashev [EMAIL PROTECTED]
I found a bug in GNU Make 3.81 on MS Windows. So let me discuss it and
suggest a patch.
Thanks. Your code is generally OK, but, unless I'm missing something,
it has a few deficiencies:
. It doesn't add an
Date: Thu, 26 Jun 2008 14:44:38 +0400
From: Vitaly Murashev [EMAIL PROTECTED]
Cc: bug-make@gnu.org
. It doesn't add an explicit drive letter to file names such as
/foo/bar, and generally treats such names incorrectly.
You are right, and i suppose that the best way is to keep
From: Juan Manuel Guerrero [EMAIL PROTECTED]
Date: Mon, 30 Jun 2008 10:12:24 +0200
A couple of months ago I presented a patch to implement DJGPP/MSDOS support
in make again. Now that the legal paperwork has been signed and submitted
I resent an improved patch again. The patch is based on
From: Russo, David [EMAIL PROTECTED]
Date: Mon, 29 Sep 2008 14:21:59 -0500
There seems to be a bug in make 3.81 when make is configured with
BATCH_MODE_ONLY_SHELL enabled. The problem only occurs when
BATCH_MODE_ONLY_SHELL is enabled, make determines the shell is unixy, and a
recipe
Date: Sat, 11 Oct 2008 02:03:27 -0700 (PDT)
From: Uygar UZUNHASAN [EMAIL PROTECTED]
g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_SQL_LIB
-DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED
-I/usr/qt/4/mkspecs/linux-g++ -I. -I/usr/qt/4/include/QtCore
Date: Tue, 14 Oct 2008 11:45:43 +0800
From: =?gb2312?B?Q2Fzc2llIFh1KNDsytjIQSkoQkop?= [EMAIL PROTECTED]
This program built for i686-pc-mingw32
Report bugs to bug-make@gnu.org
make[1]: *** [stfdma.lib] Error 2
make[1]: Leaving directory
Additional Item Attachment, bug #20495 (project make):
File name: w32clospipe.difSize:0 KB
___
Reply to this item at:
http://savannah.gnu.org/bugs/?20495
___
Message sent
Follow-up Comment #2, bug #17277 (project make):
Fixed with the attached patch (which also fixes bug #25662).
(file #17686)
___
Additional Item Attachment:
File name: w32searchpath.dif Size:5 KB
Update of bug #17277 (project make):
Status:None = Fixed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?17277
___
Message
Follow-up Comment #1, bug #25662 (project make):
Fixed with the attached patch (which also fixes bug #17277).
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25662
___
Message
Update of bug #25662 (project make):
Status:None = Fixed
Open/Closed:Open = Closed
Fixed Release:None = CVS
Update of bug #25662 (project make):
Open/Closed: Closed = Open
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25662
___
Message
Additional Item Attachment, bug #25662 (project make):
File name: w32searchpath.dif Size:5 KB
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25662
___
Message sent
Follow-up Comment #1, bug #25412 (project make):
Fixed with the attached patch.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25412
___
Message sent via/by Savannah
Update of bug #25412 (project make):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25412
___
Message
From: Peter Halliday invalid.nore...@gnu.org
Date: Fri, 03 Apr 2009 13:28:36 +
Cc:
I think I have a fix for this issue (at least it's working for me with my
makefiles). I have edited dir.c to limit the maximum number of open
directories under windows to just 1 (normally it is 10) this
1 - 100 of 733 matches
Mail list logo
