On 8/27/2010 12:54 AM, Ralf Wildenhues wrote:
> * 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?
I'm not sure. I thought we needed the override at make time, but this
facility is "here" specifically to support a use case that *I don't
use*. I just really really really don't want to break the scheme used
by Danny and others when building gcc (even if Danny has now hung up his
gcc mingw maintainer hat).
It's possible that a configure-time-only override is sufficient.
> 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".
Well, sure: if I thought, at the time, that configure-time-only was
sufficient, I wouldn't have said "we can't". I was assuming that we
needed make-time-override capability; IF that is true, then you really
don't want to get into the situation where, at make-time, the user sets
lt_cv_to_host_path_cmd=a_func_we_did_not_emit.
OTOH, if configure-time-only is sufficient, then you really don't need
lt_cv_to_host_path_cmd at all. You just replace the guts of
func_to_host_path() itself. But that's rather a big change, and I
really don't want to go there right now -- especially as I'm not sure of
the answer to the at-configure-time-only or at-make-time question.
I think that question will have to be deferred until all this stuff is
merged, with the make-time-override capability, and then we let folks
(like Danny) get used to it. THEN we ask "hey, would it be ok if you
could only modify the file/path conversion schema at configure time,
rather than at make time?"
>> 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.
No, it wouldn't be dead code. Basically, you'd have
from_$build (actually, we would NOT really implement
any of these; see below)
to_$host == what they are now
There were be TWO variables lt_cv_from_build_cmd and lt_cv_to_host_cmd,
but only one function would ever eval them:
generic_build_to_host() {
$from_build_cmd "$1"
$to_host_cmd "$from_build_cmd_result"
generic_build_to_host_result=$to_host_cmd_result
}
But, at present, $from_build_cmd would *always* be assigned to
func_convert_noop.
Everywhere we currently do "$to_host_cmd ...", you do
"generic_build_to_host ..." instead.
It's not "dead" code -- but it's *useless* code, right now, since with
the weird w32 platforms, you'd be calling $from_build_cmd
(func_convert_noop) uselessly.
> 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.
I've reworded this discussion and put it into TODO, but don't plan to
address it any more than that. Status quo for now.
--
Chuck
