[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
- Re: implementing emake's #pragma multi in GNU make?,
Mark Galeck (CW) <=
- Re: implementing emake's #pragma multi in GNU make?, Michael Stahl, 2013/02/07
- Re: implementing emake's #pragma multi in GNU make?, Mark Galeck, 2013/02/07
- Re: implementing emake's #pragma multi in GNU make?, Gerhard Fiedler, 2013/02/08
- Re: implementing emake's #pragma multi in GNU make?, Mark Galeck, 2013/02/08
- Re: implementing emake's #pragma multi in GNU make?, Gerhard Fiedler, 2013/02/10
- Re: implementing emake's #pragma multi in GNU make?, Mark Galeck, 2013/02/11
- Re: implementing emake's #pragma multi in GNU make?, Michael Ludwig, 2013/02/12
- Re: implementing emake's #pragma multi in GNU make?, Michael Stahl, 2013/02/08
- Re: implementing emake's #pragma multi in GNU make?, Mark Galeck, 2013/02/08
- Re: implementing emake's #pragma multi in GNU make?, Michael Stahl, 2013/02/08