automake-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] depcomp: recognize tabs as whitespace in the dashmstdout mod


From: Jim Meyering
Subject: Re: [PATCH] depcomp: recognize tabs as whitespace in the dashmstdout mode
Date: Fri, 03 Feb 2012 19:05:25 +0100

Stefano Lattarini wrote:
> On 02/03/2012 03:51 PM, Peter Rosin wrote:
>>
>>>> Maybe depmod.tap should be replaced/rewritten with "compilers" that
>>>> simulate the different depmods?  I could tinker with that a bit...
>>>>
>>> Yeah, I had thought about the possibility of such an approach, but was
>>> reluctant to suggest it, since it would entail non-trivial work that
>>> can only offer brittle and unsure results anyway...  Maybe we should
>>> simply make it clear that 'decomp' only offers "best-effort" support
>>> for non-mainstream compilers (i.e., different from GCC >= 4.x and from
>>> recent Sun Studio or MSVC compilers); if problems show up, the user
>>> should just use "./configure --disable-dependency-tracking" (and maybe
>>> send us a patch if he's kind and motivated enough).
>>
>> .oO(It would surely have caught a patch that massively destroyed depcomp)
>>
> I'm failing to parse this, sorry.  Could you elaborate or rephrase?  Thanks.
>
>>>> Anyway, let's take this one more round since it is obvious that I can't
>>>> be 100% trusted today and on top of that have been reading through this
>>>> enough to not see any bugs in it even if clearly marked as such...
>>>>
>>> OK.  I'm already preparing a patch to simplify 'depmod.tap' and decrease
>>> the possibility of spurious FAIL or PASS results (will post it this
>>> evening or tomorrow).
>>>
>>>> So, ok to push "depcomp: recognize tabs as whitespace in the dashmstdout 
>>>> mode"
>>>> and the below patch to the msvc branch?
>>>>
>>> ACK.  And ACK for a merge of msvc into master as well.
>>
>> Thanks for the reviews and your patience!
>>
>> Patches commited on msvc, merged into master...
>>
>> Wait, there's a (trivial) conflict.  But if I resolve that and go
>> on with the merge anyway we will end up with two different depcomps
>> with "scriptversion=2012-02-03.12; # UTC".  Not good.

I agree that with multiple branches, lines like that
(as with CVS/Rcs $Id$, $Log$, etc.) guarantee spurious conflicts
with nearly every merge of that file.  Nuke 'em.

> The real problem is that, now that we use several branches and a really
> decentralized VCS, all this 'scriptversion' stuff doesn't really make
> sense anymore.  Couldn't we simply remove them?  I say we should.  What
> do you (and Jim and Ralf, which I'm CC:ing) say?



reply via email to

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