[Top][All Lists]
[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.