| Karim Belabas on Sat, 24 Jan 2015 10:49:53 +0100 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| Re: Install Perl scripts with #!/usr/bin/env perl |
* Bill Allombert [2015-01-21 22:32]:
> On Mon, Jan 19, 2015 at 12:28:19PM +0100, Jeroen Demeyer wrote:
> > On 2015-01-19 12:20, Bill Allombert wrote:
> > >your proposal defeats the purpose of the Configure check, since the perl
> > >program checked by Configure might not be the perl program that will be used.
> > No, it does not since the perl program checked by Configure is still
> > used at build-time. My patch only changes things at run-time, not
> > build-time.
>
> The Configure check was meant for tex2mail.
> In fact, if you use release tarballs, PARI does not use perl to build.
Let me recap.
0) We use standard Perl4 features, any perl binary should do.
1) We need a perl binary to build when updating from git (not from tarballs)
2) We need a perl binary at run-time for gphelp & tex2mail
3) In principle (build machine different from target...), we thus need
to specify 2 binaries in independent ways
4) Current Configure behaviour is broken: finds 1 binary at build time
(OK for build) and use same path for run-time (not OK).
I propose :
A) To replace 'perl -w' by 'use warnings' whenever needed; it's the
recommanded modern syntax anyway.
B) To let Configure choose as now for build-time [git users]. That's
what Configure is for: to test and find good defaults on the build machine
so that build succeeds.
C) For install, we can either
* provide
Configure --installed-perl=<run-time perl binary>
with Configure's current $perl as a default [ build-machine = target is
a sensible default ]. Of course, "/usr/bin/env perl" is (now) a valid value;
or
* simply use directly
#! /usr/bin/env perl
The first lets the packager choose, the second lets the user choose (via
his PATH environment variable) [and assumes that /usr/bin/env exists on
target]
The first one has an edge since
- by default, it behaves as now and won't break anything
- it gives more control to the packager, we make no assumption about his
target system. And users tend to have broken PATHs now and then (e.g.
on Windows).
OK ?
Cheers,
K.B.
--
Karim Belabas, IMB (UMR 5251) Tel: (+33) (0)5 40 00 26 17
Universite de Bordeaux Fax: (+33) (0)5 40 00 69 50
351, cours de la Liberation http://www.math.u-bordeaux.fr/~kbelabas/
F-33405 Talence (France) http://pari.math.u-bordeaux.fr/ [PARI/GP]
`