Re: Strange GNU make behavior with -include ?
%% Grégoire Sutre [EMAIL PROTECTED] writes: gs I was having errors with my Makefiles (for Objective Caml), and I could gs pinpoint the problem with the attached very simple Makefile. gs Basically (please see the attached Makefile), I use a: gs -include fake.depend gs statement to include a dependencies makefile 'fake.depend', but gs this included makefile does not exists and cannot be made. gs Indeed, fake.depend can be made from fake.c, but fake.c does not gs exist, and it isn't the target of any rule -- explicit or gs implicit). gs So I expected make to simply ignore fake.depend (as explained in gs GNU make's manual). Not quite. The manual says that if the makefile does not exist and cannot be remade, then it will be ignored. By cannot be remade, the manual really means make doesn't know of any way to remake it. Because make can imagine a way to recreate the included makefile, it tries to do so (this is a result of the auto-re-exec feature of GNU make; it has nothing to do with whether fake.c is a prerequisite or not). If the rebuild fails (in this case because there is no fake.c) then it stops with an error. It's not clear to me which is the correct behavior in this case, but make has always behaved as it does now. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Strange GNU make behavior with -include ?
%% Ted Stern [EMAIL PROTECTED] writes: ts I'll let Paul explain why, as I would probably make a botch of it. ;-) I think it's a bug :) As Gregoire points out, the fact that a non-intermediate target exists somewhere in the makefile shouldn't cause make's rebuilding of the included makefile to fail. Anyway, I can't think of any good reason why it should :). But, I suspect that fixing this will be kind of messy :-/. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: installing gnu 3.80 on win2000
Please see the patch attached to the resolved bug 1687: https://savannah.gnu.org/bugs/?func=detailbugbug_id=1687group_id=71 -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: variable.h missing from po/POTFILES.in
Yep, I've fixed this in CVS already. Thanks for the report! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: GNU make bug concerning directory creation and prerequesites
This looks like an instance of bug #775: https://savannah.gnu.org/bugs/?func=detailbugbug_id=775group_id=71 -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Problem with shell commands on Digital UNIX V4.0F.
I can't imagine what the problem might be... certainly bash works fine for me with GNU make on Linux and Solaris... -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Using make under XP
%% Peter Goddard [EMAIL PROTECTED] writes: pg I am using make 3.79.1 under DOS on Windows XP machine. As pg far as I can see, it appears that make does not like long pg command lines. Is that true? This depends entirely on how make was compiled: whether it's using command.com or something else as the shell. See the README.W32 file in the GNU make distribution. You might also contact the [EMAIL PROTECTED] list: they know more about using make on Windows. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: always echoing commands (patch)
If you look at but #111 in Savannah, you will find that someone already reported this as a bug and supplied a patch to implement a new flag for it. FYI. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: anonymous pipe read deadlock
I don't have any good ideas about your problem: I don't use Windows myself. You can try asking on the [EMAIL PROTECTED] mailing list; people more knowledgeable about the issues surrounding shells in GNU make for Windows read that list. Otherwise all I can suggest is that you try a newer version of GNU make; the latest is 3.80. Note that there's a bug in the Windows build scripts for GNU make 3.80; see this report (and attached patch) for more information: http://savannah.gnu.org/bugs/?func=detailbugbug_id=1687group_id=71 -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Variable assignments
%% Jeff Bailey [EMAIL PROTECTED] writes: jb Is there a way to watch variable assignments as they happen? No. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: reg: the error while doing make
%% Ajit kumar [EMAIL PROTECTED] writes: ak when I am running a make, every 2 or 3 times it runs, make ak crashes ak with the following error: ak make.exe - Application Error ak The instruction at 0x0f048d8a referenced memory at ak 0x01340ffc. The ak memory could not be written. ak Note : I am using the GNU Make version :3.74 ak Any suggestions/help would be appreciated I didn't think GNU make 3.74 was ever ported to Windows. Anyway, this is an incredibly old version. I suggest you try something more recent. You should ask questions about the DOS and Windows ports of GNU make on the [EMAIL PROTECTED] mailing list. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: MAKEFLAGS not updated when it already exists?
I would agree that GNU make's behavior here is not according to the standard... it looks like you're right: the flags that are in MAKEFLAGS as a consequence of the initial invocation of make take precedence and no extra flags that are added to a sub-make will be added to MAKEFLAGS. I tested back as far as GNU make 3.75 and this has always been the case. I'll look into it. Please submit a bug against GNU make in Savannah on this, thanks! https://savannah.gnu.org/projects/make/ -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Work around bugs in pre-3.0 UWIN ksh makes bash-2.02.2 panic
%% Daniel Goujot [EMAIL PROTECTED] writes: dg maremma:/4go/tmp/make-3.80% sh --version dg GNU bash, version 2.01.1(1)-release (i586-pc-linux-gnu) dg Copyright 1997 Free Software Foundation, Inc. dg This shell will make segmentation fault on these lines : dg # Work around bugs in pre-3.0 UWIN ksh. dg $as_unset ENV MAIL MAILPATH dg PS1='$ ' dg PS2=' ' dg PS4='+ ' dg (found in make-3.80/configure, make-3.80/config.status, and maybe dg other places) In installation of gmake-3.80, ./configure step dg won't work unless these lines are removed. Hm. Well, this is really a bug in bash, but since that version is so old I doubt you'll be able to get a patch for it: they'll probably just say you should upgrade. If you really want this old version of bash supported, then you should report this as a bug to the autoconf folks ([EMAIL PROTECTED]). There's not much that GNU make can do about this, since it just uses autoconf to generate the configure file. HTH! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: $(wildcard) not expanding generated files
%% Johan Bezem [EMAIL PROTECTED] writes: jb this seems to be by design, to overcome the fact that jb OBJECTS = *.o jb doesn't expand the list, whereas jb OBJECTS = $(wildcard *.o) jb does. $(wildcard is expanded upon the first pass over the jb makefile, ie. when no rules have been executed yet; This is not true... or at least not in the above case. The $(wildcard ...) function is expanded using exactly the same rules as make variables and the other functions: there are _no_ special cases. In the above example, because the variable is recursive $(wildcard *) is _not_ expanded when that line is read. all: @touch testfile install: all @echo $(wildcard testfile) clean: @rm testfile In this makefile the $(wildcard *) function is not expanded until the rule is run (it is _not_ expanded when the makefile is read, just like $@ in a command script is not expanded then, etc.) So, on the face of it this seems like it should work. Why doesn't it work? It doesn't work because GNU make actually caches the contents of directories as it reads them, for performance reasons. Because your makefile doesn't list testfile explicitly as a target to be created, make doesn't know anything about it and it doesn't add it to the cache of the directory. So when $(wildcard *) looks up files the cache, the new file is not there. If you make that file an explicit target, rather than a side-effect, _then_ it will work. Is this a bug or a feature? jb Feature. Maybe, maybe not. But, not as straightforward as it seems at any rate :). There have been other issues with the directory cache so at some point I'll have to investigate whether (a) we can change it to work better without gutting its entire purpose (caching to avoid filesystem lookups), or (b) introduce some syntax to disable it for those who would rather have the above behavior than the speed increase. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: EINTR causing useless recompilation?
%% Tom Rodriguez [EMAIL PROTECTED] writes: tr Hello. I've finally gotten a chance to look at this more closely tr and the problem is that GNU make assume that SA_RESTART restarts tr all system calls which isn't true for solaris and I suspect isn't tr true for any System V based Unix. Yes, experimentations shows this to be the case. Unfortunately this means that Solaris is not compliant with the POSIX specs, which clearly state that any system call that can return EINTR must respect the SA_RESTART flag. tr Why not simply define atomic_stat and atomic_readdir all the time tr and use them throughout make? It wouldn't hurt any platform that tr never returns EINTR and would guarantee that it works on any tr platform with a more restricted definition of SA_RESTART. Thanks. I am going to implement a fix similar to this. It should take care of the worst of the problems. However, this does not mean that the problem is solved: GNU make makes many hundreds of different kinds of system calls, and many are hidden behind other user-level libc functions. If SA_RESTART cannot be relied upon to behave as per the POSIX spec then it seems like there's no fully reliable way to provide for this feature without doing prohibitive amounts of work. Thanks for the note! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: GNU make 3.80 build failure on FreeBSD 5
%% Gerald Pfeifer [EMAIL PROTECTED] writes: gp GNU make 3.80 fails to build on FreeBSD 5: gp In file included from glob.c:282: gp glob.h:51: redefinition of `__size_t' gp /usr/include/machine/_types.h:86: `__size_t' previously declared here gp This can be fixed by the patch below which Mike Barcroft gp [EMAIL PROTECTED] contributed to the FreeBSD ports collection. gp I would appreciate could you roll a new release of GNU make with gp this (or a similar) fix rather sooner than later; thanks. I don't think there's any way that a GNU make release can be done for at least another month or so: the CVS code is sort of in the middle of things. It would be good, when you find things like this, if you could file a bug on the Savannah site (I get bugs from Debian, etc. that way too). Question: is this change portable to previous versions of FreeBSD as well? You test just __FreeBSD__, which I assume is defined for 4.x, etc. versions as well, so I want to make sure that this section won't cause breakage on older versions. Thanks! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: GNU make 3.80 build failure on FreeBSD 5
OK, thanks. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Possible GNU Make bug
%% David Buehler [EMAIL PROTECTED] writes: db I'm expecting this makefile to echo mylib, but it echos db Makefile then mylib... perhaps there's something esoteric db going on that I haven't figured out from the documentation. The latter :). Check the GNU make manual section How Makefiles are Remade, in particular the second paragraph. Because you have a match-anything rule, that is forced, your makefile will try to be remade every time. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: GNU Make 3.80 under Windows - compile problem
This was reported as bug #1687 and fixed in the source. The fix will be in the next version of GNU make. Thanks! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: problem with silent include and special target .DEFAULT
%% Helmut Dipper [EMAIL PROTECTED] writes: hd -include aaa hd sinclude bbb hd .DEFAULT: hd @echo target: $@ hd #-- hd and the results: hd target: bbb hd target: aaa hd gmake: *** No targets. Stop. hd How can it be avoided that the rule with the special target hd .DEFAULT is applied when trying to remade not existent hd include-files? You must declare a real rule for the makefiles; even a pattern rule will do it. hd Must empty rules be specified for each include- file which may hd exist or not? Yes, if you use .DEFAULT. .DEFAULT can make any file, so it will apply to _ANY_ file that make wants to build and which doesn't yet exist. This is a very powerful, and at the some time somewhat uncontrolled, capability. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make doesn't always reread included makefiles
%% Paul Franklin [EMAIL PROTECTED] writes: pf Under certain circumstances, make fails to notice that one or more pf included makefiles have changed and does not restart and reread pf makefiles. This is a complex problem. Here is what happens: First, make tries to rebuild Make.b (it generally tries to rebuild files in the reverse order in which they are seen in the makefile; this is an accident of implementation). It sees that in order to build Make.b it needs to build Make.a, so it does. Then the rule to build Make.b doesn't actually change Make.b (it just prints a line) so make sees that Make.b was not updated, and it won't schedule a re-exec because of that. Then make looks at the next makefile, Make.a, and it sees that it has already tried to build Make.a (as a side-effect of Make.b) so make ignores it. Then it tries to build the main makefile, and there's no rule for that. So, it gets to the end and decides that none of the makefiles was rebuilt, and it doesn't re-exec. The error here is that make should notice Make.a was rebuilt even though it was done as a side-effect of another build. If you changed your rule for Make.b to actually update the file Make.b, or you switched the include lines around so that Make.a was included after Make.b instead of before, or you removed the dependency of Make.b on Make.a, then it would work. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: GCC and related packages
%% [EMAIL PROTECTED] writes: dm Why did you change the prefix from /opt to /usr/local? /opt was dm great and standardised with HPs install locations.. /usr/local is dm a nightmare specially is /usr/local is an automounted location. First, nothing was changed: the GNU project has been using /usr/local as the default location for installation of tools since forever. It never used /opt; /opt was invented after the FSF chose theirs by various commercial UNIX enterprises. Second, GNU software installs on all sorts of different operating systems, so choosing something because it's standard on one of them (HP) is not a good reason. Third, /usr/local does not have to be an automounted location and in fact, _usually_ it's not: just because it happens to be one at your site is not a good reason for the FSF not to use it. And fourth, the /usr/local prefix is just a _default_; if you don't like it you're free to change it to /opt or /fooblitsky or whatever else strikes your fancy: it's completely trivial to do this. See the INSTALL and README files in the source distribution. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: PVCS to GNU
%% Josef Kreulich [EMAIL PROTECTED] writes: jk I am transforming PVCS-make to GNU-make scripts on AIX, and I am jk asking for the option -all. This option disables the make jk mechanisms and allows to rebuild all targets without touching. See the -B option (you need GNU make 3.80 for this). -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: problem computed variables
%% Duane Ellis [EMAIL PROTECTED] writes: de DBG_ORDER=$(RAW_DBG_ORDER:%=$(%)) de REL_ORDER=$(RAW_REL_ORDER:%=$(%)) You can't do this: patterns don't replace before expansion, they replace after expansion. It's very easy, though, just do this: DBG_ORDER = $(foreach V,$(RAW_DBG_ORDER),$($(V))) You can make a function out of it and use $(call ...) if that makes it clearer in your makefile. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: timestamps vs. checksums
%% Markus Werle [EMAIL PROTECTED] writes: mw Recently I had an email discussion about build tools. Someone mw stated that make was flawed due to the fact that it uses mw timestamps to decide whether to recompile a file or not. mw I disagree with saying that make is flawed. It is flawed, but it works as designed. When make was designed 20+ years ago, the idea that compiles could complete in less than a second or that you'd be doing builds over the network was pretty ludicrous. mw Actually NFS is flawed, which I encountered today: NFS is flawed as well, of course :). mw Checking whether a file has changed is just a minor task mw among others that make has to address. You miss the bigger picture. Sure, using md5 to find the checksum of a file is very simple. Here's the problem: what are you going to compare it to? Currently make is completely stateless, because we only compare relative timestamps between files: is file A newer than file B? Yes? OK, update file B. Make doesn't have to remember anything from one invocation to the next because all the information it uses is maintained by the filesystem. If you want to implement a checksum comparison it's a huge leap, because now make must become stateful: to know whether this file's contents have changed you have to have state from the previous invocation of make that remembers what the checksum (or whatever) was then, so you can compare it to now. Now we're talking about make keeping a database of some kind (note I'm not talking about a fancy SQL database, or even necessarily something like dbm--but you need _some_ kind of data storage). Now you run into issues like locking: what happens when someone invokes make recursively in the same directory? What about parallel builds? What about portability: not all systems have libraries like dbm--does make have to provide its own? Or do we store the checksum in one file per target rather than lots of checksums in one DB file? Etc. etc. etc. As always, the devil is in the details. That's not to say that this shouldn't be done: it's actually an absolute must-have if make is to survive too much into the future: systems are getting too fast to rely on timestamps anymore. It's on the TODO list but as I've said there are many considerations. There are a number of threads dealing with this in the archives of these lists. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: 64-bit version?
%% HOMAN,JOHAN (HP-Belgium,ex1) [EMAIL PROTECTED] writes: Please send just normal text to the list, thanks! h I installed gnu make 3.79.1 on a HP-UX system with 64 bit h settings. When I look the type of file, I see that it is for a 32 h bit system. Can you let me know how it can be runned under 64-bit h systems? When you configure GNU make it will detect whether your OS supports large files and, if so, configure itself to support them automatically. However, this capability was fairly new in GNU make 3.79.1 and I believe it didn't work for all versions of HP-UX. I would try using the latest version (3.80) and if that doesn't work please contact this list and the [EMAIL PROTECTED] list (the detection and configuration of this setting is actually done by autoconf). -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: 64-bit version?
%% Steve Ellcey [EMAIL PROTECTED] writes: se There is no reason a 32 bit gnu make won't work on a 64 bit HP-UX se system. 64 bit HP-UX systems are capable of running both 32 bit se and 64 bit executables. If you look at the standard HP make se (/usr/ccs/bin/make) you will see that it and indeed, most of the se HP commands, are still 32 bits. It's true that make doesn't need to be 64-bit itself, however it _does_ need to be able to manipulate 64-bit files. That is, you want make built with support for large files so it can use stat() (or stat64() or whatever) to find information on files which are 2G. That support should be enabled in GNU make by default if configure detects that your system supports large files. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make problem ?
Please do not send huge attachments like your GNU make binary or your complete source code to the mailing list. We do not have the resources to debug your entire environment for you. If you have a problem please reproduce it using the smallest makefile that shows the behavior you are concerned about, and requiring only simple tools, then send that. Also please show an actual invocation of GNU make (exactly what you typed) and the exact output errors that make generated; don't paraphrase. If make generates lots of output just show the parts that fail and 10 or so lines of context around that. Finally, questions about the GNU make port to Windows will often get more knowledgeable responses if you send them to the [EMAIL PROTECTED] list, which is specifically for users of the Windows port. Thanks! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Inconsistent VPATH behavior ..
%% Harsha Kalidindi [EMAIL PROTECTED] writes: hk ../install/scripts/% : % hk $(INSTALL) -m 444 $() $(@) hk gmake is looking in $(VPATH)/../install/scripts. We are not hk expecting it to. We expect it to look in VPATH only for sources hk when they don't exist in the current source tree .. But you've left out, again, the most important part of your makefile (this is why I am asking you to create a small _complete_ example that shows the behavior you have a problem with). Remember that make works from the root of the dependency graph _down_; it doesn't work from the leaves _up_. So, if make is trying to build a file that matches the above rule, then it's because you defined it as a prerequisite like this: install: ../install/scripts/foo If you run make install, then make says OK, I need to build ../install/scripts/foo. It looks to see if that file exists. If it does, then VPATH is never consulted. If it doesn't exist, then if VPATH is defined make uses it to try to find the target. How does this work? Make doesn't really grok the structure of pathnames: to make every pathname is just a string. It appends the string to the end of each directory (adding a / separator) in VPATH and checks if _that_ file exists. If it does, then this is the VPATH pathname of that file. I'm not sure I'm making myself clear, or whether I'm understanding your real problem. All of the above behavior is expected and is not a bug. If you think I'm still missing the point, there _could_ be a bug here, but I'll need you to provide me a small test makefile etc. that will reproduce the problem. Once I can see a complete example I can be sure about whether what you see is correct or not. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Inconsistent VPATH behavior ..
%% Harsha Kalidindi [EMAIL PROTECTED] writes: If you run make install, then make says OK, I need to build ../install/scripts/foo. It looks to see if that file exists. If it does, then VPATH is never consulted. hk We expect the above behavior. If it doesn't exist, then if VPATH is defined make uses it to try to find the target. hk This is how it is working and it is still what we expect it to do. [...] hk Does it look at the individual paths in VPATH plus the relative hk targets (../install/scripts/foo, in this case) first or does it hk look at just the relative targets from the directory of execution hk first? I'm not exactly sure I'm understanding you: I explained it and you said this is what you expected... then asked how it works :). GNU make works exactly as I've described above: first it looks for the pathname exactly as it is given in the makefile. If that doesn't exist, _then_ it appends the pathname that is given in the makefile onto each entry in VPATH, in order, and looks for that. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: long prerequisite inside eval(call()) = vm exhausted
You are running into a resolved bug; it will be fixed in the next release. In the meantime there's a patch attached to the closed bug report you can use if you like: https://savannah.gnu.org/bugs/?func=detailbugbug_id=1517group_id=71 -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Inconsistent VPATH behavior ..
%% Harsha Kalidindi [EMAIL PROTECTED] writes: GNU make works exactly as I've described above: first it looks for the pathname exactly as it is given in the makefile. hk Breakthrough. No more failure to communicate. This is the nub of hk the issue .. If that doesn't exist, _then_ it appends the pathname that is given in the makefile onto each entry in VPATH, in order, and looks for that. hk VPATH=/u/p/src hk install: ../install/scripts/foo hk $(INSTALL) .. hk Command run in '/u/user/src'. If hk /u/user/src/../install/scripts/foo does not exist, I would expect hk it to run the command instead of looking into hk /u/p/src/../install/scripts/foo .. Well, that's actually the entire purpose of VPATH: to tell make where else to look if it can't find the prerequisite by the pathname that the makefile provides. If you don't want that behavior then you will have to stop using VPATH. Presumably there's some other reason you need it, and the above is just an unwanted side-effect? The other option is to use the vpath pattern form to restrict the VPATH lookup to only a subset of all the prerequisites in the makefile. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: makefile include dependency bug/feature
%% Albert Ting [EMAIL PROTECTED] writes: at We've encountered an interesting dependency problem. Not sure if at this is a bug or feature. at $ /bin/rm -rf test at $ mkdir -p test/dir1 at $ touch test/dir1/file1 at $ make atMakefile:13: test/file3: No such file or directory atmake: *** No rule to make target `test/dir2/file2', needed by `foo'. Stop. at It sounds like make gets confused when a file is being used for both an at implicit rule, include file, and target dependency. It should recognize at the first implicit rule doesn't match, and reference the second implicit at rule. This does indeed look to me like a bug. However, determining exactly what's wrong looks like it will take some work, so I'll have to find time for this. I don't see the problem immediately. It definitely does work for normal patterns, so I don't know why these fail. at However, if we change the BAR definition to hold the absolute at path, we do get the correct behavior. That's interesting, because it failed both ways for me. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: attempting to make gnu make fails on FreeBSD 5.0 installation
See this thread on the bug-make mailing list archives: http://www.mail-archive.com/bug-make%40gnu.org/msg02495.html -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: GNU make - dependencies
%% ernoevi Michal [EMAIL PROTECTED] writes: m Hi, there has been a nasty bug in GNU make for a long time. It is m shown in the attached file - there is also a right output from the m supplied make from DEC. With regard Please simply provide small examples directly: I can almost always tell what the problem is by looking at it and if it's in some weird format I have to save it out, etc. first. m /usr/local/bin/make (GNU make V 3.80) m echo aresds_fo.h: aresds_fo.H m aresds_fo.h: aresds_fo.H*** WHERE IS aresds_fo_tab.h? It's right here: m echo aresds_fo.o: aresds_fo.EC w_web.h libcz2_250.h aresds_fo.h /usr/users/res/vadr/aresds_fo_tab.h GNU make found it in /usr/users/res/vadr. Because it found that file there it used that instead of trying to recreate it locally (it would have recreated the file locally if aresds_fo_tab.H was newer, but it wasn't so it didn't). To me this means that you have set your VPATH variable to contain /usr/users/res/vadr. Since I didn't see it in the makefile you sent either it must be set in your environment, or your example is not complete. Probably the OSF1 version of make doesn't support VPATH, or at least not the same VPATH semantics that GNU make does (SysV VPATH behavior is quite broken). -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make 3.80's ./build.sh won't work on NetBSD
This has already been reported as bug #1536. (See the GNU make project on http://savannah.gnu.org) It will be fixed in the next release. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make query
%% Austin, Ben [EMAIL PROTECTED] writes: ab tyree:bash-2.02# make ab Makefile:1: warning: NUL character seen; rest of line ignored ab Makefile:1: *** missing separator. Stop. Please always include the version of make you're using and the operating system and version you're running it on. The above message is printed when make detects a NUL byte (ASCII 0) in your makefile, in this case in line 1 of the file Makefile. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: $(eval within conditional causes missing `endif' error
%% Jan Beulich [EMAIL PROTECTED] writes: jb investigating the possibilities the new features in make 3.80 jb offer I found that I cannot have an $(eval inside any sort of jb conditional. As the mailing list documents that this has already jb been observed I'd like to find out what the intentions are to fix jb this. Looking further in the mailing list would surely have shown you that this bug was reported (bug #1516) and fixed already (in the source tree) and that there's a patch attached to the bug report which you can apply to your 3.80 sources to fix it: see the bug report in Savannah: https://savannah.gnu.org/bugs/?func=detailbugbug_id=1516group_id=71 jb Especially would it seem questionable to me whether the same logic jb as in the include directive handling can be applied here, since it jb may be useful to be able to interact with the conditionals state jb previously in effect. I'm not sure which include directive handling you mean, but as with include files all conditionals started within an eval must be closed within the same eval. That's the only restriction. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make error with pro*c redhat 7.2
%% Guy L [EMAIL PROTECTED] writes: gl getting this error while using make with the precompiler Pro*C (linux gl Redhat 7.2). gl GNU Make version 3.79.1 gl Here is the error: gl [make] : *** [sample9.o] segmentation fault This means your compiler dumped core. Try running the command that make printed directly from the shell and you'll probably find it does the same thing. This is not a make issue; please contact your compiler vendor. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make problems
%% Edwards, Rudolph [EMAIL PROTECTED] writes: er While trying to compile the RHL 7.2 kernel, issuing the 'make er menuconfig' or any other 'make options' the response is as follows: er Make: No rules to make target 'option . Stop er Option can be anything such as config, menuconfig, clean, mrptoper, er etc... er Do you have any suggestions? No, sorry. This is not a question about GNU make, but rather about the makefiles in the Linux kenrel. Please contact someone who works on the Linux kernel. My only suggestion is to make sure you're in the right directory; it sounds to me like you are trying to run make in a directory where there's no Linux kernel makefile. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: problems with directory in make
%% Regarding problems with directory in make; you wrote: jj I'm having problems with my makefile. I want to descend into a jj directory and issue shell commands to extract a list of files jj using either `ls` or `echo` and store in a variable. jj Here is the command: jj install: jj cd LINUX/mod; mod2=$(shell echo *) This can't work: you're confusing what is run by the shell with what is run by make. A command script is handled as follows: 1) Make expands all variables and functions within the command script. 2) Make takes the resulting string and invokes a shell with that string as the commands to run. 3) Make waits until the shell exits and checks the exit code; if it succeeds (exits with a 0 exit code) then make proceeds with the next command. If it fails (exits with a non-0 exit code) then make stops. I'm obviously ignoring special cases such as -i etc. In your command, make runs the $(shell echo *) before it invokes the shell (as part of step 1); since this is before the shell started the cd command has not been done yet. Also, you haven't quoted the results and shell variables are only set to the first word. This would work: install: cd LINUX/mod; mod2=`echo *` jj I would like to descend to LINUX/mod directory from current jj directory, echo the filenames and store in variable mod2 for later jj use. If by later use you mean within the same command line, that's fine. If you mean anything else, you can't do that. As above, you are setting a _shell_ variable because it's the shell that's running the command. Once that command is over and the shell exits, any shell variables you set within the command are gone. jj install: jj mod2=$(shell `ls LINUX/mod`) jj In this case `ls` gives the right list of filenames but shell jj attempts to execute the filenames as if it were commands. jj install: jj mod2=$(`cd LINUX/mod`; $(shell echo *)) jj mod2=$(`cd LINUX/mod`; `echo *`) jj mod2=$(`echo LINUX/mod/*`) jj These don't work at all. You're totally confused if you think any of these could possibly work. Please either get a book on make, or read the very good GNU make user's manual that comes with GNU make. You're missing the basic concepts. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make 3.80 bug and testcase
This is a known bug that has been fixed in the source for a while. A patch is available attached to the bug report in Savannah (http://savannah.gnu.org/projects/make) -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Make 3.79 can no longer quoted strings into a file using the shell
%% Pomerleau, Francois [EMAIL PROTECTED] writes: pf Hello, I am developing applications in Ada and I use make for my pf compilation. As part of my build process, I generate an Ada file pf (version.adb) that contains the build date and the release pf version. I was able to do so using previous version of make pf (3.77) that came with the compiler (GNAT). Recently, I have pf upgraded the GNAT compiler which now uses make version 3.79 but pf things no longer work. I am using Windows 2000 and bash. This works fine on the UNIX systems I've tried it with. IIRC there are known issues with 3.79 on Windows. Please try 3.79.1 instead. In general if you have Windows-specific questions the best place to ask them is the [EMAIL PROTECTED] mailing list. Good luck! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: incompatibility with unix make
%% Thomas Abendroth [EMAIL PROTECTED] writes: ta I use GNU-make WIN32 version 3.79.1. for some days and I found ta out, that the makefile code below does not work. With Borland ta 'make' and Solaris 'make' the same makefile works perfectly. Does not work is not a helpful bug report. A very brief review of your makefile shows only one obvious problem: ta .SUFFIXES: .$(OBJ).cpp Suffixes must be space-separated. The above line should be: .SUFFIXES: .$(OBJ) .cpp If that doesn't help please provide a small makefile which reproduces the problem, the command you typed, and the exact output you got, as well as what you expected to get. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Canned command sequences
%% Ted Stern [EMAIL PROTECTED] writes: ts The essence of what you are asking is, Why isn't the '@' ts indication of no-echo respected by Make's $(call ) function and ts applied to the entire call? ts IIUC, the answer is that you need to consider how define/endef ts differs from a simple variable definition. ts In other words, what the all target sees after $(call) is ts evaluated is something like tsall: tsTAB @set -e; TAB echo hello tsTAB echo hello again ts Both '@' and the shell setting 'set -e' are applied only to the ts first shell, so the second line of $(rule_up) is echoed. ts Paul, did I get that right? Yes, exactly. In fact, it was a regression in 3.79.1 which allowed it to work there, and I fixed that bug in 3.80. If you use older versions of GNU make you'll see they work like 3.80, not 3.79.1. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make: *** virtual memory exhausted. Stop.
%% Fabio Alemagna [EMAIL PROTECTED] writes: fa That happens when using a construct like this: fa define function fa target: very long dependency list fa whatever fa endef fa and then passign that to $(eval) trough $(call). By reading the ml fa archives I got to know that this is a pretty old bug, which should fa have supposedly been fixed in a release which, at the time, was fa about to be made. However it appears that there have no been any fa more releases since then... Am I to assume that this bug will fa never be fixed (I read about the patch, but I also read it doesn't fa work as it should)? It has already been fixed in the source tree, and the fix will be included in the next version of GNU make. That version has not been released yet. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make: *** virtual memory exhausted. Stop.
%% Fabio Alemagna [EMAIL PROTECTED] writes: fa On Mon, 23 Jun 2003, Paul D. Smith wrote: It has already been fixed in the source tree, and the fix will be included in the next version of GNU make. That version has not been released yet. fa Yeah, I discovered that by downloading the CVS version. When is fa the next make release to be expected? Sometime, before too long. I'm trying to get the MINGW and OS/2 support integrated for this release. fa Also, do you have any figures on the $(eval) performances and its fa use in large projects? $(eval) makes things really easy and fa neater, however I'm quite worried about the memory usage of make fa in such cases and its performaces. Has any test been done fa regarding this? Not by me. I don't have a large enough system based on $(eval ...) at the moment to do this sort of testing. Actually I've never run any kind of performance testing on GNU make at all (except for a few cases with _really_ egregiously bad performance characteristics), although others have and sent me some results. Barring bugs, though, I don't see any reason why $(eval ...) should be any more memory or performance intensive than include. It's all the same code. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make: *** virtual memory exhausted. Stop.
%% Fabio Alemagna [EMAIL PROTECTED] writes: fa Ok. Do you know if it still compiles on AmigaOS with ixemul (the fa posix layer)? Well, I guess I can just try and see... No one has reported that it doesn't, but I'm not sure if anyone has tried in a while. I don't have an Amiga system so I can't try it myself. Barring bugs, though, I don't see any reason why $(eval ...) should be any more memory or performance intensive than include. It's all the same code. fa Ok, then the question translates into this one: how big can a BIG fa make file be? I mean, I'm going to use one big makefile for a fa large project (AROS, http://www.aros.org/), switching from the fa current build system which uses a lot of different tools and about fa 600 makefiles whose average size is of 212 lines: now, do you have fa any rough idea on whether make will consume a lot of memory and on fa whether it will be slow? Not really. I don't believe it will (again, barring bugs--and I'm not aware of any right now), but I've not done any real measurements. All the major internal structures of GNU make use open hash tables, so adding lots of targets, etc. should not result in a significant slowdown. As far as I'm aware, for example, there are no lookups or anything that are O(n) or worse. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make: *** virtual memory exhausted. Stop.
%% Fabio Alemagna [EMAIL PROTECTED] writes: fa The first issue, is that even if it was cross compiling, it tried fa to use the host's 'ar' command. I solved that by invoking fa m68k-amigaos-ar by hand and letting make run again, however that fa should be fixed at the source. If anything needs to be fixed here, it would be automake or possibly autoconf. However, my understanding of autoconf is that it's up to the developer to specify the cross tools. How did it find the cross compiler? Didn't you have to set CC when you ran configure? You would also have to specify AR as well. fa The other problem is that in signame.c it checks whether fa SYS_SIGLIST_DECLARED is defined, however in config.h fa HAVE_DECL_SYS_SIGLIST is used (and defined, if that has to be the fa case), which created problems because signame.c defines fa sys_siglist[NSIG] and the standard includes declare sys_siglist[], fa creating an obvious conflict. Again, I fixed this by hand in fa config.h, defining SYS_SIGLIST_DECLARED. Both issues don't seem to fa be dependent on AmigaOS, they just show up in that particular fa configuration. I'll look at this one. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make: *** virtual memory exhausted. Stop.
%% Fabio Alemagna [EMAIL PROTECTED] writes: fa I specified --host=m68k-amigaos, and configure added that prefix fa to all the tool's names, except, apparently, ar. Weird. Both that it added that prefix to some, and that it didn't add it to all. This is an autoconf issue. fa Or perhaps ar is used by hand in that makefile, I haven't checked. If so, it's an automake issue (I assume you're talking about the makefile in glob?)--there is no direct reference to ar in the glob/Makefile.am. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: error on making
%% Bruno [EMAIL PROTECTED] writes: b if im doing anything wrong, please tell me... Nothing except asking on the wrong list: your problems are related to the libraries/headers/etc. installed on your system and have nothing to do with GNU make. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: build.sh.in use of @REMOTE@ in make 3.80.0
%% Parkes, Lloyd [EMAIL PROTECTED] writes: pl build.sh.in uses a replacement variable called @REMOTE@ to select pl which of remote-*.c should be used. This seems to be obsolete with pl Makefile.in using @USE_CUSTOMS_FALSE@ and @USE_CUSTOMS_TRUE@ pl instead. Hi; this bug has been fixed in the source and the fix will be available in the next release (see bug #1536 at the Savannah site). -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: problems with $(eval include...)
There are a couple of bugs in the $(eval ...) memory handling which might be related to this. I suggest you first either build the latest CVS code or, if you don't have the infrastructure for that (building from CVS requires that you have autoconf, automake, etc. installed already--if you don't have a Linux box, where these things are packaged for you, that can be a lot of work), you can get patches to 3.80 code for these fixes. The patches are attached to the (closed) bug reports; visit the GNU make site at Savannah: http://savannah.gnu.org/projects/make and go to the bug tracking page, then pick the Fixed in Release report, then choose CVS as the release. This will show you all the bugs that have been fixed in CVS but not released yet. There are a few about $(eval ...). -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: problems with $(eval include...)
%% Fabio Alemagna [EMAIL PROTECTED] writes: fa This is unacceptable for VERY large projects with lots of modules fa and .c files belonging to those modules: say I want to build fa module A and B only, which don't depend on any other module; since fa I include ALL .d files for ALL modules and ALL .c files anyway, it fa doesn't matter how many modules I want to build, ALL .c files from fa ALL modules will be checked anyway, which is wasteful. As pointed out before, if you do the dependency generation the way automake does it (as described on my web site) you won't have any of these problems. fa My solution (if only it worked) is to include the .d files for a fa given module ONLY when that module is about to be built, which is fa right after the module's rule is run, and right before the .o fa rules are run. Eh? I don't think this will work, or else I'm misunderstanding what you're saying. In make, a target's prerequisites are always built _BEFORE_ that command script is invoked. So, the $(eval ...) in the module script will not be invoked until after all the .o rules are run (if the module depends on the .o's). fa The other solution would be to have make let you define other ways fa than timestamps checks to see whether a target needs to be rebuilt fa or not: if for example I could write prerequisites which expanded fa macros only when the target were invoked, then I could write fa macros which expanded to an empty target if the file needed to be fa built for some reasons - thus leading the target to be rebuilt - fa and to nothing if the target doesn't need to be rebuilt. This fa would be a very useful feature, imho. It, I think, would just fa require to define a new syntax for this special macro, like for fa example $@(macro): $@ would not be usable in a prerequisite list fa anyway, so using it like that is perfectly possible, I think. I think you need to step back and look at the problem space again. Working with an alternative method for dependency generation is, to me, a much simpler and more understandable way to go than something like the above. Nevertheless, it has been requested before that customizable up-to-date? queries be allowed. If such a thing were to happen it would definitely not happen until after the integration of a scripting language with GNU make (Guile; this is on the TODO list as well) and it would be done using that; you could override the default up-to-date? query by supplying some kind of Guile script or something. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: problems with $(eval include...)
%% Fabio Alemagna [EMAIL PROTECTED] writes: fa On Fri, 27 Jun 2003, Paul D. Smith wrote: As pointed out before, if you do the dependency generation the way automake does it (as described on my web site) you won't have any of these problems. fa automake uses recursive makefiles, which is something I want to fa avoid. I wasn't suggesting automake in total, I was suggesting their dependency generation style only... this is basically what's described on my website. fa First of all, say I want to build the executable exe, which depends on fa obj1.o, obj2.o and obj3.o: fa exe: obj1.o obj2.o obj3.o fa Now, I'd want to include the dependency files for the various fa obj?.o, however I want to include them only when exe is about to fa be built. This is what I can do (sometimes works, sometimes fa doesn't): fa exe: exe-deps obj1.o obj2.o obj3.o fa exe-deps: fa $(eval -include obj1.d obj2.d obj3.d) This is not reliable. The instant you want to start allowing parallel builds, which are critical for today's software builds and for taking full advantage of today's hardware, your method is no longer guaranteed to work. fa This, as said, works, but it has bugs which don't allow it to be fa really usable. I thought you sent me an email saying that using the CVS source, it worked? That's how I read it; if it still doesn't work with the CVS code please let me know and/or file a bug. I think you need to step back and look at the problem space again. Working with an alternative method for dependency generation is, to me, a much simpler and more understandable way to go than something like the above. fa I'm going away from that way of doing dependencies, I certainly fa don't want to go back to it. Anyway, I'm pointing out a bug which fa needs to be solved anyway. I agree the core dump needs to be solved (if it's not already in CVS). However, I'm not so sure I agree that the method your using would be supported. I don't know that it wouldn't be, but I'm not at all prepared to say right now that using $(eval ...) inside a command script to enhance or modify make's internal dependency graph by adding more prerequisites, would work. Make carries a lot of internal state during its walk of the dependency graph, like where it is, what it's looking for, etc., and if you go modifying the structure of that graph while make is in the middle of resolving it I can't say for sure that everything will work properly. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: problems with $(eval include...)
%% Fabio Alemagna [EMAIL PROTECTED] writes: fa so this might be used as fall-back solution in case the make's bug fa doesn't get solved. In an earlier email from you you said you were using the CVS code and it worked (or words to that effect, I don't have the email any longer). Can you please clarify whether or not this core dump still exists in the CVS code and, if so, give details and/or file a bug report? Thanks! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: problems with $(eval include...)
%% Fabio Alemagna [EMAIL PROTECTED] writes: fa On Fri, 27 Jun 2003, Paul D. Smith wrote: fa automake uses recursive makefiles, which is something I want to fa avoid. I wasn't suggesting automake in total, I was suggesting their dependency generation style only... this is basically what's described on my website. fa hum... I must have got something wrong, then... Please, clarify fa this: does that method allow for proper handling of autogenerated fa files AND the usage of one single big makefile as opposed to fa multiple recursive makefiles? Again, I'm not suggesting you use automake. Whether you can do non-recursive builds using automake or not, I don't know. I'm talking _only_ about the dependency generation, which is completely unrelated to recursion. The instant you want to start allowing parallel builds, which are critical for today's software builds and for taking full advantage of today's hardware, your method is no longer guaranteed to work. fa Isn't there any way to tell make to build exe-deps before any of fa the other prerequisites of exe, even with -jn, n 1? Sure. You specify that the other prerequisites also depend on exe-deps: foo: exe-deps foo.o bar.o baz.o foo.o bar.o baz.o: exe-deps I thought you sent me an email saying that using the CVS source, it worked? fa It works only in some situations, whilst in others it fa segfaults. I'm not quite sure which are those situations yet. I fa have to investigate further. There's one common behaviour, fa though: in any case, even if there's no segfault, if the file fa doesn't exist make doesn't invoke the rule to generate it, as it fa should instead do. OK, please file a report as soon as you finish investigating. fa I'm sure I hit an hidden and not foreseen feature of $(eval), fa which should be supported though, so to be consistent with the fa general $(eval) semantics. At this time I'm not prepared to agree with your comment which should be supported. I'll reserve judgment on that until I better understand the problem and issues involved. I will agree the core dump is unacceptable behavior, of course. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Bug report solution: make-3.80: Win32 linking error.
%% Regarding Bug report solution: make-3.80: Win32 linking error.; you %% wrote: n It seems that script for assembling binaries of make-3.80 GNU make n utility for Win32 platform is incorrect. This problem has been reported and fixed, and the fix will be available in the next version of GNU make. Patches are available attached to the bug reports at http://savannah.gnu.org/projects/make -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: problems with $(eval include...)
%% Peter A. Kerzum [EMAIL PROTECTED] writes: pak Yeah, Fabio's way seem quite clean and pretty. I agree that eval pak should support include. $(eval ...) does support include. What Fabio wants to do is declare new prerequisites inside of a command script. That may not be possible in a reliable way. Make proceeds in two very distinct phases: in the first phase make reads in all the makefiles and constructs an internal dependency graph, and in the second phase make walks that dependency graph and rebuilds target that it deems out of date. Make was not written in a way that expects the dependency graph to be modified during the second phase: until $(eval ...) that was simply impossible. I'm not prepared at this time to say that it _should_ be possible. I won't be prepared to decide that until after I understand the reasons why it doesn't work now. There are all kinds of potential problems; for example it often happens that more than one prerequisite depends on the same target: what if the target that you're modifying (by adding prerequisites) is already built? Should make somehow figure that out and reconsider the target? If not, won't that lead to lots of confusion on the part of the user? If I decide that this behavior is not valid then I'll add some code to GNU make disallowing it with an error, so that we won't get core dumps in GNU make any longer. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Bad example
%% Clock [EMAIL PROTECTED] writes: c You are using a call $(MAKE) -C $ in the info make (3.79.1). c There shall be $(MAKE) -C $@ instead probably. This doesn't work. You don't say where in the manual you found this, but I believe it's already been fixed in the next version of the manual (3.80). -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Path to binary in --help or --version
%% J. Grant [EMAIL PROTECTED] writes: jg One problem I have frequently come across is having multiple jg incompatible versions of make installed. jg This would be solved if the path was visible. Could the path to jg the binary being run be added to the --help or --version output jg please? jg Alternatively if I submit a patch to add this will it be accepted? I'm not sure how you imagine this would work, or what use it would be. If you run --version don't you already know that you have different versions? As for the other, make doesn't know its own path. For example, make doesn't have the path used during the configure encoded anywhere in its executable: you can copy the make executable anywhere and it will still work fine. It has no external files etc. that it needs to find. The only thing it could do would be to emulate the way the system searches the PATH environment variable and find the first matching binary. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: probable bug-make
%% Giancarlo Bassi [EMAIL PROTECTED] writes: gb g++: Internal error: Terminated (program cc1plus) gb Please submit a full bug report. gb See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. gb make[3]: *** [kmovistodoc.o] Error 1 Whyever would you think there is a bug in make? If you mean because of the last line, make is simply telling you that the program it invoked (g++) failed with an error code of 1. There's nothing wrong with that. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: include directive misbehaviour?
%% Samium Gromoff [EMAIL PROTECTED] writes: sg In the case when the Makefile include`s an inexisting file it sg generates an error message. This is an expected behaviour. sg Although in the cases when a rule exists to create the file in sg question, wouldn`t it be more expectable (and clean) for make to sg suppress the error messages? This has been reported as bug #102 in Savannah. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: bug with avview
%% andrea [EMAIL PROTECTED] writes: a I'm using Linux from 6 months, i'd like to install avview for see a immagine and movie on TV. My noteboke has jack yellow for connect a with TV (connection RCA) Whend a try to install avview0.12.0tar.gz a there is a BUG whend i do MAKE (not found makefile). a Indications was to write at this mail This list is for bugs or help with GNU make. Your problem is not related to make, it's related to the package you're trying to build. You should contact the development list for that package (avview). However, if this is an open source package then I suggest you look for and read the files README and/or INSTALL in the source tree, and follow the directions there. Often open source packages require you to run a configure step before you can run make; the configure step will build the makefile for you. Good luck! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: CURDIR not working properly on solaris
%% Luu, Jose [EMAIL PROTECTED] writes: lj It seems that the variable CURDIR does not work on solaris, making lj it impossible to use it as inside recursive makefiles (as it keeps lj the same value even if make is invoked with -C lj This is make-3.80 on solaris 8 , I have tried to recompile with lj various compilers: lj Sun 4.2 lj Sun 6U2 lj Gcc 2.95 lj The make package available on sunfreeware also exhibits this lj behavior. Please always remember to include the version of GNU make you're using. Curdir can't really fail: it just gets set to the working directory. So there must be something about your shell setup or environment or makefiles that's causing the problem. Please create a very small example makefile that still exhibits the problem, then send it along with a sample invocation, the output you got, and what you expected to get. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: help needed
%% Dayakar.S [EMAIL PROTECTED] writes: ds Respected Sir / Madam ds I Have problem in configuring Cygwin with Make file utility ,when I type ds make it gives error command not found. ds Please suggest me some solution to resolve this issue First, problems with Windows and GNU make are best addressed to the [EMAIL PROTECTED] mailing list. Second, note that the Cygwin version of GNU make is not generally managed by these groups: it's slightly modified from the standard version so you should ask about it on a Cygwin list or group. Third, the above is not enough information for anyone to help: does it give the error command not found because it can't find make? Or does it start make, but then when make tries to run a command it says command not found? What command is not found? Generally this means that whatever command you tried to run could not be found in any directory on your Path variable. When you talk to the Cygwin people about this please include the exact command you typed and the exact error message you received. Good luck! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Make / Win 98 question
%% Steve Thomson [EMAIL PROTECTED] writes: st sde-gcc: Internal compiler error: program cc1 got fatal signal 11 This error is being generated from GCC (the compiler) and as such has nothing to do with GNU make--and so this is the wrong mailing list to ask questions about it. Good luck! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: bug: expand.c:489:allocated_variable_append: Assertion'current_variable_set_list-next != 0' failed
I believe this has been fixed in version 3.80. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: gmake-3.80 bug?
This is a know problem. See bug # 1516 on Savannah. There's a patch there too. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Feature request: output idea
%% Full Decent [EMAIL PROTECTED] writes: fd I think it would be amazing if there was an optional output mode fd for make that would simply have a console (curses) progress bar fd with the name of the target and the status of its compilation fd like: The names of which target? Remember make is fully recursive. I guess you mean any target that was specified on the command line. But it's not possible to be created accurately because make never knows how many files it will ultimately compile until it's done: make walks the dependency graph and as it goes, it invokes compiles. It doesn't walk the entire graph first, so it has no idea how much work is needed until it's done. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: makefile --- dependencies with blanks in the path
%% HENNINGS FRANK [EMAIL PROTECTED] writes: hf We have some problems with executing make on our VB6 projects hf because there are spaces in the path names of included hf BAS-Files. Is there any chance except from changing all the VBPs hf (about 500)? You should direct Windows-related questions to the [EMAIL PROTECTED] mailing list; however, there is no good way to work with pathnames containing spaces in GNU make. If only the path has spaces you can play games like create a virtual drive letter for the path and use that instead. If the filenames have spaces you're kind of out of luck. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Hash.obj missing in NMakefile and build_w32.bat
%% Marcin Wiatr [EMAIL PROTECTED] writes: mw I tried to build GNU make 3.80 on WinXP and MSVC++ 6.0 but linker mw refused to produce output. I found that hash.obj was missing in mw NMakefile, so functions implemented in that file wasn't found by mw linker. This problem was reported a while ago and fixed in the source. Thanks for the report! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: PLEASE HELP ME
%% $AUTTF(B [EMAIL PROTECTED] writes: (B (B n After this, I use equipment read the firmware from the (B n S75_V020_OPT_MCU, then compare it with I just use the (B n source files built one. I find they are different. I don't known why? (B (BWe can't help you with this, it has nothing to do with GNU make. (B (B n The second question is whether I can the use this make.exe to build (B n it.By the way I don't known the version number of make.exe. (B (BYou can find the version of GNU make by running: (B (B make --version (B (B n The third question is What is GUN? (B (BCheck out http://www.gnu.org (B (B-- (B--- (B Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: (B http://www.gnu.org http://make.paulandlesley.org (B "Please remain calm...I may be mad, but I am a professional." --Mad Scientist (B (B (B___ (BBug-make mailing list (B[EMAIL PROTECTED] (Bhttp://mail.gnu.org/mailman/listinfo/bug-make
Re: two bugs in construct_command_argv_internal() (job.c, latest CVS)
Thanks for the updates. I'm hoping to rework that entire section because the current behavior doesn't conform to the POSIX definition of make, but if I don't manage to get it done for the next release I'll apply these fixes. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Bugs in build.sh script
%% Wirawan Purwanto [EMAIL PROTECTED] writes: wp * build.sh.in:33: The definition @REMOTE@ is no longer properly wp maintained. Why is this? This is a known bug in 3.80 which has already been fixed in the source. wp * build.sh.in:32: The definition of @LIBOBJS@ here was replaced by wp loadavg$U.o (including the literal '$U' substring there!) I guess wp this is what happens: wp - IRIX does not have the getloadavg() function, so wp - autoconf would include the make's version of it, and wp - LIBOBJS is set to 'getloadavg$U.o' (with the literal '$U' there, wp I saw it in the config.status file!) wp - this substitution was transferred to build.sh, and ... voila, wp the bug appears. Hmm, I'll have to look at this one more carefully. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Asking Help
Sorry, I don't think we can help you. First, the FSF doesn't provide binary copies of any of their software, only the source, so if you got a binary it wasn't from us. If it was a part of Cygwin you need to ask them about it; if it was part of MINGW or similar you need to ask them about it. If you built it yourself from source obtained from the FSF site (www.gnu.org or ftp.gnu.org) then you will have better luck asking about it on the [EMAIL PROTECTED] list, which is where the Windows users generally hang out. Please be sure to provide the version of GNU make you're using plus any information you can provide about the makefile you're using and exactly what error you're getting. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: building make on solaris 2.8
%% Michael [EMAIL PROTECTED] writes: m in build.sh, the symbol @REMOTE@ is not resolved. The build process m crumps when it trys to compile [EMAIL PROTECTED] This is a known bug and has been fixed in the source. You can replace @REMOTE@ with stub to get it compiling in the version you have. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
RE: --no-silent --no-quiet style option
%% [EMAIL PROTECTED] writes: j Yes, I am aware it is on the man page, I'm not talking about the man page, I'm talking about the GNU make user's manual. You can't learn everything you need to know about GNU make by looking at the man page. For one thing, it's quite out of date. j How do you feel about adding a --no-silent, --no-quiet option to j overrule all .SILENT and @ commands in a Makefile? I can take a j look at writing this patch, if it will be accepted. I'm not interested in adding lots of individual new options like this. However, I am going to be adding some kind of verbosity control option that allows the user to more specifically select the kind of output that is desired. Probably it will end up looking more like the current debug level output option rather than lots of individual options. Obviously any command-line option would take precedence over flags in the makefile. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: /usr/local/ etc...
%% Mary Felkin [EMAIL PROTECTED] writes: mf I don't know if it's a bug or not, but when I use make it keeps mf tying to write things into /usr/local/something into which I mf don't have write permission. So, it fails. GNU make never tries to write anything anywhere. It doesn't even use any temporary files. If things are being written to /usr/local/something when you run make, then the makefiles you're using must be doing it. This is not something that is a problem with GNU make, just as a bug in some source code is not the fault of the compiler. I suggest you read the documentation that comes with the software you're trying to build to see how to convince it to write its files somewhere other than /usr/local. Good luck! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: GNU make integration through an IDE
the matching ifdef for an endif, etc. are all very useful. I am saying that I think an IDE can help people edit makefiles but I don't think that an IDE can build a good makefile _for_ you, so IDE features like putting down templates, etc. I just don't think are that useful. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: GNU make integration through an IDE
infrastructure as practical including the editor help, the markup of make output to find errors, etc. etc. BUT! in no way should that mode constrain what I put into my makefile. In that mode every decision of the IDE should be lenient; it should not force me to do anything. If the IDE doesn't recognize what I'm doing it should shrug and just do its best to interpret it, but let me do it. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Static pattern usage
%% Sam Ravnborg [EMAIL PROTECTED] writes: sr deps_foo.o := foo.h sr foo.o : % : $(deps_%) bar.h FORCE sr @echo $^ sr When executed I expected it to print: sr foo.h bar.h FORCE sr But it only prints bar.h FORCE Right. sr Is it coorect behaviour that make does not expand the variable sr $(deps_foo.o)? Yes, because that's not the variable you asked to expand. You asked it to expand the variable $(deps_%). sr % is equal to foo.o in the above example, No it isn't; or at least it isn't when the prerequisites line is expanded. The entire target definition line, including the prerequisites, is expanded _BEFORE_ the line is parsed. When expansion happens the pattern substitution hasn't occurred yet, so you're expanding a variable named deps_% which doesn't exist, and so it expands to nothing. See the GNU make manual for a precise description of when expansion happens in various constructs. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Static pattern usage
%% Peter A. Kerzum [EMAIL PROTECTED] writes: pak I used this trick with rather complex define/eval constructs It pak really works but sometimes gives me 'virtual memory exhaused' If pak you (Sam) are interested, I can give you precise example. If pak only I figured out how to work out this (endless loop?) my build pak system would be perfect =) Apply the patch attached to bug #1517 at http://savannah.gnu.org/projects/make -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Unable to build win32 GNU make-3.80
%% [EMAIL PROTECTED] writes: j 3. This version of GNU make would not build, using MSVC6, or MSVC j.Net C compiler, the batch file, or the nmake NMakefile methods. See bug # 1687 on Savannah (http://savannah.gnu.org/projects/make) -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: a bug in file NMakefile
%% Tian Yu [EMAIL PROTECTED] writes: ty Perhaps it has been reported that hash.c should be refered ty in NMakefile. Yes; this has been fixed in the source. Thanks for the report! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Possible bug with make: make + ccppc + STDERR
Hi Chris; Unfortunately the Cygwin version of GNU make is not identical to what's distributed by the FSF, and only the FSF version is really supported on this list. I suggest you contact a Cygwin developer's list or site and see if they have any ideas there. I've not seen anything like this with vanilla GNU make, but maybe someone at [EMAIL PROTECTED], where the Windows users mostly hang out, has. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Missing feature gnumake?
Please include your problem report in plain text in your mail; if you want to include a tar.gz attachment with sample code that's fine, but at least the problem description should be in plaintext. It's a big pain to unpack the attachment before we even have a clue what the problem is. Anyway, you're missing this important note in the GNU make manual describing how target-specific variables work: [...] As with automatic variables, these values are only available within the context of a target's command script (and in other target-specific assignments). So, your lines like this: sd: O = objs $(O)/sdlcmain.o: $(H)/sdlcmain.h sdlcmain.c will not do what you expect: the target-specific value of $(O) is not in effect during the parsing of the target or prerequisites, it's only in effect during the command script. I'm quite sure that they have this same limitation in Solaris make, as well. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: hp-ux 11.23 IPF
%% Kinney, Joe [EMAIL PROTECTED] writes: kj We are in the preparation stages of upgrading our itanium server kj from hp-ux 11.22 to hp-ux 11.23. Upon review of your website, I kj noticed there are no gmake-3.80 downloads for hp-ux 11.23 IPF. Is kj the software available for 11.23? If so, where can I find it? The FSF does not provide binary downloads of any of its products. If you want to purchase a CD containing prebuilt binaries you can look here: https://agia.fsf.org/ I don't know if they have the binaries you're looking for. On the FSF site you can download the complete source, including source for the manual, along with complete instructions on how you can build the program yourself (all you need is a C compiler). This is what open source is all about... Good luck! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make signal text descriptions
%% J. Grant [EMAIL PROTECTED] writes: jg ok, I've cc [EMAIL PROTECTED], so maybe someone can tell me if jg signal numbers are decoded. Would you include this internally? or jg use a lib etc? We use the system service to translate the code if the system provides it (many UNIX systems provide strsignal() for example). If not we have a predefined set of signals we translate, but if the signal is not a member of that predefined list it's not translated. In the example you give here, for example, the invoked program exited with a -1 exit code, which is not a valid errno value. jg Is there any reason this is printed as unsigned char then? Would jg not -1 be more appropriate if that was what it was originally? Because the POSIX standard defines the exit code of an application to be an 8-bit value, not a signed integer. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: GNU tasklist item - is it still relevant?
%% toby cabot [EMAIL PROTECTED] writes: tc The item reads: Add features to GNU Make to record the precise rule tc with which each file was last recompiled; then recompile any file if tc its rule in the makefile has changed. tc I'm inclined to think that this item is so old that it's probably no tc longer needed but if I hear otherwise I'll be glad to keep it on the tc list. This is still a valid task someone could work on. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Lucent nmake feature support
%% J. Grant [EMAIL PROTECTED] writes: jg I have been reading about Lucent nmake jg (http://www.bell-labs.com/project/nmake/). It looks interesting, jg they use a different rule format, and include a preprocessor. jg There is a comparison to GNU make jg (http://www.bell-labs.com/project/nmake/faq/gmake.html). I was jg wondering if GNU make planned to add some similar features to jg Lucent nmake? Did you have some specific feature in mind? Based on the comparison the only significant feature difference I see is that nmake is stateful while GNU make is not stateful. Adding state to GNU make has been (and is still) on the TODO list, but it hasn't been done yet. There is no specific timeframe for this feature. Note that the comparison you cite is based on GNU make 3.75 (with a few 3.76 features thrown in). GNU make is now up to 3.80 and has a number of enhanced features. Also note that the comparison is not 100% accurate: for example GNU make has had support for distributed builds for a long time (at least on UNIX platforms), but it requires linking in a 3rd party library (free, but not provided with GNU make). -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Incident 65183 Is there any problem with GNU Make with v7.5r2
%% Agrawal.Manisha [EMAIL PROTECTED] writes: am I am working as a Software Engineer in Delphi Automotive Sysytems. am I was using the Make utility (version 3.79.1) for a build process am in a project. I faced some problems in invoking the Tasking am compiler with certain flags. The mail below describes the am problem. It looks like there is some problem with this version. am Please look into it and help me to resolve this issue. Please always specify what platform you're using GNU make on. I assume some sort of DOS or Windows platform from the filename (make.exe). In that case you should probably ask your question on the [EMAIL PROTECTED] mailing list. Also, please specify whether your version of GNU make is from Cygwin, or you built it yourself. If it's from Cygwin, we don't support that version directly so if it's a non-general make problem (which this appears to be) you should ask on the Cygwin lists. If you built it yourself please note how it was built (what shell it uses, etc.) I can't say that this: am I can reproduce the problem over here now, with your make.exe you am sent me. After some investigation, it turns out that when I am specify a compiler option larger than 14 characters, the error -1 am shows up. If the option is 13 or 14 characters wide, I get error am 11, and when the option is 12 characters or less the compiler is am invoced correctly. This is completely independend of the option am itself, only the number of characters matters. am Well, this is definitely a bug in your make utility and has little am to do with the compiler option itself. Please report this bug to am [EMAIL PROTECTED] As a workaround, you can use make.exe version am 3.78.1, see the attachment. rings any bells with me. Is it true for all commands, or just when their tool is invoked (that is, if the rule is echo 123456789012345 or similar, does it fail?) Remember please post this all to the [EMAIL PROTECTED] list, do not email it to me directly. I don't even own a Windows box and cannot help you. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: Error to installed
This is a problem in your code. It has nothing to do with GNU make. Offhand I'd say someone emailed you that file and either when they sent it or when you saved it, it got corrupted; it looks like there are a bunch of extra backslashes inserted into the file. Anyway, as I say, this has nothing to do with GNU make. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: calling $(SHELL) with make-3.80 on cygwin
%% Roland Illig [EMAIL PROTECTED] writes: ri I noticed a subtle change from make-3.79 to 3.80 on Win32: The ri shell to process the commands in the Makefile is called as Is this the version of make provided with Cygwin? Or did you get a copy from ftp.gnu.org and build that yourself? If it's the Cygwin GNU make, please ask about it on the Cygwin mailing lists: that version is somewhat different than the base version, which is what is supported by these lists. If you are using the base GNU make from ftp.gnu.org, you should consider asking your question on the [EMAIL PROTECTED] mailing list. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: make error
Please check the GNU make manual for information on make syntax. In particular, every shell command line in a make rule must begin with a TAB character (not spaces, but a TAB). -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: ifneq gnumake bug
%% Jeremy Broughton [EMAIL PROTECTED] writes: jb I have the following sample makefile, which seems to produce the jb following erroneous output, using the cygwin version 1.3.10: The output is not erroneous. jb target1.txt target2.txt : jb ifneq $^ jb @echo $^ jb else jb @echo this doesn't seem empty to me: $^ jb endif Someone else gave the answer: I'll elaborate a little bit. It's critically important to grasp the difference between make constructs, like ifeq etc., and command line constructs, like the @echo ... lines. Make constructs are evaluated as the makefile is read in. Command line constructs are evaluated when the command is about to be run. Automatic variables, like $^, are only set in the context of the command scripts. So, when the ifneq is evaluated, when the makefile is being read in, the value of $^ is the empty string. Later on, when make is done reading the makefiles, starts to run the rules, and decides to rebuild target1.txt, it will set $^ to the value of the prerequisite then evaluate the command script, so you get the output you see. jb Do you know if this is fixed in a newer cygwin release? It will never be fixed, because it is not a bug. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: [patch] README.W32.template
%% J. Grant [EMAIL PROTECTED] writes: jg Is there a reason why template was appended to this files name jg in CVS? Because during the creation of the tarball releases the file is processed to replace tokens for the release #, etc. and added as just README.W32 in the distribution. I will add some text along the lines of what you've suggested to that README. Thanks! -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: [patch] README.W32.template
%% J. Grant [EMAIL PROTECTED] writes: jg Ah, ok. Where is the tarball release creation script please? There isn't one: it's part of the makefile. See the README.cvs file in the GNU make CVS archive for instructions on how to build a tarball from the CVS archive. Note that this can't be done on Windows, only on UNIX. Well, anyway, I've never done it on Windows and I've never heard of anyone who has. The tools required to build from the CVS archive (GNU m4, Perl, GNU autoconf, GNU automake, and GNU gettext, at least) are easy to install on UNIX systems but I don't know if they'll install properly on Windows. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: BUG in 3.80 (virtual memory exhausted, xrealloc, variable_buffer_output)
This bug has already been reported and fixed in the source, and the fix will be included with the next release. Look here for the bug report; there's a patch attached to it: https://savannah.gnu.org/bugs/index.php?func=detailitemitem_id=1517 -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
Re: trouble with a trivial makefile
It works fine on both Linux and Solaris. I suggest asking on the [EMAIL PROTECTED] list. If people can't reproduce it there you should try it with the vanilla 3.80 make version; it might be a problem with the Cygwin version of GNU make. -- --- Paul D. Smith [EMAIL PROTECTED] Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org Please remain calm...I may be mad, but I am a professional. --Mad Scientist ___ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
