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

[Neil Jerram <neil@ossau.uklinux.net>]

Jan Nieuwenhuizen <janneke-list@xs4all.nl> 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