ExtUtils::MakeMaker can take care of that:
EXE_FILES
Ref to array of executable files. The files will be copied to the INST_SCRIPT directory. Make realclean will delete them from there again.
If your executables start with something like #!perl or #!/usr/bin/perl MakeMaker will change this to the path of the perl 'Makefile.PL' was invoked with so the programs will be sure to run properly even if perl is not in /usr/bin/perl.
Not sure if and how other installers handle it.
| [reply] |
We had a similar discussion a while back, see 897028. Hope that helps...
Sorry for any bad spelling, broken formatting and missing code examples. I broke my left hand and i'm doing the best i can here...
| [reply] |
Within the code itself, the usual recommendation is to use
#!/usr/bin/env perl
This will cause it to run using the first perl found in the executing user's $PATH. | [reply]
[d/l]
[select] |
The "env perl" probably won't provide what I want, as it provides the first perl binary found in a series of dirs, but what I want is the location of installer's binary.
| [reply] |
First off, which OS do you and your colleagues use? The majority of my perl XP comes from OS X and linux, so if you are using Windows, I don't know if the following will help at all.
I use perlbrew and #!/usr/bin/env perl always works for me. If using perlbrew is impractical, why not add the desired perl install to the beginning of the $PATH. It seems like this should always be the case and if it isn't, the user will be overriding the #! anyway if they directly call the perl they want to use.
| [reply]
[d/l] |
#!/usr/bin/env perl is not portable. Some more exotic systems have /bin/env instead. The correct solution, as already stated by another monk, is #!perl and let ExtUtils::MakeMaker sort it out for you.
| [reply]
[d/l]
[select] |
What if I don't use Extutil::MakeMaker?
I get used to Module::Build.
| [reply] |
llancet,
Usually, we wrote "#!/usr/bin/perl" at top of scripts, as perl is usually being installed there.
However, if I provide a script within a CPAN package, there comes a problem: somebody (like me) may have another perl ....
When I install any Perl package (CPAN or other), I call it directly with:
myperl -MCPAN -e 'install "..."'
What I refer to as 'myperl' is the exact Perl version where I want the package installed. Otherwise, it won't install to the correct directory structure.
Obviously you could open the CPAN shell for multiple installs, etc.
But you may be worrying about something that just won't happen. When a user calls your CPAN package, Perl is already running so your shebang is not used. If your package isn't in the correct directory, it will fail at compile or runtime depending on how it's called (use/require/BEGIN).
If you are the sysadmin then you will install it where your clients can get to it!
Good Luck!
"Well done is better than well said." - Benjamin Franklin
| [reply]
[d/l] |