From: ludo@gnu.org (Ludovic Courtès)
To: Andreas Enge <andreas@enge.fr>
Cc: guix-devel@gnu.org
Subject: Re: Texlive and native-inputs
Date: Wed, 29 Oct 2014 23:29:32 +0100 [thread overview]
Message-ID: <87r3xqfr1v.fsf@gnu.org> (raw)
In-Reply-To: <20141029173948.GA16948@debian.eduroam.u-bordeaux.fr> (Andreas Enge's message of "Wed, 29 Oct 2014 18:39:48 +0100")
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’.
next prev parent reply other threads:[~2014-10-29 22:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-29 17:00 Texlive and native-inputs Andreas Enge
2014-10-29 17:13 ` John Darrington
2014-10-29 17:39 ` Andreas Enge
2014-10-29 17:52 ` John Darrington
2014-10-29 18:51 ` Andreas Enge
2014-10-29 19:55 ` John Darrington
2014-10-29 22:31 ` Andreas Enge
2014-10-30 7:53 ` John Darrington
2014-10-30 8:02 ` Andreas Enge
2014-10-30 9:24 ` John Darrington
2014-10-29 22:37 ` Ludovic Courtès
2014-10-29 22:29 ` Ludovic Courtès [this message]
2014-10-29 17:43 ` Andreas Enge
2014-10-29 18:03 ` John Darrington
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r3xqfr1v.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=andreas@enge.fr \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.