win32 compilation of make 4.0 source code
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 the Windows 7 DOS Command Prompt yields a series of warnings/errors: == process_begin: CreateProcess(NULL, uname, ...) failed. make: process_begin: CreateProcess(NULL, uname -a, ...) failed. make: process_begin: CreateProcess(NULL, cygpath C:\zzz_13.12.1_general\tools, ...) failed. make: process_begin: CreateProcess(NULL, pwd, ...) failed. == Is the resulting file supposed to executed under Cygwin ? Aeneas ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: win32 compilation of make 4.0 source code
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 the Windows 7 DOS Command Prompt yields a series of warnings/errors: == process_begin: CreateProcess(NULL, uname, ...) failed. make: process_begin: CreateProcess(NULL, uname -a, ...) failed. make: process_begin: CreateProcess(NULL, cygpath C:\zzz_13.12.1_general\tools, ...) failed. make: process_begin: CreateProcess(NULL, pwd, ...) failed. == Is the resulting file supposed to executed under Cygwin ? I don't know, sorry. But Cygwin distributes their own build of Make; why won't you use that instead? In any case, the released version of Make 4.0 had a few bugs, so you may wish to try building the current development code. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
win32 compilation of make 4.0 source code
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 the Windows 7 DOS Command Prompt yields a series of warnings/errors: == process_begin: CreateProcess(NULL, uname, ...) failed. make: process_begin: CreateProcess(NULL, uname -a, ...) failed. make: process_begin: CreateProcess(NULL, cygpath C:\zzz_13.12.1_general\tools, ...) failed. make: process_begin: CreateProcess(NULL, pwd, ...) failed. = Is the resulting file supposed to executed under Cygwin ? Aeneas ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: win32 compilation of make 4.0 source code
On Mon, 2014-01-13 at 18:21 +0200, Eli Zaretskii wrote: From: Mark Brown mkbrown_...@hotmail.com Date: Mon, 13 Jan 2014 06:04:24 -0800 I was able to compile the make 4.0 source code downloaded from the gnu make site using Visual C++ 2005 under Windows 7 64 (generated 0 errors, 259 warnings) but executing the resulting make command file from the Windows 7 DOS Command Prompt yields a series of warnings/errors: == process_begin: CreateProcess(NULL, uname, ...) failed. make: process_begin: CreateProcess(NULL, uname -a, ...) failed. make: process_begin: CreateProcess(NULL, cygpath C:\zzz_13.12.1_general\tools, ...) failed. make: process_begin: CreateProcess(NULL, pwd, ...) failed. == Is the resulting file supposed to executed under Cygwin ? From what I can see, you're not using Cygwin at all either to build or to run GNU make, so there's no need to consider that. On Windows, GNU make can be compiled in a quite a number of different ways. It would be helpful if you gave us an idea of which method you used. But it doesn't seem like there's any need to worry about Cygwin. In any case, the released version of Make 4.0 had a few bugs, so you may wish to try building the current development code. This is true; I want to get a followup release out sooner rather than later but it will still be a little while yet. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: win32 compilation of make 4.0 source code
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 make site using Visual C++ 2005 under Windows 7 64 (generated 0 errors, 259 warnings) but executing the resulting make command file from the Windows 7 DOS Command Prompt yields a series of warnings/errors: == process_begin: CreateProcess(NULL, uname, ...) failed. make: process_begin: CreateProcess(NULL, uname -a, ...) failed. make: process_begin: CreateProcess(NULL, cygpath C:\zzz_13.12.1_general\tools, ...) failed. make: process_begin: CreateProcess(NULL, pwd, ...) failed. == Is the resulting file supposed to executed under Cygwin ? From what I can see, you're not using Cygwin at all either to build or to run GNU make, so there's no need to consider that. On Windows, GNU make can be compiled in a quite a number of different ways. It would be helpful if you gave us an idea of which method you used. He said that: he used Microsoft Visual C++ version 2005. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: win32 compilation of make 4.0 source code
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 used. He said that: he used Microsoft Visual C++ version 2005. But I meant, how? Through the Visual Studio project files? Or via the build_w32.bat script? Maybe that doesn't matter; I'm definitely no expert on this :-). You are right: it might matter. Sorry for my misunderstanding. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: win32 compilation of make 4.0 source code
On Mon, 2014-01-13 at 19:37 +0200, Eli Zaretskii wrote: On Windows, GNU make can be compiled in a quite a number of different ways. It would be helpful if you gave us an idea of which method you used. He said that: he used Microsoft Visual C++ version 2005. But I meant, how? Through the Visual Studio project files? Or via the build_w32.bat script? Maybe that doesn't matter; I'm definitely no expert on this :-). ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: win32 compilation of make 4.0 source code
Title: Re: win32 compilation of make 4.0 source code Hello, Mark. Monday, January 13, 2014, 17:57:20 you wrote: Is the resulting file supposed to executed under Cygwin ? No. If you build Make natively for Windows, this results in native Windows version. Cygwin is actually quite a different story. Cygwin is not really Windows. Perhaps you heard the word "personalities". Windows NT in the beginning was supposed to have multiple "personalities" (read: APIs) to be compatible (sometimes even on binary level) with different OSes. These personalities included WinAPI (actually old 9x API), OS/2 (binary-compatible) and UNIX (only source-compatible because still relied on PE format, not ELF). With time Microsoft decided to phase our everything except WinAPI. Cygwin is actually modern, opensource version of UNIX personality. When you build a program for Cygwin, you use Cygwin compilers, not Visual Studio or MinGW. Cygwin appears to be a different platform with a different runtime. You cannot compile for Cygwin using Visual Studio (well, in theory you can, given you supply a set of proper includes and libraries), but i don't know about practical attempts to do that. -- , Pavel mailto:pavel_fe...@mail.ru ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
make doesn't complain if target cannot be built
Hint: There's no file present from which foo.o can be built with implicit
rules.
Makefile 1:
--snip---
all: foo.o
--EOF---
# make foo.o
make: *** No rule to make target `foo.o'. Stop.
# echo $?
2
Makefile 2:
--snip---
all: foo.o
foo.o: generated.h
--EOF---
# touch generated.h
# make foo.o
make: Nothing to be done for `foo.o'
# echo $?
0
In Makefile 2 my intention was to state that foo.o depends on some generated
header which must be generated first (might be in another rule). But I didn't
want to change the be behaviour if foo.o cannot be built because e.g. there's
no foo.c.
The example in make's manual, chapter 4.11 Multiple Rules for One Target,
suffers from the identical problem.
Regarding to the make source code, foo.o ..
- has no cmds.
- is not phony
- is a target
remake.c
---snip---
remake_file (struct file *file)
{
if (file-cmds == 0)
{
if (file-phony)
/* Phony target. Pretend it succeeded. */
file-update_status = us_success;
else if (file-is_target)
/* This is a nonexistent target file we cannot make.
Pretend it was successfully remade. */
---
--- foo.o matches this case
---
file-update_status = us_success;
else
{
/* This is a dependency file we cannot remake. Fail. */
if (!rebuilding_makefiles || !file-dontcare)
complain (file);
file-update_status = us_failed;
}
}
else
---snap---
regards
Christian
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: win32 compilation of make 4.0 source code
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 the debug directory. If this is not the intended compilation method, do give step by step method to compile the project under Windows 7 64 , using Visual C++ 2005 . -Original Message- From: Paul Smith Sent: Monday, January 13, 2014 9:44 AM To: Eli Zaretskii Cc: bug-make@gnu.org Subject: Re: win32 compilation of make 4.0 source code On Mon, 2014-01-13 at 19:37 +0200, Eli Zaretskii wrote: On Windows, GNU make can be compiled in a quite a number of different ways. It would be helpful if you gave us an idea of which method you used. He said that: he used Microsoft Visual C++ version 2005. But I meant, how? Through the Visual Studio project files? Or via the build_w32.bat script? Maybe that doesn't matter; I'm definitely no expert on this :-). ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: make doesn't complain if target cannot be built
On Mon, 2014-01-13 at 22:23 +0100, Christian Eggers wrote: In Makefile 2 my intention was to state that foo.o depends on some generated header which must be generated first (might be in another rule). But I didn't want to change the be behaviour if foo.o cannot be built because e.g. there's no foo.c. Unfortunately, this behavior is correct, and even required by the POSIX standard (and is implemented by every version of make). Once a target is listed in the makefile it becomes known to 'make'. When make wants to build a target it will try to find an implicit rule for it. However, if there is no implicit rule found it just means that there were no commands available for that target, not that the target couldn't be built. According to the POSIX spec: If there are no commands listed for the target, the target shall be treated as up-to-date. This is actually useful behavior and is definitely taken advantage of in real makefiles. Cheers! ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Re: win32 compilation of make 4.0 source code
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 the debug directory. Does this binary work if you invoke it from the cmd.exe prompt? But please make sure your Makefile invokes programs that are on Path, and try to avoid invoking Cygwin programs as much as possible. Also, I would suggest to remove Cygwin's sh.exe from Path, as Make on Windows always prefers to use a Unix shell if available. If Make doesn't work even under these circumstances, then something is broken. Otherwise, you could be experiencing some incompatibility between Cygwin and native Windows programs. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: output from $(error) lost with output sync
Oliver Kiddle wrote:
Given the following Makefile, the output from the error function is
being lost when the gmake 4 output-sync is enabled:
[...]
With assertions active I even get this error:
% make -O
make: main.c:3409: die: Assertion `output_context == make_sync'
failed.
Aborted
I tried inserting OUTPUT_UNSET (); in func_error(), case 'e'. This
fixes the above problem, but still fails with fatal() called from
other functions, e.g.:
foo:
echo $(wordlist 0, 0, foo)
So the problem is more general. ISTM the assumption in die() that
output_context is either NULL or make_sync is just not valid, since
fatal() can be called from basically anywhere. So I made this change
which seems to fix the problem.
--- main.c.orig 2014-01-14 05:55:19.0 +0100
+++ make/main.c 2014-01-14 06:14:00.0 +0100
@@ -3406,9 +3406,8 @@
if (output_context)
{
- assert (output_context == make_sync);
+ output_close (output_context);
OUTPUT_UNSET ();
- output_close (make_sync);
}
output_close (NULL);
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: output from $(error) lost with output sync
I fixed this one locally a couple of days ago; sorry for not pushing.
I'll do that shortly.
I don't think this change is sufficient because if output_sync !=
make_sync then make_sync is never dumped with the change below.
On Tue, 2014-01-14 at 06:21 +0100, Frank Heckenbach wrote:
Oliver Kiddle wrote:
Given the following Makefile, the output from the error function is
being lost when the gmake 4 output-sync is enabled:
[...]
With assertions active I even get this error:
% make -O
make: main.c:3409: die: Assertion `output_context == make_sync'
failed.
Aborted
I tried inserting OUTPUT_UNSET (); in func_error(), case 'e'. This
fixes the above problem, but still fails with fatal() called from
other functions, e.g.:
foo:
echo $(wordlist 0, 0, foo)
So the problem is more general. ISTM the assumption in die() that
output_context is either NULL or make_sync is just not valid, since
fatal() can be called from basically anywhere. So I made this change
which seems to fix the problem.
--- main.c.orig 2014-01-14 05:55:19.0 +0100
+++ make/main.c 2014-01-14 06:14:00.0 +0100
@@ -3406,9 +3406,8 @@
if (output_context)
{
- assert (output_context == make_sync);
+ output_close (output_context);
OUTPUT_UNSET ();
- output_close (make_sync);
}
output_close (NULL);
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: make doesn't complain if target cannot be built
Am Montag, 13. Januar 2014, 17:20:43 schrieb Paul Smith: On Mon, 2014-01-13 at 22:23 +0100, Christian Eggers wrote: In Makefile 2 my intention was to state that foo.o depends on some generated header which must be generated first (might be in another rule). But I didn't want to change the be behaviour if foo.o cannot be built because e.g. there's no foo.c. Unfortunately, this behavior is correct, and even required by the POSIX standard (and is implemented by every version of make). Once a target is listed in the makefile it becomes known to 'make'. When make wants to build a target it will try to find an implicit rule for it. However, if there is no implicit rule found it just means that there were no commands available for that target, not that the target couldn't be built. According to the POSIX spec: If there are no commands listed for the target, the target shall be treated as up-to-date. This is actually useful behavior and is definitely taken advantage of in real makefiles. Is there a workaround for this? Using explicit rules seems to be difficult in my case because some objects are built from .c sources, other from .cpp. Is there a better way instead of this: SOURCES_C := foo.c SOURCES_CPP := bar.cpp SOURCES_ASM := ... OBJS := $(SOURCES_C:%.c=%.o) $(SOURCES_CPP:%.cpp=%.o) ... $(SOURCES_C:%.c=%.o): $(COMPILE.c) ... $(SOURCES_CPP:%.cpp=%.o): $(COMPILE.cpp) ... $(OBJS): generated.h EOF regards ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: make doesn't complain if target cannot be built
On Mon, Jan 13, 2014 at 9:56 PM, Christian Eggers cegg...@gmx.de wrote: Is there a workaround for this? Using explicit rules seems to be difficult in my case because some objects are built from .c sources, other from .cpp. Is there a better way instead of this: SOURCES_C := foo.c SOURCES_CPP := bar.cpp SOURCES_ASM := ... OBJS := $(SOURCES_C:%.c=%.o) $(SOURCES_CPP:%.cpp=%.o) ... $(SOURCES_C:%.c=%.o): $(COMPILE.c) ... $(SOURCES_CPP:%.cpp=%.o): $(COMPILE.cpp) ... $(OBJS): generated.h EOF In many cases, I've found it completely unnecessary to list the source files. Just list the objects that should be built and provide pattern rules for the source types, then let make figure out which source files generate which objects from the patterns, ala: OBJS = foo.o bar.o ... %.o: %.c: $(COMPILE.c) %.o: %.cpp $(COMPILE.cpp) ... $(OBJS): generated.h You only need to match sources to objects if there's a naming conflict...which I would tend to solve by renaming the file that doesn't belong. Side point: you only list an explicit dependency for a file named generated.h, which suggests you're using some sort of automated dependency technique (gcc -MD, make depend, etc) for handling dependency tracking for other .h files. If that's the case, then it can be slightly better to use an order-only prerequisite for the generated file, ala: $(OBJS): | generated.h That guarantees the generated.h file will exist before trying to build any objects, but if generated.h gets rebuilt, only the objects that have real dependencies from the automated dependency tracking setup will get rebuilt. Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: win32 compilation of make 4.0 source code
I showed some of the output when this new windows/dos make is run from the command prompt, in the original message. Why not just post a step by step description of how to compile make in Windows 7 64, post some output of its operation, and clear everything up ? Also, can you describe what the series of failed process_begin's indicates ? Are they emanating from inside the make code or from executables invoked by make ? === process_begin: CreateProcess(NULL, uname, ...) failed. make: process_begin: CreateProcess(NULL, uname -a, ...) failed. make: process_begin: CreateProcess(NULL, cygpath C:\zzz_13.12.1_gener make: process_begin: CreateProcess(NULL, pwd, ...) failed. make: process_begin: CreateProcess(NULL, basename , ...) failed. make: process_begin: CreateProcess(NULL, pwd, ...) failed. make: process_begin: CreateProcess(NULL, basename , ...) failed. make: '.' is not recognized as an internal or external command, operable program or batch file. ... = -Original Message- From: Eli Zaretskii Sent: Monday, January 13, 2014 8:51 PM To: Mark Brown Cc: psm...@gnu.org ; bug-make@gnu.org Subject: Re: Re: win32 compilation of make 4.0 source code 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 the debug directory. Does this binary work if you invoke it from the cmd.exe prompt? But please make sure your Makefile invokes programs that are on Path, and try to avoid invoking Cygwin programs as much as possible. Also, I would suggest to remove Cygwin's sh.exe from Path, as Make on Windows always prefers to use a Unix shell if available. If Make doesn't work even under these circumstances, then something is broken. Otherwise, you could be experiencing some incompatibility between Cygwin and native Windows programs. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Missing po files in GIT
Hello! I am trying to rebuild GIT version of Make, however .po files are missing in the repository. Is this intentional ? I have copied them over from my 4.0-2 archive. But where are they originally stored ? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
[PATCH] Fix output-sync option on EMX
Hello! 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). Tested together with the rest of spawn-patch under Cygwin, works fine. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia make-fix-output-sync-emx.diff Description: Binary data ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: output from $(error) lost with output sync
Paul Smith wrote: I fixed this one locally a couple of days ago; sorry for not pushing. I'll do that shortly. I don't think this change is sufficient because if output_sync != make_sync then make_sync is never dumped with the change below. I had assumed it wasn't a problem because make_sync is dumped in main.c before recipes are evaluated, but it certainly can't hurt to dump it as well. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
RE: win32 compilation of make 4.0 source code
=== process_begin: CreateProcess(NULL, uname, ...) failed. make: process_begin: CreateProcess(NULL, uname -a, ...) failed. make: process_begin: CreateProcess(NULL, cygpath C:\zzz_13.12.1_gener make: process_begin: CreateProcess(NULL, pwd, ...) failed. make: process_begin: CreateProcess(NULL, basename , ...) failed. make: process_begin: CreateProcess(NULL, pwd, ...) failed. make: process_begin: CreateProcess(NULL, basename , ...) failed. make: '.' is not recognized as an internal or external command, operable program or batch file. ... = I have looked at the output carefully... 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 Makefile, you need Cygwin or MinGW32 environment. Native Windows version of Make executes commands via cmd.exe, which of course does not understand commonly used UNIX stuff. Well, some commands are emulated by Make itself in such a case, but only a very small number. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
