Re: [PATCH 4/5] Inline the effect of am/pre-inst-guile

[Neil Jerram]

Jan Nieuwenhuizen <address@hidden> writes:

[in rearranged order...]

>> -    "$(preinstguile)" -l "$(srcdir)/$(snarf_doc).scm" -c "                  
>> \
>> +    "$(top_builddir_absolute)/meta/guile" -l "$(srcdir)/$(snarf_doc).scm"   
>> \
>> +     -c "                                                                   
>> \
>
> How do you suggest this works during cross compiling?

Because meta/guile itself uses $GUILE_FOR_BUILD when $cross_compiling is
"yes".

> Ah, but in my cross build recipe, i have something like
>
>    preinstguile=$GUILE_FOR_BUILD

Is that because you're cross-building in a way that doesn't set
$cross_compiling to "yes"?

I can understand if you are, because I think I was doing that when last
working on mingw building, and using Wine and binfmt to run the built
executables.

> I know this isn't nice, I think preinstguile should go
> and we should use $GUILE_FOR_BUILD throughout.
>
> It's just one variable, but one that you can override,

I think the right thing might be to ensure that $cross_compiling is set
to "yes" for your build, even if the default ./configure mechanisms
(which I presume are based on the --target option) don't set it.  Could
you do a grep-find for "cross_compiling", and see if any of the things
that depend on [ $cross_compiling = yes ] would _not_ be appropriate for
your kind of build?

(I think this would have worked for the mingw build that I was doing.
The difference would have been that the non-installed intermediate
executables, like guile_filter_doc_snarfage, were built (using
CC_FOR_BUILD) and run host-natively, instead of being target-built and
then Wine-run.)

Regards,
        Neil