Re: [PATCH] depcomp tests: speed up libtool-based tests

[Peter Rosin]

Stefano Lattarini skrev 2012-02-09 14:08:
> On 02/09/2012 12:05 PM, Peter Rosin wrote:
>> Stefano Lattarini skrev 2012-02-09 11:36:
>>> Sorry to answer to myself, but I think I've found a better, simpler
>>> and more appropriate way to speed up the depcomp+libtool tests.  See
>>> attached patch.
>>>
>>> OK for master?
>>
>> I was wondering about the multiple libtool runs, but figured there
>> was some difference if you only built shared or only built static,
>> compared to doing both in the same build.  But that does not seem to
>> be the case if I read the rationale for this change.
>>
> Well, duh!  By re-reading the diffs of commit e89ec38d (which is my only
> reference in this matter), it seems that your objection is correct and my

I wasn't really objecting, I was just full of question marks :-)

> rationale is wrong, in that the bug fixed by that commit presented itself
> only when the building of shared libraries was somehow disabled.  So we

s/shared/static/

> still need to go with something similar to the first patch -- but, unless
> I'm again mistaken, we need do the extra checks only for the depmodes for
> which the location of the compiler-generated depfiles can depend on which
> flavour of libraries are being built by libtool.  Attached is a patch that
> attempts to do so.  Since my brain clearly isn't functioning properly in
> this matter, I will wait for an ACK before pushing.

Libtool normally puts objects related to shared libs in .libs so that they
don't clash with objects from the static libs. But if libtool isn't doing
any static libs, it puts the objects for the shared libs where it otherwise
would have put the objects for the static libs.  I guess this change in
layout is what caused the original trouble?

But that is perhaps best seen as an internal detail and we'd better not
optimize out the static-only build (i.e. perhaps optimizing it out on the
grounds that it doesn't add much coverage, but in the end not optimizing it
out because the optimization relies on an Libtool-internal detail that might
change).  Besides, there might be some odd platform that only builds
shared libs by default, and in that case you do get increased coverage by
doing all three variants.

All in all, I think you proposed change is sane.  I haven't actually tested
it, but what the hell, it looks good so go ahead.

Cheers,
Peter