[Top][All Lists]

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

Re: parallel rebuild

From: Angel Tsankov
Subject: Re: parallel rebuild
Date: Tue, 31 Jan 2006 09:23:26 +0200

On 1/30/06, Angel Tsankov <address@hidden> wrote:
> %% "Angel Tsankov" <address@hidden> writes:
> Interesting.  I wasn't aware that parallelism worked on Windows
> platforms.

Ha-ha-haaa... What a futile attempt at being funny!

Umm, are you so sure that Paul's comment wasn't honest?  The Windows
version of GNU make is different in a number of way; it isn't obvious
that it supports the parallelism bits.

Well, I must admint that Paul's comment about parallelism seems to refer to the OS rather than make itself.

(In my experience, Paul doesn't waste his time with Windows bashing.)

Do you really think that I care?!

> That being the case, the order in which "build" is invoked > relative to > "clean" is not defined. It could be invoked first, or second. > I'm not > sure if this is your problem or not; without a definition of > "build" I
> don't see any other issue above.

You have obviously missed the point, Paul.
<sarcasm elided>

Paul's point was that the chunk of makefile you gave does not include
anything that would force the actions associated with the 'clean'
target to be completed before the 'build' target is started when the
'rebuild' target is invoked.  Ergo, during a 'make rebuild', you may
be overlapping the removing of files with the determination of which
files must be rebuilt.  If the removing runs faster, then you'll see
stuff rebuilt.  If the determination of what must be rebuilt runs
faster then only some of the stuff will be rebuilt.  Apparently you
missed that point of Paul's.

I don't agree. Take a look at this part of my first post:

It seems that when I execute the command (i.e. "make --jobs=4 rebuild") after a successful build make
sees that all files are up to date and does not do anything to update
the build target. However, it updates the clean target by removing the
object and output files.

This is what in my opinion he had missed. Then I explained why I need a rebuild target and how the clean, build and rebuild targets relate to one another.

So, how can you force the 'clean' actions to be completed before
starting the rebuild?  Simple: put the building in the action part of
the 'rebuild' target instead of trying to treat it as a dependency.

rebuild:   clean
       @$(MAKE) build

I see no purpose for the build_after_clean target (it has no effect on
the ordering of actions in your makefile), but perhaps in your real
makefile it has some useful actions associated with it.  If not, I
would suggest removing it to avoid confusing the issue.

I totally agree with you about the build_after_clean_target - it was just recommended in a different thread. The thread is titled "Prerequisites processing order" and was started by me. The post is by Paul D. Smith and is the last but one in the thread. Here it is (have in mind that multiprocessing is implied by the context of the thread):

rpjd> if prereq2 has to be done before prereq1, then make the latter a
 rpjd> prerequisite of the former.

 rpjd> target: prereq1

 rpjd> prereq1: prereq2

A more exact replica of the previous example would be:

   target: prereq1 prereq2

   prereq1: prereq2

This is why I have the build_after_clean_target which I not only wish to do away with, but which also does not work as Paul has suggested. Have I missed smth here? And finally, I am looking for a solution that does not involve recursive invocation of make (if such one exists).

Angel Tsankov

reply via email to

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