help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: implementing emake's #pragma multi in GNU make?


From: Mark Galeck (CW)
Subject: Re: implementing emake's #pragma multi in GNU make?
Date: Wed, 6 Feb 2013 23:20:23 -0800

Hello,

I read with interest the thread here on "implementing emake's #pragma multi in 
GNU make?". Here is my 2 cents, for what it's worth (2 cents probably :) ).

I listened to Eric excellently speak at the recent EC conference about #pragma 
multi . I even managed to ask him a stupid question about it.  I do think it is 
a nice feature.  

However, I also humbly disagree that it is a "gaping limitation" in GNU Make. 

Eric writes on his blog, quoted here, about the common solution:

------------------------------------------------
"nominate one of the targets as the "primary", and declare that the others 
depend on that target:

bar: foo
foo: baz
   touch foo bar 

$ gmake -j 2 foo bar
touch foo bar
gmake: Nothing to be done for `bar'. 
Awesome! We still have the odd "nothing to be done" message, but just as in the 
serial build, the command was only invoked one time. Problem solved? Nope. What 
happens in an incremental build? If you're lucky, GNU make happens to do the 
right thing and regenerate the files. But in one incremental build scenario, 
GNU make utterly fails to do the right thing. Check out what happens if the 
secondary output is deleted, but the primary is not:

$ rm -f bar && gmake foo bar
gmake: `foo' is up to date.
gmake: Nothing to be done for `bar'. 

That's right: GNU make failed to regenerate bar"
---------------------------------------------------


Yes this is the solution I use.  And I respectfully disagree with what Eric 
says about it.


1.  The "nothing to be done" message is not "odd" at all.  

When you do 

>gmake foo bar

according to the GNU Make manual, it is as if you ran 
>gmake foo
>gmake bar

, not an "all" goal as if in

>gmake all

all: foo bar

Since we have completed  the goal foo, now the second goal, bar, is indeed 
"nothing to be done".  Nothing "odd" about it.  If we ran 
>gmake all

, now bar would not be a "goal" but merely a target, and that message would not 
show up.  

Besides, in my practice with developers, they hardly ever run make with 
multiple goals.  They do one after the other.  


2.  " Check out what happens if the secondary output is deleted, but the 
primary is not:"

"What happens" is:  you have just corrupted your build.  You have touched, 
indeed, deleted, some built files (not sources) and now you expect your 
incremental build to still work?  Of course it won't.  The only recommended way 
to "clean up" if you need to, is to use 
>make clean

In my opinion, a "build" (I don't distinguish between "full" and "incremental") 
is a way to get correct, expected results, given any sequence of allowed 
actions.  Like a finite automaton.  These actions include:

1. Touching (or deleting) your sources. 
2. >make <any targets in any makefile>

Deleting a non-source file is not  one of those actions.  I tell my developers, 
if you touch your objects, you are on your own.  Don't do that and expect 
magic.  

Thank you,

Mark





reply via email to

[Prev in Thread] Current Thread [Next in Thread]