* Charles Wilson wrote on Thu, Aug 26, 2010 at 11:20:48PM CEST: > Also: I've said this before, but we can't use the m4 > function_replace magic because we need to retain the ability for > users to override the choice of $func_to_host_path_cmd. This is > critical for the 'cygwin->mingw (lie)' use case, which is VERY > common for the gcc developers.
Do you need an override at 'make' time or does one at configure time suffice? Because if the latter (which I'm assuming), then from my POV the above is just a statement that function_replace is not good enough for your needs, not one "it cannot be done". Please don't get into the habit of saying that something cannot be done if there's just another TODO item which you (understandably) may not want to fix yourself. That is very confusing in a technical discussion. Thanks. > On 8/26/2010 4:18 PM, Ralf Wildenhues wrote: > >I'm not sure I've asked before, but will state again: coding up X-to-Y > >for N choices of X and M choices of Y has complexity N*M, while coding > >it up as from-X and to-Y has complexity N+M. Quadratic algorithms don't > >scale. Why is the latter not done? > > I don't think it has come up explicitly, but it also occurred > independently to me. The main issue is you don't know what the > "native" (e.g. "central") path-type is; e.g. "from-X (to what?)" and > "(from what?) to-Y". Right. [...] > So...I don't think it makes much difference *right now* in the > amount of code required, or the number of functions implemented. Beside looking fairly ugly, yes. > OTOH, as a follow-on patch after 2.2.next, we could implement an > explicit N+M scheme just so that any future extensions -- which I > can't actually foresee -- could "hook in" scalably. Oh no, please not code which already sets out as dead code. If there is a need for more translations, then maybe, but then I'd suggest there'd be an effort to get as many of the w32 translators under the same hood as possible. > >The answer should be in a comment > >in the code, if it cannot be done. If it can be done, then I am OK with > >making it a TODO item to be addressed after 2.2.12, rationale being that > >that's just an optimization so QoI issue, whereas your patch brings new > >features. > > Err... ^^^ that's quite a long comment to parse in > ltmain.m4sh...maybe a short note to see the TODO file, and put the > bulk there? Sure; just a TODO file entry seems fine, too. Point is that it's not just in mail. Cheers, Ralf