Re: [Xen-devel] [PATCH] Add -MP to CFLAGS along with -MMD.

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Wed, 2020-03-18 at 18:19 +0000, Ian Jackson wrote:
> David Woodhouse writes ("Re: [PATCH] Add -MP to CFLAGS along with -MMD."):
> > OK... I have attempted to address my frustration in a more coherent and
> > hopefully productive way (qv), rather than resorting to monosyllabic
> > responses. Apologies for that.
> > 
> > Back to the specifics of this patch...
> 
> Wow.  Impressive.  Thank you for the comprehensive explanation.

Actually, I think I may have erred. The make documentation at
https://www.gnu.org/software/make/manual/html_node/Phony-Targets.html
makes a distinction between "phony targets" and ".PHONY targets".

What GCC emits *is* the former, while it is the latter which are
documented as causing implicit rules to be skipped.

So I think the GCC and Make documentation is entirely consistent, if
somewhat suboptimal in its use of terms with different meanings which
differ only in case and punctuation. Although looking back in
retrospect, the difference between "phony target" and ".PHONY target"
is clear enough that I wonder how I missed it.

> Supposing you put all that in the commit message:
>   Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> (for the original patch)

To be honest, I don't think it lives there. It's just a digression,
based on a half-misremembered idea that phony (not .PHONY) targets
cause implicit rules to be skipped.

Aside from that misremembrance, .PHONY rules aren't actually relevant
to this commit in any way.

It's two fairly pointless hours of my life that I want back, in which
I could have been doing something more useful on extending our live
update support to support inheriting the crashdump setup from the
previous Xen, as I had planned to do today.

Let's suppose I were to distil my 'research', including the above
correction, into an assertion along the lines of

"While make will skip implicit/pattern rules for targets which are 
 explicitly declared as .PHONY, what GCC emits with -MP are merely
 'phony targets' which are rules without a recipe, and which don't
 cause implicit rules to be skipped. Thus, the presence of such a
 rule should not prevent auto-generated header files and the like
 from being created correctly."

As we look back at this commit in future perhaps if we suspect it of
doing something wrong, what *benefit* is there to seeing that in the
commit comment?

Assuming it's a correct assertion, it's fairly much going to be
irrelevant to anyone who looks at this commit in future.

And if it's false, and I'm wrong? It's going to be either a red herring
derailing the investigation into what went wrong, or it only serves to
demonstrate how wrong I was :)

AFAICT there are very few situations, if any, in which anyone would
look back at this commit and find a comment about .PHONY targets to be
beneficial instead of just added noise.

It doesn't meet my criteria for being added to the commit comment.

May I have your Acked-By: without the addition, please?

> If you were feeling dynamic, getting the gcc does (and maybe the make
> docs) improved would be nice.

I was filing that GCC PR when I came to the realisation with which I
opened this email, and abandoned it.

> > So no, I don't think using -MP is going to break our handling of auto-
> > generated header files, but we'd have known that from a trivial
> > empirical build test within seconds, wouldn't we?
> 
> Unfortuantely in these days of many-core cpus, empirical tests showing
> that the makefile works this time do not necessarily mean it will work
> every time.  Maybe that wasn't a concern in this case, but my
> experience in general teaches me not to rely solely on tests other
> than to answer very narrow questions.

Indeed, but as you suggest I don't think this is a case that depends on
parallelism. Make tends to be fairly deterministic about what rules
*mean*, even when race conditions exist in parallel execution of those
rules.

> Sorry that this was frustrating in this case, but I think that some of
> the lossage from our (sometimes appalling) makefiles has arisen due to
> patches being committed that appeared to work at the time.  So I don't
> think your research was wasted effort.

Well, I refuted^Wrebutted *one* theory, which turns out to be
incorrect, about *one* way in which it might fail. This is far from
being a formal proof of correctness of my patch.

I suppose 'wasted' is a very subjective term and let's not argue over
whether it was wasted or not. But equally, we are no further forward
than we were before I had an erroneous theory to dispute.

Really no further forward in any way, because I didn't get to spend
that time doing anything more useful either.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel