bug-make
[Top][All Lists]
Advanced

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

RE: Error in processing of :: targets


From: reid . madsen
Subject: RE: Error in processing of :: targets
Date: Tue, 14 Jun 2005 07:32:51 -0700

Howard,

I thought I was using Sun's make, but in fact I was using GNUmake V3.75.
And in that version this works perfectly.  Meaning that the commands for
all.prologue are executed to completion before aaa, bbb, and ccc, are
build, and the commands for all.epilogue are executed AFTER aaa, bbb,
and ccc are built.

So you think it is bogus.  Then how would you implement this makefile
(which worked fine in 3.75 GNUmake) to achieve the described ordering?
Specifically the commands of all.prologue must execute BEFORE aaa, bbb,
or ccc.

        all:: all.prologue
        all:: aaa bbb ccc
        all:: all.epilogue

        all.prologue:: ; @echo prologue
        all.epilogue:: ; @echo epilogue
        aaa bbb ccc: ; @echo $@

Sure, you could add:

        aaa: all.prologue
        bbb: all.prologue
        ccc: all.prologue
and
        all.epilogue:: aaa bbb ccc

But assuming that every rule writer -- in a complex build system -- will
remember to do this is an unsafe assumption.  And it makes no difference
whether this Makefile was generated by IMAKE or by hand -- the problem
is the same.

In version 3.75, each :: rule and its dependencies were treated
separately.  Meaning that for each :: rule, the dependencies for that
rule were evaulated, and then the commands for that rule were run.
Dependencies for subequent instances of the same target were deferred
until that :: rule was evaulated.  If multiple dependencies were
specified, then they were built in parallel when the :: rule they were
mentioned in was evaluated.

In version 3.80, the dependencies for all :: rules are evaluated in
parallel before any commands for the :: target are executed.  This is a
significant change from V3.75.

Bottom line, GNUmake V3.75 provided a very useful mechanism to establish
ordering of :: rules in a parallel environment.  Thus functionality has
been lost in later versions.

Reid Madsen

-----Original Message-----
From: Howard Chu [mailto:address@hidden 
Sent: Tuesday, June 14, 2005 8:21 AM
To: Madsen, Reid
Cc: address@hidden
Subject: Re: Error in processing of :: targets

address@hidden wrote:
> Gnumake maintainers,
>  
> I've run into a functional difference between the standard unix make 
> and GNUmake (3.80) involving how the :: rules are processed.
>  
> In the standard unix make (Solaris), the :: targets ( i.e., all::) are

> process in the order they are found in the Makefile serially, 
> regardless of whether parallelism is used (i.e., -jN, where N is > 1).

That's funny, my "standard Unix" (Solaris) make doesn't have a "-j" 
switch, and doesn't support parallelism. In fact, -j is a GNU-specific
extension, and it Works As Designed.
>  
> In GNUmake (3.80), the when -j1 is used, the "::" targets are executed

> serially.  When -jN is used the "::" targets are executed in parallel.

> Consider the following -- from an IMAKE generated Makefile:

This, like most of the dreck that Imake produces, is bogus.

http://lists.gnu.org/archive/html/bug-make/2001-09/msg00013.html
http://lists.gnu.org/archive/html/bug-make/2004-09/msg00001.html

> all:: all.prologue
> all:: all.serial all.parallel
> all:: ; @echo $@; sleep 1; echo address@hidden <mailto:address@hidden>
> all:: all.epilogue
>  
> all.epilogue all.prologue:: ; @echo $@; sleep 2; echo address@hidden 
> <mailto:address@hidden>
> all.serial:: ; @echo address@hidden <mailto:address@hidden>; sleep 1; echo 
> address@hidden 
> <mailto:address@hidden>
> all.serial:: ; @echo address@hidden <mailto:address@hidden>; sleep 1; echo 
> address@hidden 
> <mailto:address@hidden>
> all.parallel: aaa bbb ccc
> aaa bbb ccc: ; @echo $@; sleep 1; echo address@hidden <mailto:address@hidden>

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support




reply via email to

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