Re: Texlive and native-inputs

[ludo@gnu.org (Ludovic Courtès)]

Andreas Enge <andreas@enge.fr> skribis:

> On Wed, Oct 29, 2014 at 06:13:09PM +0100, John Darrington wrote:
>> If they were "normal" inputs and you were cross compiling, then the packages which
>> are made available, would be those for the target system, not the native one.  Hence
>> they could not run, and the build would break.
>
> Well, my point is that probably the scripts are not run during the build
> process, but on the target system.
>
> For instance, texlive installs a file
>    texlive-2014-data/texmf-dist/scripts/psutils/psjoin.pl ,
> which I suppose does what its name says.
>
> Because we have perl as a native input, patch-shebangs replaces its first
> line by
>    #!/gnu/store/5x0h6n8ln2fvaqk1q2ji79x08y8bdr35-perl-5.16.1/bin/perl
> Then if we are cross-compiling with perl as a native input, this is the perl
> of the build and not of the target machine, and the user calling psjoin.pl
> on the target machine has a dangling interpreter here.

Then you have evidence that Perl must be in ‘inputs’.  It might/may be
that it also needs to be in ‘native-inputs’ (there’s a chance that some
build scripts use it.)

> So I think perl, python and tcsh should be normal inputs; as far as I know,
> they are not used during the build process of texlive.

OK.

>>      Or what happens if both is the case?
>> In that case, the package would need to be declared as both an input and a native-input.
>
> Would it work?

Search paths specifications for native and target inputs are disjoint.
So for instance, when cross-compiling, only native inputs are added to
$PATH.

However, I just realized that our ‘patch-shebangs’ phase (the one that
runs at the end) is buggy, since it patches according to what’s in
$PATH, even when cross-compiling.  I’ve filed a bug.

Anyway, apart from that, it would work.  :-)

Ludo’.