help-make
[Top][All Lists]
Advanced

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

Re: .PHONY and .SECONDARY interaction in make 3.81: bug/feature?


From: Alexey Neyman
Subject: Re: .PHONY and .SECONDARY interaction in make 3.81: bug/feature?
Date: Tue, 15 Mar 2005 23:28:57 +0300
User-agent: KMail/1.7.1

Paul,

I checked make versions 3.77 and 3.79.1. The 3.77 version behaves as make 3.81 
does now: the testcase from the PR #12331 reports "make: Nothing to be done 
for `all'."; make 3.79.1 reports "GOOD".

Therefore, it seems that the behavior was actually broken somewhere between 
3.77 and 3.79.1, and the original meaning of .SECONDARY was the one stated in 
PR #2515.

I would suggest using .PRECIOUS target without prerequisites to have the 
semantics "do not delete any intermediate file". For now, .PRECIOUS without 
prerequisites is actually a no-op.

This way, .SECONDARY will behave in the way it did historically. Also, there 
will be a way to request the behavior that make used to exhibit in versions 
3.79-3.80 for the .SECONDARY target without requisites.

Otherwise, a new target (.PRECIOUS_ALL) could be created.

If any of these solutions is ok, I will provide a patch.

Regards,
Alexey.

On Tuesday 15 March 2005 20:38, Paul D. Smith wrote:
> %% Alexey Neyman <address@hidden> writes:
>
>   an> revision 1.69 made .SECONDARY target not only set the 'all_secondary'
>   an> variable to 1, but also sets ->intermediate flag on all files.
>   an> Therefore, the check_dep() function in remake.c doesn't notice that
>   an> version.c needs to be rebuilt unconditionally.
>
>   an> The following patch solves the problem. No regressions introduced on
>   an> i686-pc-linux-gnu (Fedora Core 2).
>
> Hm.  This solves the problem for .PHONY files, but what if you use the
> old-style FORCE target method to force rebuilds:
>
>     FORCE: ;
>     version.c: FORCE
>
> This doesn't work with .SECONDARY set globally: it thinks FORCE doesn't
> need to be remade (even though it doesn't exist), so version.c doesn't
> need to be remade, etc.
>
> Unfortunately it's not exactly clear from the documentation (which is
> all I have to go on) what it means to set .SECONDARY globally.  If you
> take the documentation at face value, the current (3.81) behavior is
> correct and the bug you're reporting is actually an enhancement request,
> that marking a target as .PHONY take precedence over .SECONDARY and
> .INTERMEDIATE, whereas right now it's the other way around.  Which is
> fine with me as a change, BTW.
>
>
> However, I'm not sure that's really what the original intent of the
> global .SECONDARY target was... or else I'm not sure all the
> ramifications were completely thought out.  Note you cannot define a
> global .INTERMEDIATE target!  Why, then, can you define .SECONDARY
> globally, that imputes all the behavior of .INTERMEDIATE to all targets
> in the system--except for automatic deletion?  It seems strange and
> unusual to me.
>
> I have to wonder if the original point of the global .SECONDARY was
> really just to turn off all automatic deletions of any intermediate
> files, without really forcing every target to be considered
> intermediate.  To me that would make more sense.
>
>
> On the other hand, if you read the information provided with bug # 2515,
> which originally fostered this change, Bill Curry (the author of the
> bug) clearly feels that the former ("face value" reading) of the docs is
> correct and is what RMS intended when he introduced the feature,
> apparently at the request of the project that Bill is working on.  So, I
> guess maybe that is correct.  I personally would probably have
> implemented this differently, because it seems that we have a matrix of
> two different capabilities (delete/don't delete intermediates, and
> build/don't build non-existent files) and the current set of targets to
> set the capabilities doesn't cover the entire matrix: there are some
> things you can't do.  I would have preferred to define the targets in a
> more orthogonal manner to cover the entire matrix.  Then you could have
> used them in combination to get the behavior you wanted more precisely.




reply via email to

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