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?