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]
`