|Jeroen Demeyer on Tue, 11 Jan 2011 22:13:06 +0100|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: Path to perl|
On 2011-01-11 12:18, Karim Belabas wrote: > @perl@ is used whenever the script will be run on the end user's machine > (to provide extended help and prettyprinting, respectively). > > All other scripts are maintainer-only : they generate files to be > included in the release, but the scripts themselves no longer need to be > run by the end user to build the package. Thanks for the clarification. > Our releases assume that the person *installing* PARI on a given target > machine has a sane environment, in particular that perl can be found in > *his* PATH. Then the extracted scripts can be run by other users, > themselves possibly plagued with badly broken configurations. Okay, I understand your point. However, for Sage I would guess that being able to move binaries around is probably more important, so it might make sense to use #!/usr/bin/env perl for Sage. > This ticket apparently refers to a bug in sage packaging : our gphelp > doesn't start with #!/usr/bin/perl but must be extracted from gphelp.in > at Configure time (@datadir@ must also be positionned correctly; > @version@, on the other hand, is unimportant). There actually is a mistake in the bug report: Sage builds PARI using PARI's Configure (with some modifications), the person making the bug report just looked at doc/gphelp and didn't realize it was auto-generated. Considering @datadir@ in gphelp: am I right to say that the value of @datadir@ doesn't matter if the environment variable GPDOCDIR is set (which is the case within Sage). Jeroen.