Hallo Ralf, Not wishing to be curmudgeonly... however:
Ralf Wildenhues wrote:
| OK to apply the combined patch below?No, not okay! I haven't tested the code yet, but I do remember that the areas you are touching are exceedingly delicate. And even though on a cursory look, your patch looks sane, this is something to apply after 2.0!Please rethink this judgement again.
I've thought again, and your patch is still outside of our 'fix bugs or add tests between now and 2.0' credo.
I deliberately tried for a minimal-invasive change;
I'm not disputing that; it's just that applying this change pushes back the release a little further, and churns the code a little more. We have to draw the line somewhere, otherwise it is too easy to keep finding more and more little improvements that it would be nice to put in before the next release, and before we know it, that next release slips by another 2 years. I'm afraid I'm not even susceptible to the 'just this one last change' argument... the faster we get 2.0 out the door and shake the bugs out of it, the less effort we'll waste keeping 1.5.x alive, and the sooner we can put our pet patches into the tree. I have a whole list of things I want to see in 2.2 myself, some of them already expressed as patches. But let's not go there.
consistency-wise, it would probably be better to work with m4 lists all the time instead of converting to and from; but my patch actually keeps each of the three functions and their interfaces the same.
ACK. These are internal interfaces though, and while maintaining the existing syntax and semantics at the interface layer reduces the possibilty of forgetting something in one of the callers, cleanups make the code more understandable and maintainable in the long term.
Also, it might be much more efficient to change _some_ of the code not to use the dictionary lookup code: a list of tagged/non-tagged variables may easily be updated in _LT_DECL already; however, this is not a minimal change, either.
ACK.
On the other hand, thankyou very much for taking the time to fix this problem! I'm going to add your patch to my quilt series and enjoy the speedup until 2.0 is done. It'll also mean that I'll have been able to give it a good workout before approving.I can only rephrase: please rethink your post-2.0 judgement. Tell me what you need to be convinced (test suite tests for these functions, whatever).
Sorry, but I'm hell bent on focussing for the release. Fantastic though it will be to see a speedup in the bootstrap... it is a symptom of the 'just one more thing' creeping featurism that has been holding back our release process for so long.
Please also remember that, if _you_ use this, the old version will not be tested any more. It might thus just as well break in between, unnoticed, or be broken before, but breakage only uncovered later.
I meant that I will use it for my installed libtool, mainly for work
on M4. I'll keep my libtool dev tree clean, except for the 2.0 patch
queue.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
