Re: 3.82 to 3.81
On Thu, 2011-12-01 at 18:55 +0530, Sijith James Philip wrote: For project specific need i want to change makefile version 3.82 to 3.81. Is it possible to do that. The source code for most previous versions of GNU make is available for download: http://ftp.gnu.org/gnu/make/ Choose the one you want, build it, and use it. Cheers! -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Make 3.81 and 3.82 break on parallel build
On Wed, 2011-11-16 at 12:32 -0600, david.hag...@gmail.com wrote: I have a make file that includes a set of machine generated dependency files. Those files describe a set of shared libraries to be build, of the form: somedir/libfoo.so: somedir/libbar.so somedir/libbaz.so Note that libfoo.so has explicitly stated it depends upon somedir/libbar.so. libbar.so has a similar dependency file that describes its needs: somedir/libbar.so: somedir/libbaz.so otherdir/bar.o However, if I run a parallel make: make -j4 mytarget then make will happly start building everything, and will try to link somedir/libfoo.so before even STARTING on linking somedir/libbar.so. Although this could be a bug, it's more likely, IMO, that your target/prerequisite requirements are not correctly stated. For example, it could be that you use slightly different paths so that make doesn't realize these two libraries are really the same thing, and the dependencies aren't being propagated properly. Try running make with the -p option so it prints its internal database. Are the prerequisites you expect to see for somedir/libfoo.so really there? Try running the parallel version with -d (redirect the output because it's voluminous) and see what make says about trying to build somedir/libfoo.so: what does it say about the somedir/libbar.so prerequisite? ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Make 3.81 and 3.82 break on parallel build
On Wed, 2011-11-16 at 15:40 -0600, david.hag...@gmail.com wrote: Try running the parallel version with -d (redirect the output because it's voluminous) and see what make says about trying to build somedir/libfoo.so: what does it say about the somedir/libbar.so prerequisite? That it does not exist, so it fails. But if run not-parallel, it correctly identifies it must be built first. ?? You mean _make_ says the file doesn't exist and so make fails? Or the linker says it doesn't exist and the linker fails? Originally you said it will try to link somedir/libfoo.so before even STARTING on linking somedir/libbar.so. I took this to mean make actually invoked the linker to build somedir/libfoo.so and the linker failed, not that make failed to find the prerequisite. It doesn't matter what the linker says, the question is what make says in the -d output about the somedir/libfoo.so and somedir/libbar.so libraries before it tries to invoke the linker. I can't reproduce this failure (with an attempt to reproduce the environment you described) and parallel builds definitely work. So there must be something more going on here that is related to your specific situation and we probably won't be able to help much without a runnable example with real makefiles, etc. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Make 3.81 and 3.82 break on parallel build
On Wed, 2011-11-16 at 17:35 -0600, David Hagood wrote: On Wed, 2011-11-16 at 17:02 -0500, Paul Smith wrote: On Wed, 2011-11-16 at 15:40 -0600, david.hag...@gmail.com wrote: Try running the parallel version with -d (redirect the output because it's voluminous) and see what make says about trying to build somedir/libfoo.so: what does it say about the somedir/libbar.so prerequisite? That it does not exist, so it fails. But if run not-parallel, it correctly identifies it must be built first. ?? You mean _make_ says the file doesn't exist and so make fails? Or the linker says it doesn't exist and the linker fails? The linker is run, and fails. However, the -d -p output says that Make is fully aware the prereq does not exist, but for some reason decides that doesn't matter. The output ALSO clearly shows that make knows the prereq must BE made. It's like the scheduling of what rules to run next gets out sync. Hm. Strange. The only time I've seen anything like that happen is due to unexpected interactions between make's rebuild included makefiles operation failing and normal builds. You can try getting the latest version of GNU make out of CVS and building it (you'll need autotools and other stuff installed: see the README.cvs file once you get a copy) to see if that works any better. Other than that, I don't think I can help much more without a reproducible test case. In particular I wonder how you've configured your auto-generated prerequisites to work. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Fri, 2011-11-11 at 22:42 +0100, Sebastian Pipping wrote: the copyright assignment form reached the FSF more than a week ago. Would be great to get some more review on my patch now. I don't mind if on-list, off-list, half-half... Hi Sebastian. I got notified by the FSF that your disclaimer has been received. Thanks for your contribution! I'll look at your code today. I have to say that I feel that David's point of 20 Oct is well-taken, that a more flexible command line interface would be better. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [PATCH] High resolution file timestamp support for Mac OSX
On Wed, 2011-10-12 at 19:32 +, Troy Runkel wrote: The GNU make configure script currently doesn’t enable high resolution file timestamp support for the Mac OSX platform. However, nanosecond file timestamps are available, they’re just stored in a different location in the ‘struct stat’ structure used by the stat() API call I applied this patch (note I don't store configure in CVS so you don't need to modify it (or send patches to it). Thanks! -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: fix for make gaining jobserver tokens
On Tue, 2011-10-25 at 13:34 -0700, Tim Newsome wrote: We do a lot of builds (as in double-digit servers building non-stop). Sometimes, when a part of the build fails, make -j8 would die with: make: INTERNAL: Exiting with 9 jobserver tokens available; should be 8 With -j16 the error would be 17 instead of 16, etc. I think it's simply an off-by-one error in cleanup code that is almost never run. Attached is a patch that fixes it. We've been running with it for over 5 days now and haven't noticed any problems. I applied a change to fix this. I tried for a while but couldn't generate a repro case. Bummer. Thanks! -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
On Thu, 2011-11-10 at 14:51 -0500, tz wrote: On Nov 10, 2011 2:32 PM, Paul Smith psm...@gnu.org wrote: On Thu, 2011-11-10 at 10:36 -0500, tz wrote: You don't need to cross-compile: you can compile natively. What you can't do is rely on your upstream vendor to provide you the toolchain you are going to use. You need to build it yourself, using known versions, and install the results in a separate location (not your distro's /usr/bin). That doesn't work if you don't have space on the embedded device. Some don't have resources to network mount, and builds take days (literally). ??? So OK, you ARE using a cross-compiler. I thought you said earlier that you didn't want to. Anyway it doesn't matter whether you're building natively or cross; what matters is that you use an archived, known version of your toolchain to build your target code and not whatever version of the toolchain is delivered with your desktop du jour. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #33034] Makefile:23: *** mixed implicit and normal rules. Stop. for Linux kernel out of source builds
On Thu, 2011-11-10 at 10:36 -0500, tz wrote: Unfortunately, in the embedded world, not everything is updated constantly. Even the desktop is not updated weekly. ARM is still at Fedora 12, though 16 was just released. I don't and won't have an updated kernel tree that works unless I find some way to recompile everything, and the huge, complex, slow, and obscure autotools are often broken for cross compiling much beyond GCC itself and associated tools. I doubt the entire tree in the FSF repository can be properly cross-compiled. I've done embedded development work for many years; in fact much of my work even today involves embedded targets. I understand the issues involved with being forced to work with old software, cross-compiled software, minimally supported targets, etc. However no argument I've seen so far has convinced me that this backward-compatibility mode is necessary. Using whatever native toolchain you have installed on whatever distribution you happen to be using this week to build your target platform is just asking for pain everlasting. No sane and reliable environment can work like this. Today you're having an issue with make, but tomorrow it will be a change in GCC, or binutils, or whatever... then what? Will you be asking GCC to add a special flag to switch back to old behavior just to support older Linux kernels? Not going to happen. Why is this different? In every environment I work on I always have a completely separate toolchain, including the compiler, binutils, flex, yacc, gdb, even things like fakeroot, to build my software... and make is unquestionably part of the toolchain. And of course, even if we were to make this change and release a new GNU make today you would STILL have this problem in any existing environments... you'd need to deploy a custom version of make and use that instead anyway. I just cannot see a single significant advantage to this... I'm still open to hearing one though. I doubt the entire tree in the FSF repository can be properly cross-compiled. Debian has taken to arrays of the various processors so they can go native. You don't need to cross-compile: you can compile natively. What you can't do is rely on your upstream vendor to provide you the toolchain you are going to use. You need to build it yourself, using known versions, and install the results in a separate location (not your distro's /usr/bin). I wasn't asking to change all the error messages or for flags for every version of GNU make, but only this one. Yes, that's what everyone says... about their particular issue. The reality is that the change needed in the Linux makefiles to avoid this problem is so trivial we could have created patches for every prior version of the kernel you need in less time than it's taken us to have this conversation. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: wildcard function returns nothing when filename contains '_' or '[' characters
On Sun, 2011-10-23 at 19:21 +0200, earlgrey wrote: __modules := $(sort $(shell grep -h '\.ko' /dev/null $(wildcard $(MODVERDIR)/*.mod))) with MODVERDIR=fglrx-11.06[Driver 8.861] There's no problem with underscores. The problem with [] is that these are special to the shell's globbing capability, just like * is a special character. Ditto for the whitespace. Run man 7 glob for details. If you try this from the shell: echo fglrx-11.06[Driver 8.861]/*.mod you will not get back what you want either. You have to escape special characters: MODVERDIR = fglrx-11.06\[Driver\ 8.861\] then it will work. I should point out that (a) GNU make doesn't support spaces in targets in general, so the whitespace will continue to be a problem for you going forward, and (b) if you insist on using shell-special characters like [] in your filenames you'll have to be very careful about how you write your shell commands in recipes, to quote all the filenames that might contain these characters. My advice: don't use these kinds of pathnames. You can make it work but the ongoing effort will be significant. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Thu, 2011-10-20 at 05:56 +0200, Sebastian Pipping wrote: On 10/11/2011 10:11 PM, Sebastian Pipping wrote: Alright. Please initiate the copyright assignment process. Any news on this? So there are no preperations to do? The paperwork generally requires you to list the files that you made changes to, and it's helpful to know the scope of the changes. As long as you're still in the early development stage it's not easy to do this. However it can take a bit to complete esp. if you reside outside the U.S. (inside the U.S. we can now use scanned documents via email but outside the U.S. we still must rely on physical mail). I'll send you some options and you can choose which you prefer. Could you add a bootstrap/autogen.sh script to CVS? Any advice or progress here? Any more information you need from me? Check the README.cvs file, for now: make-cvs$ tail -17 README.cvs This list is eminently suitable for a quick swipe o' the mouse and a swift click o' mouse-2 into an xterm. Go for it! autoreconf -i ./configure make update make make check Or, for a debugging version: autoreconf -i ./configure CFLAGS=-g make update make make check Or, all-in-one: autoreconf -i ./configure make update make make check -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: German message error Konnte nicht geöffnet werden printed to stdout instead of stderr
On Tue, 2011-10-18 at 09:05 +0200, Alexander Kriegisch wrote: Some more information: I found the relevant string in /usr/share/locale-langpack/de/LC_MESSAGES/make.mo which is part of Debian package language-pack-de-base, currently installed on my Ubuntu Oneiric in version 1:11.10+20111006. I have no idea if I should address you or the mentioned package maintainer (Language pack maintainers language-pa...@ubuntu.com). At least I could pinpoint the problem which might also exist for other strings and other languages. Translations for GNU software is not handled through Ubuntu. Please see the Translation Project (long, long precedes even the idea of Ubuntu much less the reality :-)) and file a report with the appropriate language translation team; the GNU make page is here: http://translationproject.org/domain/make.html I pick up the latest translations automatically every time I make a release. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: German message error Konnte nicht geöffnet werden printed to stdout instead of stderr
On Mon, 2011-10-17 at 12:58 +0200, Alexander Kriegisch wrote: I am using GNU make 3.81 on Ubuntu oneiric (11.10). I noticed that the German error message Konnte nicht geöffnet werden. is sometimes listed in my output, even if I redirect stderr to /dev/null. So obviously it goes to stdout. This happens for LC_ALL=de_DE@euro, but not for LC_ALL=C. So maybe it is a language-specific bug or the English message equals or something. Please check and fix this problem. I would be happy if you would answer to this inquiry CC to my e-mail address because I am not subscribed to this list. Thanks. Hi Alexander. Google translate shows me that this message means Could not be opened. I'm not sure what would show a message like that in GNU make. My suspicion, personally, is that this message is not coming from GNU make at all but rather it's being printed by a program that GNU make is invoking. I would need to see the context including the full text of the error message to know for sure. In any event, GNU make's i18n/l10n implementation never, ever changes anything like whether messages are printed to stdout or stderr based on any of the LC_* values. The only differences in behavior based on these settings are in the output that is printed. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
RE: suggestion: new make function
On Tue, 2011-10-11 at 11:03 -0700, Lawrence Ibarria wrote: -Original Message- From: bug-make-bounces+libarria=nvidia@gnu.org [mailto:bug-make- bounces+libarria=nvidia@gnu.org] On Behalf Of David Boyce Sent: Sunday, September 25, 2011 2:17 PM To: Tim Murphy Cc: bug-make@gnu.org; make-...@gnu.org Subject: Re: suggestion: new make function I agree with Tim and with Tim's suggested API, in particular withfile. Involving the shell in something as basic and inherently portable as writing to a file opens up a world of portability issues, in addition to the performance and readability problems mentioned. Given that some platforms (Windows) have ARG_MAX limits and have adopted command files as the official workaround, a command line generator (which is fundamentally all make does) should have the native capability to create those kinds of command lines. IMHO. My main reason for being reticent about this particular issue is it would be nice to include some kind of @-operator capability in GNU make which would mean you wouldn't need to write files directly yourself for the purposes of splitting very long command lines. However, I am not adverse to adding a new function to write to a file. I'm not super-jazzed about the 3-argument withfile proposal though: I don't like using C fopen() option strings in a make interface. Also I think reading from a file is something that needs a lot more thought; probably best to split that into a separate proposal. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Mon, 2011-10-10 at 23:59 +0200, Sebastian Pipping wrote: On 10/03/2011 06:22 PM, Sebastian Pipping wrote: To re-summarize: - make does not color its output itself as of now - colorized output would help distincing output by make from output by programs involked by make, example at [1] - existing wrappers (like colormake [2]) have problems - There is a quickhack patch against make 3.82 at [3] - I am willing to keep working on that patch until you like it enough to apply it upstream - I don't know about your expectations on such a patch yet, but I need to know. Please get back to me on this. Thanks! Another week has passed by. Paul, can I have your opinion on this? I have no problem with the concept of colorized output, as long as it meets the following requirements: * The default is no color mode as now * The implementation is clean and portable and doesn't add lots of complexity to the code. Does everything support the color codes you're using? I don't want to have to link with ncurses or something to get portable colorization. * The color designation is flexible: the last thing I want to do is get into a situation where we are scrambling to find acceptable colors for those who prefer terminals with light backgrounds, dark backgrounds, color blind folks, etc. I also don't want to have a new ~/.makerc file or something just to define color schemes. * Based on the above it seems like the code required to implement this will be sufficiently large that it will require copyright assignment to the FSF. * Patches based on the current CVS latest version of GNU make are easier for me to examine/apply/test. Cheers! -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [rfc] Colorized output for GNU make?
On Wed, 2011-10-12 at 00:05 +0200, Eli Zaretskii wrote: Date: Tue, 11 Oct 2011 22:11:23 +0200 From: Sebastian Pipping sebast...@pipping.org * The implementation is clean and portable and doesn't add lots of complexity to the code. Does everything support the color codes you're using? I don't want to have to link with ncurses or something to get portable colorization. No plans on using ncurses here. I suppose if we do what grep does were safe enough portability-wise? I'll check what I can learn from there. Please don't assume that writing some special character sequences to stdout is all that's needed. This is so on Posix platforms, but not Windows or DOS. To be truly portable, there should be an API that accepts a string and the information how to color it, and then a platform-specific backend actually produces the colored output and writes it to the screen. Right. It's OK to look at how GNU grep does it, but GNU make is actually far more portable than GNU grep, which is really a POSIX tool and more tightly tied to POSIX systems. GNU make, in addition to POSIX systems, also runs on Windows, DOS, Amiga/OS, even OpenVMS. Plus not all POSIX systems use the same colorization models; really colorization depends on the terminal type not the OS (at least for POSIX systems). vtxxx, pcansi, and xterm terminals may use very different colorization codes than some other terminal type. Anyway, it's not necessarily the case that a feature implemented only on a subset of supported platforms will be rejected. But, it needs to be implemented in such a way that it doesn't break on unsupported platforms and that it's easy and clean to extend to work on other platforms if someone wants to do so. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Online manual: wrong define in eval section
On Sat, 2011-10-08 at 17:34 +0200, Georg Sauthoff wrote: Hi, currently the online manual section on eval http://www.gnu.org/software/make/manual/make.html#Eval-Function contains an example with folowing line: define PROGRAM_template = In comparison to that my local info page (make 3.81, Ubuntu 11.04) says: define PROGRAM_template And indeed the syntax of a multi line variable definition does not allow a trailing ' =' and thus if you use the first line make can't find the PROGRAM_template variable. You can verify this using 'make --warn-undefined'. I don't know if the online version of the manual is outdated - but please fix it such that it contains the right syntax, since this example describes a rather complicated part of makefile techniques (- eval templates). It's not the manual that's outdated, it's your version of GNU make. The online manual always defines the latest version of GNU make, which is currently GNU make 3.82. You're using GNU make 3.81, which is not the latest, so your version of GNU make doesn't match the manual. You can tell this by looking right at the beginning of the manual where it says: This is Edition 0.71, last updated 19 July 2010, of The GNU Make Manual, for GNU make version 3.82. If you want accurate documentation then use the version that comes with the version of GNU make you have installed. Cheers! -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Online manual: wrong define in eval section
On Sat, 2011-10-08 at 18:04 +0200, Georg Sauthoff wrote: It's not the manual that's outdated, it's your version of GNU make. oh, you are right. Somehow did not expect such a change in syntax at this age of GNU make or between minor version numbers. There is always new syntax in every release. As for version numbers, GNU make's versioning just goes up by one minor number each release. We've never bumped the major number even for significant new features. It would take a truly earth-shattering change to send us to 4.0 at this point (or alternatively, maybe we get to 3.99 and don't want to go to 3.100 :-)). The oldest version of GNU make I have documentation for was already 3.03, and that was released back in August of 1988. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
RE: make 3.82 performing more stat() calls than 3.81
On Fri, 2011-09-16 at 19:18 +, Troy Runkel wrote: FYI, I believe I've located the fix in the GNU make CVS repository that resolves the excessive stat() call problem. I've back-ported the fix into 3.82 and it appears to be working in our build system. The patch for 'read.c' is attached if anybody is interested. Thanks. You might consider going to the Debian packages site and downloading the source package for the Debian version of GNU make. They are pretty good about backporting fixes and I know for a fact that this fix, for example, is included in the Debian version. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: make 3.82 performing more stat() calls than 3.81
On Tue, 2011-09-13 at 21:06 +, Troy Runkel wrote: During our investigation we found that make 3.82 performs more stat() calls than 3.81. Hi Troy. I've verified that this issue exists in 3.82 but it's already been fixed in CVS and the fix will be available in the next release of GNU make. Thanks! -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Problems installing gmake
On Thu, 2011-09-08 at 15:54 -0500, Dennis Sonifer wrote: I have an HPUX 11.23 PA-RISC machine. Downloaded the make file from your site, make-3.82.tar.gz. I am hoping there is just a setting or two away from perfection but I am generally unfamiliar with installing packages. Looks like there is something wrong with your system's configuration. Maybe your C compiler is misconfigured, or you're missing packages you need to install in order to compile code on this system. I don't have access to a system like this, so I can't debug it myself; you'll need to look at the config.log file and find the spot where it's trying to look for those headers, and see what the actual error is (note that you will find LOTS of errors in that log; that's the point of autoconf, to try different things until it figures out what works and what doesn't--you have to keep looking until you find the errors related to that particular failure, for example looking for locale.h etc.) Those error messages should help us determine what's wrong on your system. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: different behavior on 3.82, 3.81, 3.80-and-older
On Tue, 2011-09-06 at 16:31 -0500, Brandon Casey wrote: all:: SHELL_PATH = /bin/sh SHELL = $(SHELL_PATH) some_file: shell_compatibility_test FORCE @echo making some_file @$(SHELL) true Are you sure you don't mean $(SHELL) -c true here? The above will never succeed unless true is a shell script. -include some_file all:: shell_compatibility_test @echo building all please_set_SHELL_PATH_to_a_more_modern_shell: @echo testing shell $(SHELL) @$$(:) shell_compatibility_test: please_set_SHELL_PATH_to_a_more_modern_shell .PHONY: all .PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell .PHONY: FORCE That is an... interesting... approach. With make 3.81, make prints: make: Nothing to be done for `all'. Since all is a PHONY target, its commands should always be executed right? Perhaps make is remembering the previous failure of shell_compatibility_test and ignoring the second all:: target? It's because you're using -include some_file, and some_file depends on shell_compatibility_test, and shell_compatibility_test depends on please_set_SHELL_PATH_to_a_more_modern_shell. Since the some_file target does not exist, make attempts to rebuild it so that it can be included; once the target is rebuilt then make will re-exec itself and read that file in, then continue on. But, your commands fail and so the build of those target fails. But, since you're running under -include, where the - is telling make that when it tries to build the included makefile, it should ignore failures, no error is reported. So make does ignore the failure and doesn't print anything. Now make sees that none of the included makefiles were modified, so it does NOT re-exec itself and just continues on. However make already knows it can't build those targets and so the next time you try to use that target make won't try to build it. There's a good argument to be made that when make comes across a target which it tried and failed to build during the makefile rebuild phase, it should realize that the target failed the first time and treat it as a failure this time as well. It looks like your makefile was depending on the behavior of some cobwebby corners of the GNU make feature set, and those corners have since been dusted. On make 3.82, it prints: make: *** No rule to make target `please_set_SHELL_PATH_to_a_more_modern_shell', needed by `shell_compatibility_test'. Stop. ?? The rule exists, but somehow marked as missing because of a prevous failure via the some_file target? I don't get this message so I don't know why you're seeing that. If I remove the dependency on shell_compatibility_test from the some_file target Now you've broken the link, so that make doesn't try to build shell_compatibility_test during the first phase (when it's trying to rebuild the makefiles). So then when it tries to run that target during the normal builds, it will not have been run yet, and will fail. However, I suspect that this change will defeat the original intent of this bit of code. Without any docs as to why things were done this way I can't be sure but my suspicion is that it's trying to force the build to fail immediately in the case of a bad shell, regardless of which target was invoked. But I could be wrong. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [PATCH] Options: `--dry-run' should prevent `--touch' from touching
On Fri, 2011-09-02 at 01:58 +, Michael Witten wrote: Hello? I do prefer bugs files in Savannah to things sent on the mailing list, just because they're easier to keep track of. I applied this patch. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: gnubatch-1.3
On Mon, 2011-08-29 at 17:02 -0300, Marcos Hocpfner wrote: hello, I need know, whit that version the GCC compiler the same, I am intall on a Solaris 10 sparc This list is for people who need help using the GNU make program. You need to ask your question on a list dedicated to either the GCC compiler, or to Solaris. Good luck! -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Automatic variable $ doesnt increment to the next source file while compiling
On Tue, 2011-07-19 at 15:22 +0530, Rahul wrote: I am using make (version 3.81) for compilation. However the automatic variable $ doesnt increment as expected and uses the 1st source file itself for compiling all the objects. There's not much help we can give based on this description. Please provide a sample of what you're doing (the smallest makefile syntax that reproduces the problem) and show what output you're getting and what output you expected. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
RE: $(sort) - what is lexical order? (was RE: Follow-up)
There is no standard definition of lexical order that I'm aware of that means only, and exactly, sorted according to the current locale collation definition. The free dictionary defines it as: the arrangement of a set of items in accordance with a recursive algorithm, such as the entries in a dictionary whose order depends on their first letter unless these are the same in which case it is the second which decides, and so on Which seems reasonable to me. GNU make uses the standard C runtime function qsort(3) to perform its sorting, with a comparison function of the standard C runtime function strcmp(). The strcmp() function is defined by both the ISO C and POSIX standards to perform byte-wise comparisons; that is, it uses ASCII sorting order (on systems where the characters are stored as ASCII chars, which is just about all of them these days). The builtin sort function DOES sort. It may not sort the way you would prefer, but it sorts in a standard, repeatable, well-defined way that does not change based on a particular user's environment settings... most creators of build systems consider this reproducibility to be MUCH more important than locale-specific collation, which is just visual flourish. I agree that the manual should document the fact that the sort function does not sort according the current LC_COLLATE value but instead always uses the standard ASCII (or LC_COLLATE=C) order. But I will not say that it doesn't sort lexically, because that's not true: it does. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: $(sort) - what is lexical order? (was RE: Follow-up)
Please don't reply only to me: discussions belong on the mailing lists. On Tue, 2011-07-19 at 15:32 -0400, Rob Holbert wrote: The key in that definition is depends on their first letter, not the capitalization of their first letter. But in any event, if you don't have a clear definition for Lexical, then that's probably a big clue it should not be in the manual. Otherwise, the definition would have to mention case. So, using a sort function to provide an unsorted list does not sound reasonable to me. Especially when the UNIX command line does it right, which is quite odd because I thought the kernal was built with make and gcc. Hmmm. Well, maybe somebody ought to get coherent on what it does mean instead of reiterating the obvious. I think there's some misunderstanding of how things really work shown by this paragraph. When I use sort on MY command line, it sorts the same way that GNU make does: ~$ (echo aardvark; echo Zebra) | sort Zebra aardvark This is exactly what I'd expect from my UNIX command line tools, because I've configured my environment to use the built-in sorting order (which was the only sorting order for much of the history of UNIX), ASCII. You've configured your environment to use a different sorting order, which is fine. The ability to show directory listings, etc. using the user's personal sorting order preferences is a great enhancement from when UNIX was originally created. But it's not at all obvious that having a tool like make follow the user's wishes here is the right thing to do. I would not really expect to find Zebra before a bear in an index? The only use for a sorted list is to quickly identify the presence or absence of an item by quickly scanning the list. (i.e. Damn why is lcd.o not present in the build?) . If not for this, what useful purpose does the broken sort serve? If you understand the sorting order used by make, it's no more or less difficult to determine whether a file is missing than any other sort order. You simply have to look with the other lowercase filenames and see if it's there. The sort is not broken. It's not random; that would be silly. It's just not what you're used to. Consider another scenario: make uses your sorting preferences, and you run a build and it fails. You send the log to me and I'm looking at it, but I use different sorting preferences. Now I'm confused by your log because the sorting order is different and I can't find things. Or, your build fails because of a subtlety related to the sorting order, but I can't help you as things work fine for me because I use a different order. Having a completely deterministic sorting order is a good thing, for a build system. Any ordering which is modified by the user's environment is by definition not deterministic. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: PostgreSQL 9.0.4 failure.
On Tue, 2011-06-14 at 22:01 -0500, Perry Smith wrote: I opened a bug report with PostgreSQL but I believe it is a problem with make. The bug report there is 6059: http://archives.postgresql.org/pgsql-bugs/2011-06/msg00109.php You can also read a post here: https://groups.google.com/d/topic/pgsql.general/iOnCH9VuwnE/discussion It definitely looks like a change in behavior of GNU make triggered this issue. However, until/unless someone provides us with the text of the makefile rule that is failing we can't know whether this is a bug or something that was changed intentionally. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: make 3.82 bug with leading space on member names in library prerequisite.
On Wed, 2011-06-08 at 14:13 +0100, Duncan Moore wrote: Using this makefile: .PHONY: all all: lib.a( a.o) (%.o): %.o @echo $@ $ make 3.81 gives what I would expect: lib.a a.o make 3.82, with the corrections for bug #30612, gives: make: *** No rule to make target `lib.a()', needed by `all'. Stop. https://savannah.gnu.org/bugs/?30612 Cheers! ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Implicit pattern rules do not match files with spaces in their names [resend]
On Tue, 2011-06-07 at 16:35 -0400, Anthony DeRobertis wrote: This is with GNU Make 3.81. I originally posted this as a question on Stack Overflow, http://stackoverflow.com/questions/6233574/ According to the docs (10.5.1), % in a pattern rule matches any nonempty substring. But it seems to actually match some subset of that, in particular, ones that does not contain spaces. GNU make does not support files containing whitespace (in fact no POSIX make does: make defines whitespace to be a separator and does not define any way to escape whitespace). Some things work, by accident; many do not. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: private with target-specific variables
On Wed, 2011-05-18 at 15:02 +0200, Mario Schwalbe wrote: $ LC_ALL=C make -f Makefile.private-bug prereq: make: *** No rule to make target `private', needed by `target'. Stop. $ LC_ALL=C make -v GNU Make 3.81 The private feature was added in GNU make 3.82. It's not available in GNU make 3.81. If you use make -p you'll see that your makefile is not being interpreted at all as you expect. This line: private GLOBAL = global is creating a variable named private GLOBAL, which is why your echo of $(GLOBAL) shows nothing; you never set the variable $(GLOBAL). Similarly, this line: target: private LOCAL = local is not declaring a target-specific variable at all: it declares a target target with four prerequisites: private, LOCAL, =, and local. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: make multiple target patterns: make doesn't tell what these patterns are
On Tue, 2011-05-17 at 09:23 +0200, Folkert van Heusden wrote: When there's something going wrong in the makefile causing a make multiple target patterns, make doesn't tell you what these multiple targets are. That is inconvenient when working with e.g. scriptfiles that select targets. Also -d doesn't give this output. I grepped the entire GNU make source code for the message make multiple target patterns and didn't find it. Can you be more specific about the problem? A small simple makefile that illustrates it, along with the command you invoked, the output you got (all cut/pasted please) and why you feel this output is wrong or insufficient would be best. Cheers! -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Possible problem / misunderstanding in make manual
On Thu, 2011-05-12 at 10:10 +0200, Julien Palard wrote: I have hard time to understand a part of the make manual, the problem can be a typo of a subject not clearly expressed, here is the point : In the page about multiline variables : http://www.gnu.org/s/hello/manual/make/Multi_002dLine.html A statement say that : You may omit the variable assignment operator if you prefer. If omitted, make assumes it to be ‘=’ Then on the page about eval : http://www.gnu.org/software/make/manual/html_node/Eval-Function.html#Eval-Function There is an example : define PROGRAM_template = $(1): $$($(1)_OBJS) $$($(1)_LIBS:%=-l%) ALL_OBJS += $$($(1)_OBJS) endef This example works for me only if I remove the '=' sign That's because the online manual describes the latest released version of GNU make (3.82) but your system is using an older version where this feature is not supported. You should use the version of the manual that came with your system, that matches the version of make, or else upgrade your version of make to the latest. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: $(wildcard pattern-without-glob-chars) broken (Re: make ChangeLog read.c)
On Sat, 2011-05-07 at 17:06 +0400, Kirill Smelkov wrote: This change seems to be breaking how $(wildcard) works for patterns without glob characters. Ouch, you're right. Something missed in the regression test suite! I'll fix it. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: $(wildcard pattern-without-glob-chars) broken (Re: make ChangeLog read.c)
On Sat, 2011-05-07 at 10:15 -0400, Paul Smith wrote: On Sat, 2011-05-07 at 17:06 +0400, Kirill Smelkov wrote: This change seems to be breaking how $(wildcard) works for patterns without glob characters. Ouch, you're right. Something missed in the regression test suite! I'll fix it. The code was there to handle this I just had the boolean expression wrong. Fixed now and I added regression tests to make sure it continues to work. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: patch to support output synchronization under -j
On Tue, 2011-05-03 at 09:48 +0200, Stefano Lattarini wrote: The other thing I was thinking is that this feature might want to be enabled via a command-line argument. All the complex makefiles generated by automake, etc. for example cannot take advantage of this if you have to modify every makefile to add the special target. Not completely true. A developer using Automake who wants to take advantage of this feature could just add the line: .PARALLELSYNC: to his Makefile.am file(s). Automake's preprocessing policy is to pass through the things it doesn't understand (or that are not influential to it). Sure, I realize that. But that only helps developers. I was thinking about users of open source software, building it on larger machines with -jN and wanted to get clean output when it fails. That's my situation: I have archived vanilla tarballs downloaded directly from the upstream sites, and I have a makefile that does all that's necessary (unpack them, configure, build, install, etc.) I certainly don't want to have to go modify the Makefile.am / Makefile.in files to get this feature enabled. Also apropos of nothing, I don't like this name :-). Maybe .OUTPUTSYNC or something would be better? PARALLELSYNC doesn't help understand what the feature does. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Make 3.82: weird circular dependency and missing $ expansion
On Tue, 2011-05-03 at 17:39 +0200, Akim Demaille wrote: Le 2 mai 2011 à 16:07, Paul Smith a écrit : Hi Paul! So, the circular dependency issue is because of this: %.eps: %.pdf %.eps %.pdf: %.dat In the second rule you say that BOTH %.eps and %.pdf can be built from %.dat, and in the first rule you say that %.eps can be built from %.pdf. So make has two different ways to build %.eps, and one of them lists as a prerequisite a co-target in the other rule. Make is rightly confused here. I'm confused in understanding why it's rightly confused :/ But maybe my confusion is, as Edward pointed out, because I am misled by the term circular dependency, as really, I can't see any here. Maybe circular is not the best term; as Edward says maybe a better term in this case is ambiguous. However the same code checking is used for circular dependencies so that's the output you get. In order to understand make's dilemma I need to be sure you understand what the %.eps %.pdf: %.dat syntax means; some people think it means the same thing as: %.eps: %.dat command %.pdf: %.dat command But that's not what it means (if these was an explicit rule, instead of a pattern rule, it would mean that). What it means instead is that one invocation of command will create BOTH %.eps and %.pdf. That is, make has no way of building %.pdf, except for a rule that ALSO builds %.eps. So, you ask to build accel.eps. Make finds the first rule, %.eps : %.pdf. Now make wants to know how to build accel.pdf. Looking around make sees that it can be build by the rule %.eps %.pdf: %.dat. This rule works because there is an accel.dat. But wait! When make builds accel.pdf using that pattern rule, it will ALSO build accel.eps... but make already has a different rule to build accel.eps. Now make has two different rules that both will build the same target file, so it gives up with an error. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Make 3.82: weird circular dependency and missing $ expansion
On Tue, 2011-05-03 at 15:03 +0200, Edward Welbourne wrote: It all depends on the order in which make searches the rules, which is why changing things in the makefile matters. If make finds the second rule first then it sees it can build foo.eps and foo.pdf from foo.dat and it's all good. No circularity. Well, it still gets told the same edges in its directed graph, so it's just as cyclic - when you ignore the direction on at least some edges; i.e. it's not a tree - it's just that it's not interested in the %.eps: %.pdf rule by the time it reads it, so it doesn't get confused about it. The fact that this depends on the orer of rules strikes me as highly suspect; it may be by design but I'd read it as saying make isn't really building the full directed graph of dependencies. Absolutely true; it definitely does not (when it comes to pattern rules: the full graph is created for explicit rules of course). Make has a well-defined way to traverse the graph, described in the manual, and as soon as make finds the first acceptable match using that algorithm it will stop searching the graph and build the target. If there are ambiguities or cycles further on, that are never checked because make stops once it finds an acceptable solution, then you will never know it (unless you change the graph to expose them). To test and check every possibility would (a) be very slow, and (b) is not necessary to build, and (c) expressly violates the behavior documented in the manual, that many makefiles rely on to avoid these kinds of issues. Cheers! -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: patch to support output synchronization under -j
On Tue, 2011-05-03 at 13:00 -0400, David Boyce wrote: The other thing I was thinking is that this feature might want to be enabled via a command-line argument. All the complex makefiles generated by automake, etc. for example cannot take advantage of this if you have to modify every makefile to add the special target. Hmm, it feels like you've reversed position since last year? When I submitted the patch for .ONESHELL it included a new --one-shell flag and you rejected the flag part saying you didn't want make to end up like GNU tar in the sense of having an overwhelming number of options. Heh. Consistency is for suckers :-). However, I still feel that .ONESHELL is not something you can always just set on the command line and have things work just as before. Although _sometimes_ that's true, other times recipes are written in a particular way that can cause problems if .ONESHELL was set. And certainly if you write your makefile assuming .ONESHELL then anyone who runs make _without_ setting it will not be happy... the build will absolutely fail. For these reasons I'm less happy about having the user add it via the command line. To me .ONESHELL is a feature that the makefile AUTHOR chooses for her makefile, not (generally) something that the makefile USER would select (although certainly for some well-formed makefiles you can turn it on and off with no difference in behavior). For this SYNC feature, it will not make any difference whatsoever whether the person invoking the command uses it or not. In fact, in a way it's MORE appropriate for the command line, to allow the user to choose whether or not to use it (just like -j itself); it seems like forcing this to always be on by setting a pseudo target is somewhat antisocial; now if people want to avoid this behavior they have to edit the makefiles. In that way, SYNC is a feature that the makefile USER selects, or not, and not something the makefile AUTHOR would choose. Does that make sense? That was when you came up with the --eval option, which I found brilliant BTW. So I guess the first-order answer to your point would be there is a way to enable this at the command line and you invented it: --eval=.PARALLELSYNC:. However, I personally like command-line options and if you want a first-class flag you'll get no argument here. Except, I don't remember if --eval is passed down to sub-makes? The mind goes first... -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Make 3.82: weird circular dependency and missing $ expansion
On Mon, 2011-05-02 at 09:17 +0200, Akim Demaille wrote:
Using the attached Makefile (I spent quite a while to strip it down from an
Automake generated file), Make 3.81 reports:
$ make
echo accel.dat accel.dat
echo {accel.dat}
{accel.dat}
test -n accel.dat
echo accel.pdf accel.eps
Which is what I expect. But Make 3.82 reports:
$ LC_ALL=C gmake -rR
gmake: Circular accel.pdf - accel.pdf dependency dropped.
echo {}
{}
test -n
gmake: *** [accel.pdf] Error 1
I would have understood that something be reported about accel.eps,
but I don't understand what it means about accel.pdf. It would be
really nice to have more details about those circular dependencies.
And see how $ is expanding to nothing.
Weirdly enough, if I comment the document.pdf dependency, which is
not involved in plain make all, it works. If I move it, it works
too. If I compare the --print-db without-document.pdf -
with-document.pdf, I can see that things about accel.pdf differ (and
$ is not defined), but it does not help me understand what's wrong:
So, the circular dependency issue is because of this:
%.eps: %.pdf
%.eps %.pdf: %.dat
In the second rule you say that BOTH %.eps and %.pdf can be built from
%.dat, and in the first rule you say that %.eps can be built from %.pdf.
So make has two different ways to build %.eps, and one of them lists as
a prerequisite a co-target in the other rule. Make is rightly confused
here.
When make wants to build foo.eps it finds the first rule and sees that
it can build foo.eps if it can build foo.pdf, so make looks for a rule
to build foo.pdf and finds that it can build it from foo.dat... but that
rule ALSO builds foo.eps. Now make has two rules that can build foo.eps
and one of them is required to build its own prerequisite. Circular.
It all depends on the order in which make searches the rules, which is
why changing things in the makefile matters. If make finds the second
rule first then it sees it can build foo.eps and foo.pdf from foo.dat
and it's all good. No circularity.
I'm not sure about the details, and I'm not sure about why $ is empty;
that does seem like a bug.
--
---
Paul D. Smith psm...@gnu.org Find some GNU make tips at:
http://www.gnu.org http://make.mad-scientist.net
Please remain calm...I may be mad, but I am a professional. --Mad Scientist
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: patch to support output synchronization under -j
On Fri, 2011-04-15 at 16:57 +0300, Eli Zaretskii wrote: Date: Fri, 15 Apr 2011 12:43:53 +0100 From: Tim Murphy tnmur...@gmail.com I think it's an inevitable consequence that if you have a long-running task then the output from it won't appear until it has completely finished and you won't be able to watch the progress - in this scheme there is no way to show some of the output whilst also ensuring that it is not interspersed with output from other recipes. Well, if that's so, then this feature will be less useful than it could be, at least for me. It reminds me of my DOS days, when running a compilation command from Emacs would show me the output only when the compiler was done. I'm not happy to return to those compiling blind days. Can something be done to alleviate this? When I first read this it seemed to me that (a) there's no good way to solve this, and (b) it's not so important anyway in most builds as compiles are relatively quick. But, I've been playing with a makefile that I have, that builds a complete suite of GCC tools from scratch. I'm building them on larger systems with -j5 or -j10 (not much compared to what some are doing I realize). Sometimes these builds fail and it can be frustrating to see what part of the build is failing. But here's the thing: these makefiles are by their very nature massively recursive. Each top-level rule is an entire build of a major component like gcc, binutils, gdb, bison, etc. As far as I understand it, if I were to enable this feature then all of the output from the entire build of gcc (for example) would be collected into a file and not printed until the entire sub-make had completed. That's not very optimal. Unless I missed something? I wonder if we can figure out a way to make this work better, as Eli asked. Can we work out a way to handle normal rules (rules with + or $(MAKE)) and sub-make rules differently, so that output from normal rules wasn't collected behind a sub-make? I'm not sure I see exactly how this could work. The other thing I was thinking is that this feature might want to be enabled via a command-line argument. All the complex makefiles generated by automake, etc. for example cannot take advantage of this if you have to modify every makefile to add the special target. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: makefile target all: not built automatically
On Tue, 2011-04-26 at 13:31 +0100, Jon Grant wrote: I noticed that the all: target must be at the top of a makefile, unless explicitly built by make all. Is this expected? It seems quite limiting.. There is nothing special about the all target. That's just a convention that many, but not all, makefile authors use. Make itself doesn't treat the all target, if it exists, in any special way. The GNU make manual says: The order of rules is not significant, except for determining the default goal: the target for `make' to consider, if you do not otherwise specify one. The default goal is the target of the first rule in the first makefile. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: Possible minor bug in manual?
On Fri, 2011-04-08 at 13:58 -0300, Federico Sanchez Pinzon wrote: from GNU Make manual: 3.6 (Overriding Part of Another Makefile): However, it is illegal for two makefiles to give different recipes for the same target. Thanks. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: substantial 'glob' speedup ...
On Wed, 2011-04-06 at 12:35 +0100, Michael Meeks wrote:
Anyhow - one problem we are seeing is that as we load and parse the
~50Mb of dependencies that we need (for part of writer) we are statting
the same files involved in dependencies sometimes a thousand times or
so. We do around 700k stats with lots of duplication.
These ~all come from calling 'glob'; I append a patch that tries to
call glob only if needed - it could be done more prettily:
Try this one and see if it works as well.
--
---
Paul D. Smith psm...@gnu.org Find some GNU make tips at:
http://www.gnu.org http://make.mad-scientist.net
Please remain calm...I may be mad, but I am a professional. --Mad Scientist
? gnumake.supp
? log.1
? vg.out
? x.out
? doc/gendocs_template
? doc/manual
Index: read.c
===
RCS file: /sources/make/make/read.c,v
retrieving revision 1.197
diff -u -r1.197 read.c
--- read.c 18 Apr 2011 01:25:20 - 1.197
+++ read.c 18 Apr 2011 01:59:14 -
@@ -2898,6 +2898,7 @@
const char *name;
const char **nlist = 0;
char *tildep = 0;
+ int globme = 1;
#ifndef NO_ARCHIVES
char *arname = 0;
char *memname = 0;
@@ -3106,32 +3107,40 @@
}
#endif /* !NO_ARCHIVES */
- switch (glob (name, GLOB_NOSORT|GLOB_ALTDIRFUNC, NULL, gl))
- {
- case GLOB_NOSPACE:
- fatal (NILF, _(virtual memory exhausted));
-
- case 0:
- /* Success. */
- i = gl.gl_pathc;
- nlist = (const char **)gl.gl_pathv;
- break;
-
-case GLOB_NOMATCH:
- /* If we want only existing items, skip this one. */
- if (flags PARSEFS_EXISTS)
-{
- i = 0;
- break;
-}
- /* FALLTHROUGH */
-
- default:
- /* By default keep this name. */
+ /* glob() is expensive: don't call it unless we need to. */
+ if (!(flags PARSEFS_EXISTS) || strpbrk (name, ?*[) == NULL)
+{
+ globme = 0;
i = 1;
nlist = name;
- break;
- }
+}
+ else
+switch (glob (name, GLOB_NOSORT|GLOB_ALTDIRFUNC, NULL, gl))
+ {
+ case GLOB_NOSPACE:
+fatal (NILF, _(virtual memory exhausted));
+
+ case 0:
+/* Success. */
+i = gl.gl_pathc;
+nlist = (const char **)gl.gl_pathv;
+break;
+
+ case GLOB_NOMATCH:
+/* If we want only existing items, skip this one. */
+if (flags PARSEFS_EXISTS)
+ {
+i = 0;
+break;
+ }
+/* FALLTHROUGH */
+
+ default:
+/* By default keep this name. */
+i = 1;
+nlist = name;
+break;
+ }
/* For each matched element, add it to the list. */
while (i-- 0)
@@ -3171,7 +3180,8 @@
#endif /* !NO_ARCHIVES */
NEWELT (concat (2, prefix, nlist[i]));
- globfree (gl);
+ if (globme)
+globfree (gl);
#ifndef NO_ARCHIVES
if (arname)
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: patch to support output synchronization under -j
On Fri, 2011-04-15 at 07:18 +0100, Tim Murphy wrote: Right, of course :-) That is the obvious reason for using files, thanks! I was biased against writing things to disc which is probably silly, because it's probably not slow when compared to the size of the job that's running. I think you could do the same thing with pipes although you need to spawn a separate process to track each job, most likely. The main reason I prefer solutions using files is that it's the simplest and most portable method. Stdout and stderr will now all be stdout, BTW (no matter what method one uses) but that's not generally such a problem. I don't quite follow that? If you're willing to separate stdout and stderr so that, for example, all stdout output comes first followed by all stderr, then you can still use both. You can just create two files, hook stdout to one and stderr to the other, and after everything is done shuttle the contents of the stdout log file to stdout and the contents of the stderr log file to stderr. The functionality would be the same (as far as what goes to what file descriptor) but they wouldn't be interspersed. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: patch to support output synchronization under -j
On Fri, 2011-04-15 at 19:54 +0300, Eli Zaretskii wrote: What about the other issue: with the fact that output from a recipe is only shown when the entire recipe is done. I think this is a serious drawback, at least in some use cases. Can anything be done about that? I don't see how. The entire point of this feature is that all the output for each job is shown together as one group, rather than intermixed with the output of other jobs. I can't see how you can see the output from all jobs immediately and still keep the output from being mixed together; that seems akin to squaring a circle :-). If you want the output immediately, don't enable this feature. If you want the output to be grouped together, then enable this feature. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: patch to support output synchronization under -j
On Thu, 2011-04-14 at 11:01 -0400, David Boyce wrote: On Tue, Apr 12, 2011 at 1:46 PM, David Boyce david.s.bo...@gmail.com wrote: So I've made a proof-of-concept patch against 3.82.90 which seems to work without that overhead and my question is, would this be of interest towards 3.83? Ping? The original patch attachment was made by hand using diff -u and I had some trouble applying it myself. So here's a version created with cvs -q diff -uN which should work better. I've looked at it and as a concept I don't have too many issues with it (although I'd like to hear from the ports) but I think there some outstanding issues that should be considered. One example: I think saving stdout and stderr to different files and then printing them separately is problematic; consider if your recipe prints lots of information lines, with errors (to stdout) interspersed. If you throw all the errors to the end you lose a lot of context. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: patch to support output synchronization under -j
On Thu, 2011-04-14 at 20:48 +0300, Eli Zaretskii wrote: From: Paul Smith psm...@gnu.org Date: Thu, 14 Apr 2011 13:29:09 -0400 On Thu, 2011-04-14 at 11:01 -0400, David Boyce wrote: On Tue, Apr 12, 2011 at 1:46 PM, David Boyce david.s.bo...@gmail.com wrote: So I've made a proof-of-concept patch against 3.82.90 which seems to work without that overhead and my question is, would this be of interest towards 3.83? Ping? The original patch attachment was made by hand using diff -u and I had some trouble applying it myself. So here's a version created with cvs -q diff -uN which should work better. I've looked at it and as a concept I don't have too many issues with it (although I'd like to hear from the ports) David, can you explain why you needed to lock the files? Also, what region(s) of the file you are locking? fcntl with F_WRLCK won't work on Windows, so the question is how to emulate it. David wants to interlock between ALL instances of make printing output, so that even during recursive makes no matter how many you have running concurrently, only one will print its output at a time. There is no specific region of the file that's locked: the lockfile is basically a file-based, system-wide semaphore. The entire file is locked; it's empty and has no content. I'm not sure I like the idea of having to define a lockfile to enable this feature though. It feels a little too much like exposing the implementation details to the user. Finally, I'd suggest that the system-dependent portions of sync_output be factored out into a separate function, so that the Windows port could have its own implementation without infesting job.c with yet another bunch of #ifdef's. Definitely. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: patch to support output synchronization under -j
On Thu, 2011-04-14 at 20:59 +0100, Tim Murphy wrote: To prevent any kind of deadlock you sort of want to empty everything the stderr and stdout pipe buffers may contain. It is conceivable that the stdout pipe might contain two lines of text and stderr pipe might contain 1 by the time your select statement (or waitformultipleobjects) has woken up. This would all be true, if anyone were using pipes and select statements... but we're not :-) The implementation David provided has all the output going to temporary files, which are then read and printed to stdout or stderr (and deleted) when the job gets the output sync lock. To choose between merged and not merged you just choose between creating distinct files, vs. creating one file and setting both stdout/stderr to write to it... same as it would write to the tty device. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: bug report acknowledgments should be the default!
On Thu, 2011-04-14 at 08:57 +0800, jida...@jidanni.org wrote: PS == Paul Smith p...@mad-scientist.net writes: PS If you want a bug report to be filed and acknowledged, then you want: PS https://savannah.gnu.org/bugs/?func=additemgroup=make Thanks for answering! Well that's not the advertised way to submit bugs. You advertise bug-*@gnu.org. Both the mailing list and Savannah are discussed on the make home page, but you're right, this should be made more clear. It does clearly say that bug-make is a main discussion list, however, and so I wouldn't expect people to think that messages to that list would become bug reports and automatically acknowledged, a la Debian's BTS etc. PS The FSF does not use an email-based bug tracker, like Debian; we use PS Savannah. OK, but Savannah should then be made to send acknowledgments by default. The power users could easily adjust some of their settings to turn them back off. I believe that if you file a bug with Savannah it will send you email both when you file it and whenever it is updated. If something about Savannah isn't working the way you want, you should file a bug against Savannah itself (the Savannah project on Savannah). I don't have any ability to modify or fix the Savannah behavior. Cheers! -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: bug report acknowledgments should be the default!
On Thu, 2011-04-14 at 07:28 +0800, jida...@jidanni.org wrote: I noticed that when submitting bugs to bug-*@gnu.org, unlike other bug submission by mail systems, e.g., Deb bugs of Debian, the user receives no cheery auto reply acknowledging the bug was ever even received and didn't go into a black hole, or expecting the user to dig out what happened to his submission via poking around the website. Let's the advanced user disable notifications like they can in Debian. For the default state, please enable auto acknowledgments of bug mail received, like Debian does. Anybody reading this? Anybody get this? If you want a bug report to be filed and acknowledged, then you want: https://savannah.gnu.org/bugs/?func=additemgroup=make The FSF does not use an email-based bug tracker, like Debian; we use Savannah. This mailing list is for discussion about bugs. Sometimes those discussions result in a fix and sometimes not, but it's not the case that every message to this list is automatically tracked as a bug report. Only Savannah bug reports are officially tracked. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: [PATCH] Options: `--dry-run' should prevent `--touch' from touching
On Mon, 2011-04-11 at 18:49 -0500, Michael Witten wrote: On Fri, Mar 25, 2011 at 00:00, Paul Smith psm...@gnu.org wrote: On Thu, 2011-03-24 at 03:52 -0500, Michael Witten wrote: Thus, it makes most sense for `--dry-run' (`-n') to mask `--touch' (`-t') rather than the other way around (which is the current, buggy, unexpected, possibly ruinous behavior). This patch seems correct to me. Is this discussions finished then? Yes, I will make this fix. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: substantial 'glob' speedup ...
On Wed, 2011-04-06 at 12:35 +0100, Michael Meeks wrote:
These ~all come from calling 'glob'; I append a patch that tries to
call glob only if needed - it could be done more prettily:
That's interesting. I wonder why the glob expansion is so inefficient;
I would expect it to do the same kinds of checks that you're doing (that
is, basically be a string-walk unless a glob character is found).
+need_to_glob (const char *name)
+{
+ int i;
+ for (i = 0; name[i] != '\0'; i++) {
+if (name[i] == '?' || name[i] == '*' || name[i] == '[') {
+ return 1;
+}
+ }
+ return 0;
+}
Why not just use strpbrk()?
--
---
Paul D. Smith psm...@gnu.org Find some GNU make tips at:
http://www.gnu.org http://make.mad-scientist.net
Please remain calm...I may be mad, but I am a professional. --Mad Scientist
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: [PATCH] Options: `--dry-run' should prevent `--touch' from touching
On Thu, 2011-03-24 at 03:52 -0500, Michael Witten wrote: Thus, it makes most sense for `--dry-run' (`-n') to mask `--touch' (`-t') rather than the other way around (which is the current, buggy, unexpected, possibly ruinous behavior). This patch seems correct to me. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: strcache scaling issue
On Sat, 2011-03-19 at 20:47 +0300, Kirill Smelkov wrote: 100020004000500060007000 3.82.90 (with patch,2.2s4.8s14.0s 23.5s 31.6s 44.4s -O3, no asserts) 3.81 -O32.5s5.2s11.5s 14.1s 18.3s 23.8s I suspect it's to do with all the extra stuff added into the strcache; as I mentioned before, it turns out that every temporary filename we construct for pattern rule searches goes into the strcache even if they don't match anything: that's a lot of extra memory. I wonder, if you run make (both old and new) with the -r flag, if you'll see similar divergence in performance. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Make Error - trouble shooting
On Wed, 2011-02-23 at 14:58 +0900, JamesHur(허성삼) wrote: This is James Hur from Korea, I’ve been tried to solve specific problem as follow and I got the answer through the googling. - Problem : When I run make with Makefile, I got error message as : Makefile:1458:mixed implicit and normal rules. Stop - And I found the answer by this web-page : http://www.linuxquestions.org/questions/linux-software-2/error-mixed-implicit-and-normal-rules-while-trying-to-build-busybox-826795/ - He had same problem and fixed it up. - However I got trouble still due to don’t know how to change the code. - Maybe I get the source code of make utility from gnu.org and should try to change the source code, could you let me know the way how to fix it up? Pls. I seriously doubt that you want to change the code for GNU make, but if you do you can find it at ftp://ftp.gnu.org/pub/gnu/make/ You can also download the previous version (3.81) which still contains the bug in it that the makefiles you're using are exploiting. The reason the newer version of Linux works and the older does not is that the makefiles were fixed in the newer ones. Or you can fix the makefiles. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: strcache scaling issue
On Sun, 2011-01-23 at 09:59 +0100, Ralf Wildenhues wrote: * Paul Smith wrote on Sat, Jan 22, 2011 at 10:27:01PM CET: Thanks for your investigations here; that's very helpful. I had also had some thoughts about improving the strcache in various ways. For example, I was thinking maybe about splitting it into two: one for filenames and one for variable names, since these strings very rarely overlap. But a hash doesn't degrade in quality just because you put two different kinds of things in it. I wouldn't go for more complexity here. On the contrary, if you want an example where one big hash table is used for several different kinds of objects very successfully, look at git. Hi Ralf. I promoted a rework of strcache.c. For your simple scaling test on my system with debug compiled I get these results: Build Info 1000 2000 4000 3.82 -g 2.61s 8.85s 33.52s 3.82 -O2 1.90s 7.62s 27.82s New -g (with asserts) 1.03s 2.31s 5.79s New -O2 (no asserts) 0.65s 1.50s 3.52s Not exactly linear yet but much improved. However there are other issues I've seen. First, I've discovered far too much is being added to the strcache; all the temporary strings found during implicit rule evaluation, even those which do not match, are being permanently stored, which is bad!! Second, related to my comment above on splitting into two caches: I think I have a reason to want to do this. On some types of make compiles, we need to match filenames case-insensitively but we never want to match variable names insensitively...! So more work to come in these areas (among others). -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: a bug of GNU Make 3.82 ?
On Sat, 2011-02-19 at 22:30 +0800, ygsoft_plus wrote: When I compile a source code with it, there is often this error : Makefile:431: *** mixed implicit and normal rules. Stop. It means the following two lines of the code have error : config %config: scripts_basic outputmakefile FORCE / %/: prepare scripts FORCE There is a lot of code in the Makefile of my source code which like the above two line code. If I modify all of the Makefiles which has the error Makefile:431: *** mixed implicit and normal rules. Stop. , it is a very hard work. So , If I don't modify the Makefiles, how can I will not get the error? GNU Make 3.81, there is not the error: Makefile:431: *** mixed implicit and normal rules. Stop. Can you help me? how can I do about this problem? You can either continue to use GNU make 3.81, or change your makefiles (you have to split the rule into two rules, one that is explicit and one that's a pattern rule). The new way works with all versions of GNU make. See this from the NEWS file for GNU make 3.82: * WARNING: Backward-incompatibility! In previous versions of make it was acceptable to list one or more explicit targets followed by one or more pattern targets in the same rule and it worked as expected. However, this was not documented as acceptable and if you listed any explicit targets AFTER the pattern targets, the entire rule would be mis-parsed. This release removes this ability completely: make will generate an error message if you mix explicit and pattern targets in the same rule. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: [PATCH] Docs: make.texi: ; - ,
Thank you for these two patches; I've applied them in my workspace. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Using $(eval) to get information at the time a target is invoked
On Tue, 2011-01-11 at 21:05 +0200, Eli Zaretskii wrote: Okay. Any hints for where to put breakpoints to see when the Make reads the directory for the offending file (the one that gets deleted by the rule)? I'd like to compare the behavior on GNU/Linux and on Windows, so that I could decide whether this is a Windows-specific issue or not. Hm. Not really sure but IIRC all the caching stuff is contained in dir.c so I would set some breakpoints in there. If you get lost let me know and I'll go through take a look. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Using $(eval) to get information at the time a target is invoked
On Sat, 2011-01-08 at 11:35 +0200, Eli Zaretskii wrote: But I wonder if this is really Windows-specific. Could this be the example you asked for in Savannah bug#443 and #14617 (which was hoped to be solved in bug#21231)? Can you tell me what causes Make to renew the cache used by $(wildcard) on GNU/Linux? I could then try to see why it does not happen on Windows in this case. There's nothing that will renew the cache (IIRC), except that the cache has a limited size and so eventually information is removed from it that way. I would suspect something different: the cache is not loaded all at once; that is, make starts looking for files and as it does so it loads information into the cache (the cache is really implemented as a set of hooks into the standard GNU globbing library). When make finds what it's looking for, it stops loading things into the cache even if only half the files in a given directory are cached. Then later it may go back and load more things. So, the order in which things appear during readdir(), I think, along with what files make looks for, impacts what exists in the cache and what doesn't at any given time. And this behavior may be different on Windows as well. (The above is what I remember from my last foray into the caching code which was a couple of years ago at least; it's not that complicated, I just don't look at it much anymore--hopefully I'm not completely imagining how things work). ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Using $(eval) to get information at the time a target is invoked
On Fri, 2011-01-07 at 20:46 -0500, Hsu, Shihchieh IAS wrote: Summary: Using $(eval) to get information at the time a target is invoked, but instead information gotten is when “make” is invoked. Problem occurs for make3.81 and make 3.82 on Windows XP It works fine for me on Linux, after I fixed your typo: 01/05/2011 11:31 AM 0 Hello.c clean: del hello.c I realize that maybe this doesn't matter on Windows where the filesystem is not case-sensitive, but of course on Linux if you delete hello.c that won't have any impact on Hello.c which is why Hello.c still exists after the rm. In your second example, with the subdirectory, you get the cases the same: A makefile (makefile_sav) looking for files under a subfolder test works: (test contains hello.c and world.c files) clean: del test\hello.c and it works. I don't know enough about Windows to say if this case difference really matters, but you might try that. Please post a message on the make-...@gnu.org mailing list if you can't figure it out: the folks on that list are a lot more knowledgeable about make running on DOS/Windows platforms. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: mention converses
On Mon, 2010-12-27 at 16:19 +0800, jida...@jidanni.org wrote: On (info (make) Automatic Variables) you mention `$(@F)' is equivalent to `$(notdir $@)'. But on (info (make) File Name Functions) you don't mention the converse! Nobody would have guessed there are shorter ways to write those things. Only the automatic variables have special shorthand such as $(@F), etc. $(notdir ...) works with any value, and so the documentation for that function is generic and doesn't mention special cases that only work with a limited number of variables. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make's apparent weird behaviour
Hi Sergio; it would help us greatly if you'd choose an email client that would preserve whitespace in your mail when you send it; stripping leading whitespace from your messages makes it very difficult to correctly parse your examples. Thanks! On Wed, 2010-12-15 at 10:22 +0100, Sergio Villone wrote: as requested,I report the offending maketile, the result and my comment directly here in the mail body: makefile- .SILENT :; SHELL:=/bin/tcsh First, you should not use any csh derivative with make. csh is a badly broken (by design) shell and should be relegated to the dustbin of history. In particular, for the purposes of GNU make, csh/tcsh do bizarre and inappropriate things with open file descriptors which means that you cannot use GNU make's jobserver feature for parallel build support if you use csh/tcsh as your SHELL. define heastuff echo --heastuff$(1) #aa create necessary vars endef doheastuff:; echo doheastuff_heanm:$(heanm) $(foreach nm,$(heanm),$(call heastuff,$(nm))) Second, this foreach loop will not do what you want in the case where there is more than one value in the heanm variable, since the second expansion of the $(call ...) will simply be added to the first after a space. Basically if your value of heanm was foo bar then this foreach loop would be the same as writing: $(call heastuff,foo) $(call heastuff,bar) which is obviously not going to work. And, if you only ever expect $(heanm) to have a single word as its value, then the foreach is unnecessary in the first place. #aa: Command not found. This is expected because the expansion of the define appears inside a recipe context. The GNU make manual discussion of the define/endef feature says: When used in a recipe, the previous example is functionally equivalent to this: two-lines = echo foo; echo $(bar) since two commands separated by semicolon behave much like two separate shell commands. However, note that using two separate lines means `make' will invoke the shell twice, running an independent subshell for each line. In other words, if a variable created with define/endef appears in a recipe, the entire expansion is part of the recipe. That means that the comment line will be passed to your shell, and if your shell treats it like a comment then it will be a comment; if your shell does not, then it won't be. You're right that this means you cannot put make comments into define/endef variable values. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug#605639: deal better with different filesystem timestamp resolutions
On Thu, 2010-12-02 at 08:41 +0800, jida...@jidanni.org wrote: By the way, make(1) lacks any of this time comparison resolution machinery at all! I'll CC them. Can you be more clear? What is the behavior you are missing today, that you would like to have? I'm not following how this feature of cp is relevant to make. Make already uses high-resolution timestamps for comparison automatically on filesystems that support it, if that's what you mean. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #31743] ?= operator doesn't work correctly with 3.82
Hm; I thought they restored Savannah as of 11/24 after the break-in, but this bug (filed 11/23) no longer exists in the database so I guess they must have restored an earlier copy than that. Anyway this is fixed; if you want to re-submit it to Savannah that's fine: I'll mark it fixed. Otherwise never mind. Cheers! On Tue, 2010-11-23 at 16:05 +, Mounir Lamouri wrote: URL: http://savannah.gnu.org/bugs/?31743 Summary: ?= operator doesn't work correctly with 3.82 Project: make Submitted by: volkmar Submitted on: Tue Nov 23 16:05:46 2010 Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 3.82 Operating System: None Fixed Release: None Triage Status: None ___ Details: See attached Makefile. `make` should echo defaultvalue `make FOO=bar` should echo bar but echoes the empty string. This is working correctly with 3.81. ___ File Attachments: --- Date: Tue Nov 23 16:05:46 2010 Name: Makefile Size: 45B By: volkmar Makefile to test http://savannah.gnu.org/bugs/download.php?file_id=22088 ___ Reply to this item at: http://savannah.gnu.org/bugs/?31743 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #31743] ?= operator doesn't work correctly with 3.82
On Tue, 2010-11-23 at 21:10 +, Paul D. Smith wrote:
Update of bug #31743 (project make):
Triage Status:None = Verified
___
Follow-up Comment #1:
Actually it doesn't work (always) in 3.81; there's a memory corruption bug
here that shows up sometimes. But I do see your behavior with 3.82 and that's
not right either. I'll look at it.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?31743
___
Message sent via/by Savannah
http://savannah.gnu.org/
I fixed this and checked the fix into CVS. Unfortunately due to the
Savannah compromise the website is down for a while so I can't update
the bug. But, you can check out the new CVS code. Or, if you prefer,
you can apply the fix yourself (it's simple):
--- read.c 6 Nov 2010 21:56:24 - 1.195
+++ read.c 30 Nov 2010 14:48:53 - 1.196
@@ -1802,7 +1802,8 @@
int len = strlen(v-name);
gv = lookup_variable (v-name, len);
- if (gv (gv-origin == o_env_override || gv-origin == o_command))
+ if (gv v != gv
+ (gv-origin == o_env_override || gv-origin == o_command))
{
if (v-value != 0)
free (v-value);
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: possible make bug
On Sun, 2010-11-28 at 13:14 +0100, Sergio Villone wrote: you ill find in the allegate a directory containg a possible guilty makefile (prova), a text file f the result of running this makefile and a text file (comment) explaining the misleading results Hi Sergio; in the future we prefer if the problem description, etc. are included in the message itself rather than in an attached file; it's much simpler to just read the message rather than having to break open a separate tar file first. However, the behavior you're seeing is not a bug. Please check the GNU make manual section on how make reads a makefile, as well as discussions of the preprocessor statements like ifeq. Make works by completely parsing all makefiles first, and only as a second step does it start to run recipes after deciding which targets to build. Make does not evaluate the recipes of targets until and unless it decides to build those targets. Preprocessor statements like ifeq, etc. are all evaluated during the first step, the read-in of the makefiles. So, your test for the variable nlist3 is done during this first phase, before make starts to build targets. Here, nlist3 has not been set yet. Then when make decides to build the all: target it evaluates the recipe and at that time it sets the value of nlist3, so when the echo command runs it appears to have the right value. When writing makefiles the single most important thing to understand is the phases that make goes through, and when variables are evaluated. If you want to see what the value of nlist3 is when the ifeq is run, you can use $(warning nlist3 = $(nlist3)) BUT it must be on a line without a TAB; any line starting with TAB is part of the recipe and won't be evaluated until the second phase. If you want to have your recipe behavior depending on values that exist only when the recipe is run you have to use shell-based if statements, not make ifeq. Rewrite your rule as: all:; $(eval nlist3 := $$(words $$(list3))) echo list1 ($(list1)) has $(nlist1) words echo list2 ($(list2)) has $(nlist2) words if [ $(nlist1) -eq $(nlist2) ]; then \ echo list1 list2 have the same # of words; \ else \ echo list1 list2 do not have the same # of words; \ fi echo list3 ($(list3)) has $(nlist3) words if [ $(nlist1) -eq $(nlist3) ]; then \ echo list1 list3 have the same # of words; \ else \ echo list1 list3 do not have the same # of words; \ echo but nlist1:$(nlist1) and nlist3:$(nlist3) -- so what??; \ fi Also, is the output of make -v you quote in the comment file correct? It's very odd because the single most important line, the one telling us what version of GNU make you have, is missing from your output. When I run this I get: ~$ make -v GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for x86_64-pc-linux-gnu Note the first line of the output describing the version. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Make 3.82: error in french (fr) translation
On Sun, 2010-11-14 at 18:14 +0100, Christophe Jarry wrote: I found an error in GNU make 3.82, inside `fr.po' file. Line 514 of `fr.po' reads: msgstr Évitement de récursion dans une régle implicite.\n It should be replaced with: msgstr Évitement de récursion dans une règle implicite.\n (Here, `régle' has been replaced with `règle'.) Hi Christophe; thanks for the suggestion. Note that all translations of GNU packages, including GNU make, are handled through the Translation Project (http://translationproject.org/). In particular, GNU make's translation page is http://translationproject.org/domain/make.html And the page for the French translation team is here: http://translationproject.org/team/fr.html Any change to the translations needs to be submitted to them. I don't maintain any translations myself: when I make a release of GNU make I always download the latest directly from the TP site and use that in the package I create. Cheers! -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make-3.82 NEWS question
On Thu, 2010-11-11 at 12:46 -0800, Warren Dodge wrote: * WARNING: Future backward-incompatibility! Wildcards are not documented as returning sorted values, but up to and including this release the results have been sorted and some makefiles are apparently depending on that. In the next release of GNU make, for performance reasons, we may remove that sorting. If your makefiles require sorted results from wildcard expansions, use the $(sort ...) function to request it explicitly. It says Future but I am seeing this behavior in 3.82. It that correct? Yes: I meant to undo that change but due to some CVS fu before the release, my undo of that change did not make it into the official tarball even though the update of the NEWS file did. Sigh. So as it stands, the change IS in 3.82 even though the NEWS file says it isn't. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #31614] allow spaces in target names
On Wed, 2010-11-10 at 16:15 +0100, Edward Welbourne wrote: $ echo 'a b:; echo $@' | make -f - a b echo a b a b and what happens if you echo 'a b:; echo $@' | make -f - a ? If that doesn't echo a, then you've broken all rules with more than one target ... I expected your escaping to require echo 'a\\ b:; echo $@' | make -f - 'a b' or echo 'a b:; echo $@' | make -f - 'a b' or similar, so that the target's space is escaped. Unfortunately Savannah's email program is not correctly translating the bug content into email. The actual example in the bug is: echo 'a\ b:; echo $@' | make -f - a b You don't need double backslashes because it's inside single quotes. However, this is not nearly the only problem with this suggestion. Adding support for whitespace inside filenames is actually extremely tricky, because almost all of make is really just text parsing, and all that parsing is whitespace-based. None of it will work correctly in the face of target names containing whitespace. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug with comment parsing and variable expansion
On Tue, 2010-11-09 at 15:47 +0100, Rafaël Carré wrote: Hello, I believe I've found a bug in make 3.81, or at least some confusing behaviour. Here is a comparison of GNU make and netbsd 'pmake' A-$(X) isn't expanded to A-1 because of the comment on the line where X is set, although X is set to 1 X is not set to 1. It's set to 1 (note trailing space). This is documented and required by the POSIX standard: trailing whitespace on a variable assignment is preserved. % cat Makefile X = 1 #comment Y = 1 A-$(X) = a B-$(Y) = b all: @echo $(X) $(A-1) @echo $(Y) $(B-1) It's a hugely bad idea to use simple echo when trying to see values, because the shell will eat whitespace differences. You should quote the values and add characters before and after, like this: all: @echo '|$(X)| |$(A-1)|' @echo '|$(Y)| |$(B-1)|' then you will immediately see the difference. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: source file extension
On Wed, 2010-10-20 at 16:08 -0600, Duke Normandin wrote: %.o:%.mod $(MODULA) % This should be $, not %. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: need helpp//...
On Wed, 2010-10-06 at 06:14 -0700, Jasleen Sidhu wrote: i m trying to use srilm.during moses installation .i have made the changes in make file that is set srilm . but when i write 'make world' it shows following mesaage make:sbin/machine-type command not found. make.**no file to make ** The bug-make mailing list is for problems with the GNU make program. Your problem is not with GNU make (as far as I can tell), it's with the source package that uses GNU make as its build utility. So, the moses-support list you have CC'd is a good place to start. Good luck! ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Intermittent parallel make rebuild failures
On Tue, 2010-10-05 at 10:23 -0700, David Highley wrote: Good news, it appears that Red Hat 5.4 with GNU make 3.81-3 fixes the issue we are running into. Now to find the right version for Cygwin. I'd be really interested to know whether the current latest release of GNU make (3.82) has this problem or not. If not I'll need to go dig up the SRPM for that version of GNU make from Red Hat and find out what patches they've installed. That's the issue, things used to work reliably. Now we seem to accept that they work most of the time. Can you clarify what you mean by used to work reliably? With which version? The directory caching stuff predates my involvement with GNU make, so it's at least 15 years old. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Intermittent parallel make rebuild failures
On Tue, 2010-10-05 at 11:07 -0700, David Highley wrote: The latest version of Fedora 13 does not have a 3.82 verion of make so the only way to test would be to build from source which I can do. It may take me a while since were pretty busy right now. Building make from source is pretty trivial: only one binary (plus docs). You can just run it out of the build directory if you want, no need to install. But no huge rush: I'm underwater at work for at least the next few weeks as well. Do we know if anyone is working on a newer update for Cygwin? I don't; maybe a message to make-...@gnu.org would help? I really don't follow this at all (I know, lucky, right? :-)) but my vague impression is that people are moving away from cygwin and towards mingw. Paul has it really only been 15 years. I though our discussions went back to 1995 or so when you were working a Bay Networks. Well, I've been using GNU make heavily since 1988 or 1989 so it's likely we did have those discussions. But I took over maintainership from Roland in 1996 (as best as I recall). ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: The bugs in make v3.82
Please send all questions to the mailing list, rather than emailing me personally. Thanks! On Wed, 2010-09-29 at 12:43 +0400, Alexander Kornilov wrote: 1) Are the special target which executed before all other target? It's maybe used for some initializations and preparing of build process (e.g. remove log files from previous build). No. But you can fake it with the trick I mentioned in my last email, using $(shell ...) in an immediate context: __dummy := $(shell whatever) Here, whatever will always be executed before any rule is attempted. You can leave out the variable assignment if you're sure the script will not generate any output to stdout. 2) Are the special target which executed when error was occurred? It's maybe helpful to display detailed log when error was occurred while compilation. No. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: The bugs in make v3.82
On Tue, 2010-09-28 at 13:54 +0400, Alexander Kornilov wrote: BUG #0001: --- Description: The rule for generation dependency file (%.d) doesn't work on Linux platform; Severity: Major; Steps to reproduce: 1. Unpack bug_0001.zip files from letter attachment; 2. Execute makefile from archive on Linux platform. Result of operation: make Creating dir Obj Generate dependency for test1.cpp Generate dependency for test2.cpp Interesting. When I tried your test case with GNU make 3.82 it failed with a different, very subtle bug. However, your makefile is wrong and that's why it's failing for you in GNU make 3.81. I have no idea why it works in Windows; if it does that's a bug in the Windows version of make, IMO. You have rules like this: %.o: %.cpp makefile @echo Compiling $; @echo $@ $(objDir)$(slash)$@ This goes against one of the fundamental rules of writing makefiles: your recipe MUST update the target that make wants it to. The target make wants it to update is the file $...@. Your recipe is not creating $@, it's creating $(objDir)$(slash)$@, which is an entirely different file. Basically, your approach is not going to work. You are trying to use vpath to find _OBJECT_ files, but when make runs the object files don't yet exist so make can't find them. You can't use vpath for this; vpath is only for finding _SOURCE_ files: files that always exist, not files that make builds. I think you should read the following; they bear directly on your situation: http://make.mad-scientist.us/rules.html http://make.mad-scientist.us/vpath.html http://make.mad-scientist.us/autodep.html Klocwork: -- In file klocwork_report_make_v3.82.zip I attach static code analysis tool Klocwork report for make v3.82 generated by my build system. Klocwork find many vulnerabilities and warnings in make code. According my experience Klocwork is 'smart' tool and maybe you find it's comments useful for make improvement. I'll take a look but often these tools show many false positives. Make language: --- In my build system I am often use condition constructions and upset by make language restrictions Are you plan support condition construction like this: ifeq ($(SHELL), sh.exe) (($(target_platform), WinXP) || ($(target_platform), WinVista)) endif ifeq ($(SHELL), sh.exe) .. elif ($(SHELL), /bin/bash) .. endif I mind AND ( and OR (||) 'elif' operations in ifeq. In GNU make 3.82 you can write ifeq else ifeq endif-style constructs. There are also $(and ...) and $(or ...) functions available in both 3.81 and 3.82. However, they don't work quite as you describe above. Please check the manual for full details. Questions: --- I doesn't find solve of this my problem in user-guide. Could I 'know' what particular target user pass to make? e.g. make clean Look up the MAKECMDGOALS variable in the manual. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: The bugs in make v3.82
On Tue, 2010-09-28 at 18:42 +0400, Alexander Kornilov wrote: Could you, please, review my new example (bug_0001_fixed.zip attached)? But some issue still present on Windows platform: Preconditions: 'Obj' directory present as dependency of target (see example from attachment). Obj/%.d: %.cpp makefile Obj 1. Execute make. File Obj/test1.d Obj/test2.d Obj/test3.d was generated; 2. Delete file Obj/test2.d; 3. Execute make again. Expected result: Only Obj/test2.d generated. Actual result (Windows platform): File Obj/test1.d Obj/test2.d Obj/test3.d generated again on Windows platform. Please keep it on the mailing list so everyone can see. First you can reduce these lines: objList := $(srcList:%.cpp=%.o) objList := $(addprefix $(objDir)/,$(objList)) to just: objList := $(srcList:%.cpp=$(objDir)/%.o) Ditto for depList. You still have a bug in your makefile, which is also very common. I'll bet it fails the same way on Linux as well, not just Windows. Here's the rule that's causing your problems: $(objDir)/%.d: %.cpp $(objDir) makefile This lists the directory Obj as a prerequisite of all the .d files. Directories are treated no differently than any other file by make; the time last modified of the directory is checked against the target. The problem is that the time last modified on a directory is updated when (and only when) the directory itself changes: that is, a new file is added, or a file is removed, or a file is renamed. That means that every time you add/remove/rename a file in the Obj directory, the directory timestamp is updated and any .d file that has already been created will be considered out of date, and rebuilt. Using a directory as a normal prerequisite is almost never what you want. You have two choices. I prefer the simple one which is to just force the directory to be created whenever the makefile is invoked; something like: __dummy := $(shell mkdir -p $(objDir)) The advantage here is this is executed as the makefile is read in, every time, so you don't have to list this as a prerequisite of any target to make sure it's created. The other choice is to use an order-only prerequisite (see the manual). This would be something like: $(objDir)/%.d: %.cpp makefile | $(objDir) The downside is you have to remember to do that for any rule that writes to $(objDir). The advantage is that the directory is not created unless it's actually needed. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: There is a bug in the make manual!!
On Sun, 2010-09-05 at 11:01 +0430, ali hagigat wrote: I copied some lines of the 2010 make manual, page 19. It says prerequisite list will be: /tmp/var/bar/foo.c Where is 'var'? You're right; that should not contain a var. I've fixed that in the source. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Import statement - non-recursive make implementation
On Fri, 2010-09-03 at 17:45 +0200, Kamil Mierzejewski wrote: I came up with a solution to this long-lasting, largely-talked problem of recursive make invocation. Can you please clearly describe the problems you want to solve, then describe the solutions you came up with? The above problem definition is a little vague, and without knowing what you're trying to accomplish it's difficult to judge your description of the changes. Thanks! -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: There is a bug in the make manual!!
On Sat, 2010-09-04 at 11:12 +0430, ali hagigat wrote: Please check the following section of the make manual: I'm not quite sure what you're trying to say. You have a version of the manual published in 2006. It has a problem. There have since been new versions of the manual made available, that have the problem fixed. What do you want us to do about this situation? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Make error
On Wed, 2010-09-01 at 14:15 +0530, Tejbahadur Singh // Viva wrote: /bin/sh: line 1: glib-mkenums: command not found make[2]: *** [s-enum-types-h] Error 127 This mailing list is for problems with the GNU make program itself. We can't possibly help troubleshoot all the hundreds of thousands of software packages that use make to control their builds. The above issue is caused by the software you're trying to build failing, not GNU make failing. You'll have to find a mailing list dedicated to supporting that software (looks like pango-1.21.1) and ask them why your build is failing. If I had to guess I'd say you need to install a package on your system (whatever it is) that provides the glib-mkenums command, because it's missing. That's about all I can say. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make-3.82 testcases fail *sometimes*
On Mon, 2010-08-30 at 19:52 +0200, Matthias Hopf wrote: All except those in targets/SECONDARY (which I do not 100% understand yet) are related to tests using sleep for parallelization tests - something highly unreliable on systems with lots of processors and high load. Lots of processors shouldn't make a difference; if you sleep 2 it'll wait for (at least) 2 seconds, no matter whether you have one or 4,096 processors. If your system is under very heavy load then I guess it could matter although having a sleep 2 take 4 or more seconds before you wake up, for a simple command-line tool like make, seems like you would have to have a REALLY REALLY high load. Using configurable factors is not something I want to get into. If it's really the case that if you have two invocations of sleep, one sleep 2 and one sleep 4, running at the same time, and you can't guarantee that the sleep 2 will finish before the sleep 4, then we'll need to find a completely different method of testing parallel builds. Maybe we could do something like use locking files (one process sleeps for a second and creates file X, another process waits for file X to exist then sleeps for a second and continues). The problem here is doing it in a portable way, so it works on both UNIX and Windows (for example) systems is not so simple. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make-3.82 testcases fail *sometimes*
On Tue, 2010-08-31 at 16:10 +0200, Matthias Hopf wrote: In effect, the tests of make 3.81 failed on our build systems every now and then. For 3.82 this is worse, I was able to sometimes fail one of the tests even on my local workstation with 8 cores and not too much stuff running otherwise. It was one of the targets/SECONDARY, though, without the use of any sleep. Looking at that rule I can see why it might easily show incorrectly. I'll think about how to best fix this. I'm inclined to simply make the cp commands silent (prefixed with @) and let the error message if the file doesn't exist indicate the order error. But I'll need to look at the details of why that test was created. I already wrote that this issue exists when make version 3.81 was released, and the discussion wasn't exactly long or productive. It's hard for me to track issues long term via email. Is there a Savannah bug filed about this? That's the best way to make sure it's not forgotten about. For bugs related to the test suite I really need the entire work directory, not just a description and a patch. Maybe we could do something like use locking files (one process sleeps for a second and creates file X, another process waits for file X to exist then sleeps for a second and continues). The problem here is doing it in a portable way, so it works on both UNIX and Windows (for example) systems is not so simple. As the files don't have to be locked, but rather only created and tested for existence (if using single use names), I think this would be possible to do. Let me think about it. Right, I didn't mean flock() or something; I just meant test for existence. But, doing a loop waiting for a file to exist in a UNIX shell vs. Windows command.com (for example) is not simple. I don't think deadlocks are a problem here: we aren't trying to test a cycle in the graph (there cannot be a cycle), we just want to be sure things are created in the right order. The first thing we should probably do is determine if the test suite runs on Windows and if so which of the Windows variations it supports (cygwin/mingw/native windows32/dos/etc.) -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make-3.82 testcases fail *sometimes*
On Tue, 2010-08-31 at 20:15 +0300, Eli Zaretskii wrote: From: Paul Smith psm...@gnu.org Date: Tue, 31 Aug 2010 10:40:55 -0400 Cc: bug-make@gnu.org Right, I didn't mean flock() or something; I just meant test for existence. But, doing a loop waiting for a file to exist in a UNIX shell vs. Windows command.com (for example) is not simple. I don't see a problem: the test suite is written part in Perl and part in Bourne shell commands in the Makefile's generated by the tests. Both behave roughly the same on DOS/Windows as they do on Unix. There's no command.com anywhere in sight, not in the test suite, because the test suite cannot be run at all using the native DOS/Windows shells. That's good to know. Then, we can probably implement a straightforward loop test using sh (while [ ! -f somefile ]; do sleep 1; done) and assume it will work on Windows (at least as well as it works today). Too bad GNU's version of sleep, that accepts fractional seconds, is not portable :-). ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make-3.82 testcases fail *sometimes*
On Tue, 2010-08-31 at 20:32 +0300, Eli Zaretskii wrote: From: Paul Smith psm...@gnu.org CC: mh...@suse.de, bug-make@gnu.org Date: Tue, 31 Aug 2010 13:24:45 -0400 Too bad GNU's version of sleep, that accepts fractional seconds, is not portable :-). How about introducing a new Make function $(sleep) ? ;-) I don't see how that can work...? We don't want make to sleep, we want the job make invokes to sleep (to emulate a compile that takes some amount of time). ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make-3.82 testcases fail *sometimes*
On Tue, 2010-08-31 at 21:15 +0300, Eli Zaretskii wrote: From: Paul Smith psm...@gnu.org CC: mh...@suse.de, bug-make@gnu.org Date: Tue, 31 Aug 2010 13:41:44 -0400 How about introducing a new Make function $(sleep) ? ;-) I don't see how that can work...? We don't want make to sleep, we want the job make invokes to sleep (to emulate a compile that takes some amount of time). A sub-make could sleep, no? What I'm saying is that if you have a rule like this: foo: $(sleep 0.10) echo hi The recipe is always expanded by make before it invokes the shell command, so it would be make that runs the sleep operation, and make that sleeps, before the shell is even started. I don't think that would help the issue we're trying to solve (I really can't see a valid use-case for $(sleep) to be honest). But, maybe you were thinking of something different? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Showing file/line number combinations when executing make
On Sun, 2010-08-22 at 15:05 +, e...@opera.com wrote: Quoting Edward Peschko e...@yahoo-inc.com: My question - how do you actually trace this back to the target that generated this statement? In this case, the ghostscript Makefile is so convoluted that it goes through levels of indirection to get to this point, so grep is of limited help here. So - why can't make add (optionally, of course) a line number/file name combo to each of the statements that it executes - and as an additional option show the text of the makefile that is executing at the time? See recent thread: http://lists.gnu.org/archive/html/bug-make/2010-07/msg00159.html http://lists.gnu.org/archive/html/bug-make/2010-08/msg2.html Summary: The feature you describe would indeed be a nice thing to add. It's possible to simulate it at present if your make-files are nicely written, but tiresome if you're dealing with someone else's make files that didn't contemplate the need to do this. In GNU make 3.82 if you enable basic debugging (that is, any level of debugging including --debug=b) you will see information on where the command was defined (makefile and linenumber); for example from a build of GNU make itself, with --debug=b: make[2]: Entering directory `/home/psmith/src/make/make-temp' Successfully remade target file `config.h'. Prerequisite `job.c' is newer than target `job.o'. Prerequisite `job.c' is newer than target `job.o'. Must remake target `job.o'. Invoking recipe from Makefile:521 to update target `job.o'. gcc ... -MT job.o -MD -MP -MF .deps/job.Tpo -c -o job.o job.c job.c: In function 'construct_command_argv_internal': job.c:2287: warning: unused parameter 'batch_filename_ptr' mv -f .deps/job.Tpo .deps/job.Po Successfully remade target file `job.o'. Prerequisite `job.o' is newer than target `make'. Must remake target `make'. Invoking recipe from Makefile:481 to update target `make'. gcc ... -o make ... Successfully remade target file `make'. Hm. I think the Invoking lines should be indented too. Also it's odd that the newer than target lines for job.c are printed twice; I'll have to look into that. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Showing file/line number combinations when executing make
On Sun, 2010-08-29 at 14:13 -0400, Paul Smith wrote: On Sun, 2010-08-22 at 15:05 +, e...@opera.com wrote: Quoting Edward Peschko e...@yahoo-inc.com: My question - how do you actually trace this back to the target that generated this statement? In this case, the ghostscript Makefile is so convoluted that it goes through levels of indirection to get to this point, so grep is of limited help here. So - why can't make add (optionally, of course) a line number/file name combo to each of the statements that it executes - and as an additional option show the text of the makefile that is executing at the time? See recent thread: http://lists.gnu.org/archive/html/bug-make/2010-07/msg00159.html http://lists.gnu.org/archive/html/bug-make/2010-08/msg2.html Summary: The feature you describe would indeed be a nice thing to add. It's possible to simulate it at present if your make-files are nicely written, but tiresome if you're dealing with someone else's make files that didn't contemplate the need to do this. In GNU make 3.82 if you enable basic debugging (that is, any level of debugging including --debug=b) you will see information on where the command was defined (makefile and linenumber); for example from a build of GNU make itself, with --debug=b: I decided this was not so great. I've implemented (in CVS now) a new flag, --trace, which does two things: first, it always shows the complete recipe even for recipes that are marked as silent. Second, it shows a reference line for each rule that's run in the standard GNU format: filename:lineno: update target `target' due to: $+ Or: filename:lineno: target `target' does not exist For builtin rules, the filename/linenumber is replaced with builtin. This way, you can use tools that can parse the standard GNU output to jump from place to place. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: include Makefile path
On Wed, 2010-08-25 at 10:24 +0200, Stanisław Findeisen wrote: Is there any way to know a path (absolute, or relative to the primary Makefile) of an included Makefile? In that included Makefile of course. Look up the documentation for the MAKEFILE_LIST variable in the GNU make manual. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: GNU Make 3.82 raises make: free(): invalid next size (fast) error when building Android
On Wed, 2010-08-25 at 02:26 +0200, Alexis ROBERT wrote: Something more like ... this ? :) Program received signal SIGABRT, Aborted. 0xb7fe1424 in __kernel_vsyscall () (gdb) backtrace #6 0xb7ef21cd in free () from /lib/libc.so.6 #7 0x080522a6 in func_sort ( o=0xc6d9eb4 t/host/linux-x86/bin/accRuntimeTest out/host/linux-x86/bin/run-core-tests-on-ri out/target/product/generic/data/app/AndroidCommonTests.apk neric/system/bin/qemu-props\fw*x\f\202'x\f1, argv=0xbfffd5e0, funcname=0x806b201 sort) at function.c:1183 Wow, this is very strange. All I can assume is that there's some memory corruption here because the malloc/free in func_sort() looks correct to me. Are those special characters in that string (e.g., is \202 a 4-char string of \, 2, 0, 2, or is it a single character with value 0202)? Ditto for the \f; is that one or two characters? Do those characters appear in the actual makefile somewhere, or is this the result of some kind of corruption? If you happen to have valgrind installed it would be interesting to run the make instance inside valgrind and see what it complains about. Are you somewhat proficient with GDB? If I suggested some breakpoints to set and things to print would you be able to do that? -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: GNU Make 3.82 raises make: free(): invalid next size (fast) error when building Android
On Tue, 2010-08-24 at 20:03 +0200, Alexis ROBERT wrote: I'm trying to build Android with ArchLinux for my Nexus One and I'm having the following message during the build : find: `drm/java': No such file or directory find: `drm/java': No such file or directory external/qemu/Makefile.android:1101: warning: overriding recipe for target `external/qemu/android/avd/hw-config-defs.h' external/qemu/Makefile.android:933: warning: ignoring old recipe for target `external/qemu/android/avd/hw-config-defs.h' *** glibc detected *** make: free(): invalid next size (fast): 0x0d0e8ea0 *** I've not seen this before. I wonder if it has something to do with overriding recipes? Thanks for reporting it. However: === Backtrace: = /lib/libc.so.6(+0x6c7b1)[0xb775a7b1] /lib/libc.so.6(+0x6d52b)[0xb775b52b] /lib/libc.so.6(cfree+0x6d)[0xb775f1cd] make[0x8050558] make[0x804fad1] ... make[0x8058def] This backtrace is not useful because your version of GNU make was compiled without debugging enabled. Can you get a copy and build it with CFLAGS=-g to enable debugging and disable optimization, then force the failure and report the stack trace? That would be very helpful. Thanks! PS. Note I'm on vacation this week so I won't be able to provide very timely replies. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: mixed implicit and normal rules
On Wed, 2010-08-18 at 07:17 -0500, Peter Fales wrote: A user has complained about Makefiles that broke when we updated from make-8.31 to make-3.82, demonstrated by this sample Makefile: Help %:: @$(ShowTargets) As I understand it, this is intended to catch the unspecifed target and print the help message. When make-3.81 is used by running make it prints Hello World Wouldn't using .DEFAULT be better/faster? A catch-anything pattern rule like that is very expensive. but 3.82 prints Makefile:7: *** mixed implicit and normal rules. Stop. I don't understand this well enough to know which is the correct behavior or what the error message is trying to tell me. Is 3.82 working as expected? Is there some more correct way to accomplish the same result? The previous behavior of mixing implicit and pattern rules in one line like that was never supported or documented, but due to a hole in the parser it worked for certain specific cases (for example, reversing that line so the pattern comes first would not work, nor would adding extra explicit targets after the pattern target). In 3.82, the parser was tightened in this respect and that hole was closed, hence you see this error. The right way to fix this is to write two rules: Help: @$(ShowTargets) %:: @$(ShowTargets) However, as above if you can use .DEFAULT it would be much more efficient. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Override... but not really
On Mon, 2010-08-09 at 11:54 -0700, Philip Prindeville wrote: I guess I was thinking that variables are exported between makes the same way that environments variables are passed between processes. Well, certainly variables CAN be exported by make (see the export command) and passed to sub-makes that way. However, those variables have the least priority so you have to be very careful. Using make CFLAGS=-DA would still not be possible because that would override the env. var. You could run CFLAGS=-DA make and that would work. Also, see the -e flag to make which allows env. vars. to have a higher precedence than makefile vars... but this is highly dangerous because users might have odd env. vars. in their ~/.bashrc etc. Hm. Actually, you might be able to do this, because you can reset the MAKEOVERRIDES variable to empty. Of course that would delete ALL command line variables, so it could limit your flexibility on the command line. But, what you'd do is override and export CFLAGS, then set MAKEOVERRIDES to empty so that sub-makes wouldn't have any command-line settings. Now I think sub-makes would get the value of CFLAGS from their parent. It would have to be tested and proven; there may be subtle areas that are not well-behaved. This will require rewriting several hundred makefiles. I don't think there's any possible way to do this without changing makefiles. It's a good idea to test the implementation on a small subset before creating a huge environment based on that implementation :-) If you're going to have to do this anyway you might consider changing your makefile environment so that individual makefiles only set a few variables and all common bits are contained in some command makefiles that are include'd by the rest. This can drastically cut down on the amount of editing you have to do when you change things. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Override... but not really
On Mon, 2010-08-09 at 12:41 -0700, Philip Prindeville wrote: Alas much of this is beyond my control, and it's not a single project: it's a Linux distro having a couple of hundred projects, many of which have several directories deep of makefile nesting. Ah, well, you didn't say so :-). One would suspect that if these are Linux distro packages, these packages are all, or at least mostly, autoconfiscated. Autoconf (or more specifically in this case, automake) obeys the GNU programming standards which requires the behavior I already mentioned: that CFLAGS, CPPFLAGS, CXXFLAGS, LDFLAGS, etc. are all reserved for use by the user, and they can be overridden on the make command line without bad effects. Basically they work just as I mentioned above. Of course, there are always some people who don't like autoconf and think it's too difficult, and instead create their own build/configure systems. Well, these systems either ignore all the use-cases that make autoconf difficult in the first place, and thus do not support the features that people need in uncommon environments, and hence are not useful/usable for any installation that doesn't closely match the authors'; or else they're complicated in their own, non-standard way which means more effort for the user (that's you) when they want to build things. Anyway. What was I talking about? Oh yes. Nevertheless most makefile developers have resolved this issue one way or another, already. So you shouldn't need to (and you shouldn't WANT to) rewrite all their makefiles. You just have to learn how they did things. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: Override... but not really
On Mon, 2010-08-09 at 14:00 -0700, Philip Prindeville wrote: The offender I'm staring at right now is ppp-2.4.5. I'll try to autoconfiscate it (autoconf + obsfucate?) later. I wasn't suggesting you should autoconfiscate it. I was suggesting the maintainers of the package should. PPP is a bit of a special case because it's been around for so long, it's almost grandfathered. I suggest you take a look at the PPP makefiles and see if there's not some simpler way to go than reworking it for autoconf: that seems like a huge amount of work. Certainly you shouldn't attempt it, IMO, unless you feel that the PPP maintainers are willing to adopt those changes. Maintaining them out of the tree, as patches, will be difficult. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: make 3.82 fails on powerpc defconfig update [was: Linux 2.6.35]
On Mon, 2010-08-02 at 11:51 +0300, Thomas Backlund wrote: BOOT_TARGETS = zImage zImage.initrd uImage zImage% dtbImage% treeImage.% cuImage.% simpleImage.% Now, I dont know if this is intended breakage by the make update, or if the Makefile needs to be updated The change is intentional. Note, though, that this syntax was always dodgy, even in previous versions of GNU make. If you wrote it exactly as you did, where all the explicit targets come first and all the implicit targets come second, then it seems to have been interpreted correctly. However, if you did it any other way (for example, put some explicit targets after the first implicit target) then make would silently throw away all the targets starting with the first implicit target. Since the syntax used here wasn't ever described in the documentation, rather than reworking it as a new feature I decided to follow the docs and disallow it, and be verbose about the error. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: [RFC]serialize the output of parallel make?
On Thu, 2010-07-29 at 22:44 -0700, Howard Chu wrote: The scheme that I grew up with on Alliant Concentrix was just to prefix each output line with its job number |xx|blah blah blah. It obviously requires a pipe for each child process' output, so that lines can be read by the parent make and then the prefix attached. The resource issue is one thing for sure, but even more than that I'm not sure that would work with make's current, single-threaded design. Make doesn't really have any central loop where we could add a select() or whatever to check which children had output ready to be processed, so _where_ to add this is a big issue... if we don't read the pipe fast enough then jobs will slow down as they hang on the write(). I think asking make to do this work will simply cause your builds to slow down a lot, unless we introduced threads and had a separate thread doing that work. Or, we could implement the other idea you had for more reliable jobservers (avoiding the RESTART issue), which had make fork a process and then had that process fork the job: in that environment there's an extra process that can be used to manage each child's output. Of course this has its own drawbacks on systems with very high process creation overhead, like Windows. And serialzation you mean is not the same as I mean. I believe Paul and Edward fully understand what I mean. I think Tim is saying the same thing: his solution will definitely work, at least as well as having make do it. If make did the work then it would invoke the command with stdout/stderr redirected to a temporary file, then when the job was complete make would read and print those files to stdout. In Tim's solution, the command that make invokes (really, the shell make invokes to run the command) saves its OWN output to a temporary file, then when the command is done it gets a semaphore (to ensure serialization) and dumps all that output. Actually I suspect that Tim's solution would be MORE efficient, because if make is reading large output files and streaming them to stdout, that's time it DOESN'T spend doing other, make-like things. If you have the command itself doing it then you get the advantage of multi-processing involved. I certainly don't see how it could be SLOWER; if you want to enforce serialization then at some point, someone is going to have to wait--that's more or less the definition of serialization. I don't see how the command waiting is any less efficient than make doing basically the same thing. This is all assuming that by serialization you mean ONLY that the output from each command will be grouped together, without interspersing any other command's output. If you mean something more, such as that the output of the commands appears in some deterministic fashion (for example, given the rule a: b c d that the output of the command to build b would always come before c and that would always come before d) then that's much more difficult, and not what I was suggesting. -- --- Paul D. Smith psm...@gnu.org Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: gmake Error.
On Fri, 2010-07-30 at 13:31 -0400, Ana Zoghbi wrote: I would like to kindly ask your help with an error I’m getting when running the gmake command. I would appreciate anything that you could do to help me. I’m trying to install the sudosh2 SW that I downloaded from this site gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -Werror -MT parse.o -MD -MP -MF .deps/parse.Tpo -c -o parse.o parse.c cc1: warnings being treated as errors parse.c: In function 'parse': parse.c:22: error: incompatible implicit declaration of built-in function 'bzero' gmake[2]: *** [parse.o] Error 1 This is an error given by your compiler, because the compilation of the source code for this package failed on your system. The last message, from GNU make, is just telling you that make gave up because the compilation failed. This list can, unfortunately, only help you with errors in GNU make itself: we cannot advise you about errors in random software that might use GNU make to build. I recommend you go to the sudosh2 site in SourceForge and find mailing lists or bug tracking tools or support forums related to sudosh2, and ask about your error there. Be sure to specify which operation system (and version of the OS) you're using as well. Good luck! ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
