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.
>
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?
For this change, I suggest you simply bump the $scriptversion on master
after the merge (set it to, say, 2012-02-03.17). This is IMHO better
that having more backporting of non-essential patches.
> There is no good place to base this. It's another instance of trouble
> caused by the `quote'-'fix' commit on master. I want to sync the
> depcomp version on msvc with that on master (I forgot that depcomp
> on msvc and maint differed when I did v1.11-654-g41404a8
> "scripts: cherry-pick recent changes from master") before I push
> the above.
>
> So, I'm suggesting the following change on msvc first, then the other
> two that you ACKed above, then merge msvc into master and branch-1.11.
>
> Ok?
>
As I said above, I'd prefer a simple bump of $scriptversion during the
merge to master. But in case you insist to do this backport ...
>
> From 0ef94b4e737ddf9b2f2ea47c02fc11ac932f3d1e Mon Sep 17 00:00:00 2001
> From: Peter Rosin <p...@lysator.liu.se>
> Date: Fri, 3 Feb 2012 15:46:09 +0100
> Subject: [PATCH] depcomp: cherry-pick recent changes from master
>
... I'd change the summary line to give a more meaningful description of
the change ("depcomp: quote 'like this', not `like this'"), and then
add a paragraph telling that you are backporting this change from master
(A simple "Cherry-picked from recent changes from master" will do IMHO).
Thanks,
Stefano
