Re: submake messages not perfect
Paul I guess I still don't understand Dan's comment, though. Well for me, make calling several make's all in the same directory, I see lots of messages about how they are entering and leaving that directory, when in fact they never set foot outside that directory, and what they really were trying to say was I'm now being born, I'm now dying. And they all call themselves [1] dj so maybe even mention PID's. I don't see what PIDs have to do with anything. sr To be able to distingush between two different make instances? Paul But none of make's normal output says anything about PIDs. Well, why not take a tip from syslog and start adding them today. [1:3515] looks smarter than just [1]. Since you are already detecting when make is called by make and printing special messages, you might as well beef them up. sr It's anyway insane^Wunsafe to have two make's running in parallel sr in same dir. Paul Well, it's not necessarily true that it's unsafe. As long as they are Paul building disjoint sets of targets it will work fine. OK document that. Some programs aren't safe. Paul But, I do think it's not very useful since it's much simpler to just let Paul make do the parallelism for you from a single invocation. I wanted to but found I cannot limit -j's reach to only one level. That's why I wanted you to dj Do add an examples showing when dj $ make -j x y dj and dj $ make x make y wait dj are equivalent, and when they are not. Paul IMO that is not at all an appropriate example for the GNU make manual. Well, OK, whatever. All I know is that they can be the same or not, depending on how deep their dependencies are. I was not able to use -j in http://jidanni.org/comp/apt-offline/ so did the two 's. ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
Re: submake messages not perfect
%% Dan Jacobson [EMAIL PROTECTED] writes: Paul I guess I still don't understand Dan's comment, though. dj Well for me, make calling several make's all in the same dj directory, I wrote a long reply to this. Then I rewrote it. Then I decided to delete most of it :). I've left some comments about using -j with make below. I'll just say that I think that the issues you've raised here apply specifically to the extremely unusual use-case where you invoke multiple make's from the command line in parallel, putting them into the background. This is not a situation I've ever known anyone else to feel is useful with make. I don't see any real utility in the changes you've described to the manual or the code for the traditional, 99.99% of use cases where one invocation of make is invoked, either serially or in parallel. That being the case I have a hard time justifying to myself the added complexity in the documentation or in the codebase. I will point out one important fact: recall that GNU make runs on many platforms _OTHER_ than UNIX: it runs on DOS, Windows, Amiga, and VMS, plus a port to OS/2 for the next release. I'd prefer to avoid describing complex capabilities that are unique, and/or whose syntax is unique, to UNIX or even specific shells, in the GNU make manual; that's not where such things belong. A few comments on parallel builds: Paul But, I do think it's not very useful since it's much simpler to Paul just let make do the parallelism for you from a single Paul invocation. dj I wanted to but found I cannot limit -j's reach to only one level. Yes you can. Just set the commandline of any submakes to add -j1 and force them to run serially: .PHONY: subdir subdir: $(MAKE) -j 1 -C $@ dj Do add an examples showing when dj $ make -j x y dj and dj $ make x make y wait dj are equivalent, and when they are not. Paul IMO that is not at all an appropriate example for the GNU make Paul manual. Note my comments above about make running on multiple platforms, etc. dj Well, OK, whatever. All I know is that they can be the same or not, dj depending on how deep their dependencies are. That's not what I said. I said it was safe as long as the two targets were entirely disjoint. It doesn't matter how deep or shallow their dependencies are, it only matters if the sub-tree of their dependency graphs overlap or not. The only thing that's different about these two invocations is the quite obvious: since they're running completely separately, they don't know anything about each other. That means that if their dependency graphs overlap, you might get into a situation where both instances of make were trying to build the same target at the same time. That is almost guaranteed to be a problem. If you have one instance of make running with -j, it knows which targets have been built, which are in the process of being built, and which have not been built yet. So, it will never build a target until all its prerequisites have been completed. dj I was not able to use -j in http://jidanni.org/comp/apt-offline/ so dj did the two 's. Lots of very helpful people read this list. If you would like some assistance, try asking a question with a small example of what you're trying to do. -- --- 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://lists.gnu.org/mailman/listinfo/bug-make
Re: submake messages not perfect
On Sun, Aug 29, 2004 at 01:44:48AM -0400, Paul D. Smith wrote: %% Dan Jacobson [EMAIL PROTECTED] writes: dj The messages on submakes aren't perfect. dj make[1]: Entering directory `/tmp' dj make[1]: Leaving directory `/tmp' dj You mean starting submake 1 and especially ending submake[1]. I don't understand your comment. Maybe I did :-) This message appear when you do: make -C some/dir When using recursive make files you almost always uses 'make -C ...' so the original writer get the impression this is something printed only for make invoked from within make. What it tells is that make enter directory 'xxx' and uses normal rule-set to find a Makefile. Pretty clear when know the make machinery. And too many programs are dependent on this message for it to just change wording a bit. dj In fact, if one did dj bla: dj make a make b dj then they would both be [1], Yes, because both of them are direct submakes of the top-level make. If you want to get up to two you have to have a sub-submake (the top level make invokes a make which invokes another make). dj so maybe even mention PID's. I don't see what PIDs have to do with anything. To be able to distingush between two different make instances? It's anyway insane^Wunsafe to have two make's running in parallel in same dir. Sam ___ Bug-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-make
Re: submake messages not perfect
%% Sam Ravnborg [EMAIL PROTECTED] writes: %% Dan Jacobson [EMAIL PROTECTED] writes: dj The messages on submakes aren't perfect. dj make[1]: Entering directory `/tmp' dj make[1]: Leaving directory `/tmp' dj You mean starting submake 1 and especially ending submake[1]. sr This message appear when you do: sr make -C some/dir It appears when you invoke a sub-make, period, regardless of whether you use -C or not. sr When using recursive make files you almost always uses 'make -C sr ...' so the original writer get the impression this is something sr printed only for make invoked from within make. I think you're chasing herrings when you talk about -C (where did that come from?) but it is correct that this message is printed when invoking make from within make (recursive make, or submake, or whatever). I guess I still don't understand Dan's comment, though. dj so maybe even mention PID's. I don't see what PIDs have to do with anything. sr To be able to distingush between two different make instances? But none of make's normal output says anything about PIDs. It's not the intent of the GNU make manual to give a tutorial on UNIX or multiprocessing, after all. I'm certainly not interested in explaining what a PID is and why you should care, when it is not relevant to understanding how to use GNU make. sr It's anyway insane^Wunsafe to have two make's running in parallel sr in same dir. Well, it's not necessarily true that it's unsafe. As long as they are building disjoint sets of targets it will work fine. But, I do think it's not very useful since it's much simpler to just let make do the parallelism for you from a single invocation. -- --- 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://lists.gnu.org/mailman/listinfo/bug-make
Re: submake messages not perfect
%% Dan Jacobson [EMAIL PROTECTED] writes: dj The messages on submakes aren't perfect. dj make[1]: Entering directory `/tmp' dj make[1]: Leaving directory `/tmp' dj You mean starting submake 1 and especially ending submake[1]. I don't understand your comment. dj In fact, if one did dj bla: dj make a make b dj then they would both be [1], Yes, because both of them are direct submakes of the top-level make. If you want to get up to two you have to have a sub-submake (the top level make invokes a make which invokes another make). dj so maybe even mention PID's. I don't see what PIDs have to do with anything. -- --- 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://lists.gnu.org/mailman/listinfo/bug-make
