Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)

[Ralf Wildenhues]

* 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