Re: automatic linking links too many files
Hello, The intent of the default rule is to make it easy to handle object files or libs I think. So it makes sense that for you the file is assumed to be an object file and is passed to the link line. For anything other than very simple cases you will make your own rules. 1. Do you actually want to make a dependancy on a file/files like textfile? I think in that case it would be easiest to define your own rule. You may have a point that there is something unexpected in make. I don't see what rule would match textfile and treat it as an object file. But I'm not sure. 2. If you just want to use default rule and have one c file yhen you want maybe a very simple makefile containing: all: executable $ make -f makefile.all g++ executable.cpp -o executable 3. If you have more than one c file you add a dependancy on the other c files object files: executable: othercfile.o $ make -f makefile.other g++-c -o othercfile.o othercfile.cpp g++ executable.cpp othercfile.o -o executable 4. I notice that adding a static library doesn't get picked up by a default rule. I'm not going to dig further into this. My syntax for libs might be wrong, makefile.lib: executable: othercfile.o staticlibrary.a staticlibrary.a: yetanothercfile.o $ make -f makefile.lib g++-c -o othercfile.o othercfile.cpp g++-c -o yetanothercfile.o yetanothercfile.cpp g++ executable.cpp othercfile.o staticlibrary.a -o executable g++: staticlibrary.a: No such file or directory make: *** [executable] Error 1 Just thinking a bit out loud, hope this is of some use to you also. James. Federico Poloni wrote: `Makefile' contains: executable: textfile the output of `make' is g++ executable.cpp textfile -o executable ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
[bug #23273] Please include xkcd easteregg
Follow-up Comment #4, bug #23273 (project make): patch attached Posted this already on make mailing list, sorry for duplicate info, was not sure about adding patch here. As simple as possible I think. Don't call to fatal so that easter egg error text is clear of adornment. Exits using die(2) as fatal does. Doesn't trigger action if -k (continue on error) is specified. There's already a strcmp() call in remake.c (strncmp used for this patch). There's already a getuid() call in misc.c, I think for all platforms. Tested on linux, solaris and cygwin. $ ./make the cat some tea make: *** No rule to make target `the'. Stop. $ ./make me a sandwich What? Make it yourself. $ sudo ./make me a sandwich Okay. $ ./make -k me a sandwich make: *** No rule to make target `me'. make: *** No rule to make target `a'. make: *** No rule to make target `sandwich'. $ ./make -f Makefile.me me a sandwich make: Nothing to be done for `me'. make: *** No rule to make target `a'. Stop. $ ./make me a cup of tea please What? Make it yourself. (file #16091) ___ Additional Item Attachment: File name: make_me_some_tea.patch Size:0 KB ___ Reply to this item at: http://savannah.gnu.org/bugs/?23273 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: [bug #23273] Please include xkcd easteregg
Sorry I'm not sure about where to submit a patch.
http://savannah.gnu.org/projects/make/ ?
I keep on thinking about this since I saw your request Joachim!
Now maybe I can lay it to rest whether this is used or not.
As simple as possible I think.
Don't call to fatal so that easter egg error text is clear of adornment.
Exits using die(2) as fatal does.
Doesn't trigger action if -k (continue on error) is specified.
There's already a strcmp() call in remake.c (strncmp used for this patch).
There's already a getuid() call in misc.c, I think for all platforms.
Tested on linux, solaris and cygwin.
patch also attached
$ cat make_me_some_tea.patch
Index: remake.c
===
RCS file: /sources/make/make/remake.c,v
retrieving revision 1.137
diff -u -r1.137 remake.c
--- remake.c5 Nov 2007 14:15:20 - 1.137
+++ remake.c9 Jul 2008 16:58:29 -
@@ -353,6 +353,13 @@
if (!keep_going_flag)
{
+ // bug #23273: http://xkcd.com/149/
+ if (!strncmp (me, file-name, 3))
+ if (getuid())
+ fputs (What? Make it yourself.\n, stderr), die (2);
+else
+ fputs (Okay.\n, stderr), die (2);
+
if (file-parent == 0)
fatal (NILF, msg_noparent, , file-name, );
$ ./make the cat some tea
make: *** No rule to make target `the'. Stop.
$ ./make me a sandwich
What? Make it yourself.
$ sudo ./make me a sandwich
Okay.
$ ./make -k me a sandwich
make: *** No rule to make target `me'.
make: *** No rule to make target `a'.
make: *** No rule to make target `sandwich'.
$ ./make -f Makefile.me -k me a sandwich
make: Nothing to be done for `me'.
make: *** No rule to make target `a'.
make: Nothing to be done for `sandwich'.
$ ./make -f Makefile.me me a sandwich
make: Nothing to be done for `me'.
make: *** No rule to make target `a'. Stop.
$ ./make me a cup of tea please
What? Make it yourself.
$ make -k me a god
make: *** No rule to make target `me'.
make: *** No rule to make target `a'.
make: *** No rule to make target `god'.
$ su -
[EMAIL PROTECTED] # cd ~yyy/make-3.81
[EMAIL PROTECTED] # ./make me a god
Okay.
[EMAIL PROTECTED] # ./make haste not waste
make: *** No rule to make target `haste'. Stop.
Joachim Breitner wrote:
Follow-up Comment #3, bug #23273 (project make):
Sure, I know how to make this happen on my machine (also by shell aliases
etc.), but that’s not the point of an easter egg. I imagine someone reading
that comic strip, trying it out just for the sake of it and then be really
surprised that it works.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?23273
Index: remake.c
===
RCS file: /sources/make/make/remake.c,v
retrieving revision 1.137
diff -u -r1.137 remake.c
--- remake.c5 Nov 2007 14:15:20 - 1.137
+++ remake.c9 Jul 2008 16:58:29 -
@@ -353,6 +353,13 @@
if (!keep_going_flag)
{
+ // bug #23273: http://xkcd.com/149/
+ if (!strncmp (me, file-name, 3))
+ if (getuid())
+ fputs (What? Make it yourself.\n, stderr), die (2);
+else
+ fputs (Okay.\n, stderr), die (2);
+
if (file-parent == 0)
fatal (NILF, msg_noparent, , file-name, );
___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
Re: Bug: make igores options, switches and targets
Georg-Johann Lay wrote: make clean echo clean clean That proves that your make does accept the command-line target. So it must be the shell or ?? something. Not a problem with make I think. your Makefile and sh -c 'make clean' call works okay within cygwin for me: $ sh -c 'make clean' echo clean clean $ sh --version GNU bash, version 3.1.17(6)-release (i686-pc-cygwin) Copyright (C) 2005 Free Software Foundation, Inc. $ make -v GNU Make 3.81 Is there anything I can do? It is obviously a problem of make and not of sh. Is your make aliased to something else or is it a script ? And if it is invoked from sh is the same make invoked? Could there be any environment difference causing the problem? which make sh -c 'which make' ls -al `which make` alias |grep make sh -c 'alias |grep make' Looking for things like that might be worthwhile. James. e.g. for me: $ alias |grep make alias makerpsgb='nice -6 make STACKS=gb -j 5 21 make.log |tee makeerr.log' alias makerpsiups='nice -6 make STACKS=iups -j 5 21 make.log |tee makeerr.log' alias makerpsrel='nice -6 make BUILD=release -j 5 21 make.log |tee makeerr.log' $ sh -c 'alias |grep make' ** nothing ** ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: EAGAIN in read jobs pipe
Oh dear. Sorry people. I was of course being a bit silly when talking about make -j 16385! Howard Chu wrote: [EMAIL PROTECTED] wrote: Perhaps... On the other hand, if you're using -j 65K, why not just -j? Does you build even have 65K jobs? of course I do not use -j65k ! :-O :-) Very good question. I could be wrong of course, but I in my experience you don't gain any real benefit from going beyond 3-4 jobs per (virtual) core... What's the difference in build time from, say, -j 128 and -j 65385 for you? not much! also a build making more calls to make can result in jfactor * number of make calls jobs So I might regularily use maybe -j 10 (when I know 10 more calls to make are made) On some machines this might be unacceptable and bring them to their knees. On other machines it can work really well. I usually count on 1.5 jobs per core, but obviously the right balance depends on your disk speeds relative to your CPUs... I find that the limiting factor in the speed of builds is disk access. (gcc preprocessing following all header files) So all of the multiple processes spawned are mostly just waiting on disk. So using a parallel build makes optimum use of both cpu disk together. So yes, between 3-4 jobs per core, maybe a little bit more. Of course Your Mile^H^H^H^HKilometerage Will Vary alot with different projects and machines. James. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: EAGAIN in read jobs pipe
Ken Takusagawa wrote: For reasons I haven't completely triaged yet, I've been having my parallel makes die with read jobs pipe: Resource temporarily unavailable. Stop. All memory on machine might be used up (real memory + all swap). e.g. we get this: virtual memory exhausted: Resource temporarily unavailable We have some particularily heavy files at compile time and if machines are busy (memory-wise) or if they are low in memory anyway they frequently hit that error and the build fails. Depending on the machine and build this can happen even if not using any parallelism. I hacked the function new_job in job.c such that if errno==EAGAIN, then we sleep(1) and loop again, and my problem went away. (Essentially adding EAGAIN to EBADF and EINTR as the ignored signals.) :) cool! That seems like a good idea. Rather than scripting to test for successful build and retrying a few times maybe make could do the retry. James. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: EAGAIN in read jobs pipe
Paul Smith wrote: On Tue, 2007-01-09 at 10:32 +, James Coleman wrote: Ken Takusagawa wrote: For reasons I haven't completely triaged yet, I've been having my parallel makes die with read jobs pipe: Resource temporarily unavailable. Stop. All memory on machine might be used up (real memory + all swap). I don't think this can be the case. In a standard POSIX system a buffer is allocated to the pipe when it's created. There's no need to get more memory when writing to or reading from the pipe. Further, GNU make simply writes one byte to the pipe for each possible job, so as long as you're not using -j65536 or something silly like that it's unlikely to be a problem. Yes I'm not sure about the read jobs pipe error. The error I have seen is due to gcc running out of memory. I thought it might be somewhat related. We have some .h and .cpp files generated for ASN1 encode/decode and they are huge and they result in a very large gcc process. :) -j65536 We have sun machines here with 4 multiple cores 8 virtual cores per core (coolthreads). solaris 10 They have their own limitations but you can gmake -jridiculous on them and build is much faster and machine stays responsive (I presume solaris 10 kernel is managing things better than before). http://www.sun.com/servers/coolthreads/t2000/ Thought you might like to know that. Noticed something else. Something else completely pointless! ridiculous must not be 16385 gmake -j 16386; # or above hang gmake -j 16385; # or below fire along rapidly GNU Make 3.80 SunOS 5.10 Generic_118833-03 sun4v sparc SUNW,Sun-Fire-T200 Sun Fire T200 (32 X SPARC 1000MHz) slot 1 has a 8184MB (7.9921875GB) DIMM I'll go back to my corner and be quiet now. James. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: GNU make 3.81rc1 released -- please test.
I definately agree it is a bug fix. (that changes behaviour :) ) Thanks Paul, James. Paul D. Smith wrote: I'll add a note about this as it's a behavior change, even though I consider it a bug fix. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: GNU make 3.81rc1 released -- please test.
libumem on solaris is quite good, you can run it no problem without dbx or the other sun tools. Not quite as good as valgrind I believe though I don't have experience with valgrind. Here's another url with good examples of use of libumem: http://access1.sun.com/techarticles/libumem.html Very easy to turn on (uses sun library interposition) UMEM_DEBUG=default UMEM_LOGGING=transaction LD_PRELOAD=libumem.so.1 make -k -j 4 variants=dyn_dbg --warn-undefined-variables everything You can then use mdb to connect to running process or examine core. James. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
gnu make manual tweak/fix to example used in 8.8 The eval Function
Hello, 8.8 The eval Function has an example of using eval, foreach, ... and I am planning on using something a bit like that myself. The example provided has a two problems and I have a fixed version (tested on GNU Make 3.80 on solaris). You might like to incorporate this fixed version in the manual? Or something like it. I know examples are just that and it's a bit pendantic to get them fully working but you might find this useful. Attached here please find a tgz of dummy c files and working Makefile. (my working makefile does @echo $(CC) etc; touch FileThatWouldBeCreated so it can be tested in dummy mode) Two lines had problems: (see original Makefile and modified one (as in tgz) below) $(1): $$($(1)_OBJ) $$($(1)_LIBS:%=-l%) and $(LINK.o) $^ $(LDLIBS) -o $@ The first makes e.g. -lpriv and -lprotocol dependancies of server or client. Probably not what is intended. So it could simply be replaced with: $(1): $$($(1)_OBJ) Usually making the build dependant on the lib files is not done unless the lib files are also built in the same makefile. But this is what I am doing so a more interesting replacement would be: $(1): $$($(1)_OBJS) $$($(1)_LIBS:%=lib%.a) On the second line the $(LINK.o) looks quite dodgy. Maybe it could be defined but I replaced it with $(CC) -r Okay well, small change, lots of guff from me, Not too sure where the gnu make manual source is so apologies for not submitting in patch format :-7 In the hopes it is slightly useful to someone James. Gnu make manual referred to as is on web here: http://www.gnu.org/software/make/manual/html_chapter/make_8.html#SEC85 Original example: PROGRAMS= server client server_OBJS = server.o server_priv.o server_access.o server_LIBS = priv protocol client_OBJS = client.o client_api.o client_mem.o client_LIBS = protocol # Everything after this is generic .PHONY: all all: $(PROGRAMS) define PROGRAM_template $(1): $$($(1)_OBJ) $$($(1)_LIBS:%=-l%) ALL_OBJS += $$($(1)_OBJS) endef $(foreach prog,$(PROGRAMS),$(eval $(call PROGRAM_template,$(prog $(PROGRAMS): $(LINK.o) $^ $(LDLIBS) -o $@ clean: rm -f $(ALL_OBJS) $(PROGRAMS) Modified fixed (but dummy link/lib) version: CC = gcc PROGRAMS= server client server_OBJS = server.o server_priv.o server_access.o server_LIBS = priv protocol client_OBJS = client.o client_api.o client_mem.o client_LIBS = protocol # Everything after this is generic .PHONY: all all: $(PROGRAMS) define PROGRAM_template $(1): $$($(1)_OBJS) $$($(1)_LIBS:%=lib%.a) ALL_LIB_FLAGS += $$($(1)_LIBS:%=-l%) ALL_OBJS += $$($(1)_OBJS) endef $(foreach prog,$(PROGRAMS),$(eval $(call PROGRAM_template,$(prog # dummy link and library creation $(PROGRAMS): @echo $(CC) -r $^ $(LDLIBS) -o $@ libpriv.a: touch libpriv.a libprotocol.a: touch libprotocol.a clean: rm -f $(ALL_OBJS) $(PROGRAMS) libpriv.a libprotocol.a mksrvcli-sample-dummy-makefile-with-template.tgz Description: application/compressed ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
