Hello, On šeštadienis 15 Rugpjūtis 2009 23:46:44 Raphael Hertzog wrote: > with the feedback received and from what I understand, it's not a > feature that I would like to support on the long term since there is no > finite set of substitutions and those can change depending on external > include files.
If I understand correctly, everybody more or less liked all substs but vt one. In fact, I was definitely wrong on that one and I agree that it is broken by design. Actually, I have the code lying on my private git repository which implements (IIRC): * c++ tag which does matching on c++filt output; * regexp tag which permits and does regexp matching in symbol names; * reworked wildcard implementation. All these tags are based on the same framework hence they fully support missing / new symbols detection (Closes: #541464). Unfortunately, I have not got around to write tests / update man page for these changes yet hence I never submitted the patch for review :/ I may post it in the current state if you want to see it. > Externalizing the definition of substitutions would avoid the maintenance > problem for us but it doesn't make the solution any better. I think it's > best if you maintain that functionnality outside of dpkg-dev for now. > Tagging it wontfix and not closing it since it's a decision that might be > revisited later on. That's unfortunate to hear. I understand why maintaining substitution definitions inside dpkg-dev might be unfeasible but what is wrong with providing framework for externalizing them? In other words, if vt is dropped, what is wrong with other substs? Sure, with regex matching one can avoid substs at all, but substs leave less ambiguity and will always be faster since their result is predictable in parsing stage. -- Modestas Vainius <modes...@vainius.eu>
signature.asc
Description: This is a digitally signed message part.
