Home > Archive > PERL Beginners > December 2007 > configuring startperl during make ?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
configuring startperl during make ?
|
|
| Mayuresh Nirhali 2007-12-28, 8:00 am |
| Hello,
During DBI building, MakeMaker uses the fixin() method to write the shebang
line for all the perl scripts that will be installed.
The path on my machine is /usr/perl/5.8.4/bin/perl. I also have
/usr/perl5/bin/perl which is *currently* pointing to the same 5.8.4 perl,
but this generic version independent path helps me pointing to the latest
version all the time.
I would like to have all the shebang lines replaced to the generic
/usr/perl5/bin/perl. Now, MakeMaker's fixin method seems to be
using $Config:{startperl}. If my understanding is right, startperl is
populated during installation (correct me if I am wrong here), Is there a
way to change this parameter to point to the version independent perl path
??
Thanks
Mayuresh
| |
| Tom Phoenix 2007-12-28, 7:01 pm |
| On Dec 28, 2007 12:39 AM, Mayuresh Nirhali <mayureshnirhali@gmail.com> wrote:
> During DBI building, MakeMaker uses the fixin() method to write the shebang
> line for all the perl scripts that will be installed.
> The path on my machine is /usr/perl/5.8.4/bin/perl. I also have
> /usr/perl5/bin/perl which is *currently* pointing to the same 5.8.4 perl,
> but this generic version independent path helps me pointing to the latest
> version all the time.
>
> I would like to have all the shebang lines replaced to the generic
> /usr/perl5/bin/perl. Now, MakeMaker's fixin method seems to be
> using $Config:{startperl}. If my understanding is right, startperl is
> populated during installation (correct me if I am wrong here), Is there a
> way to change this parameter to point to the version independent perl path
> ??
The value of $Config{startperl} comes from your Config.pm file, which
in turn was built when your perl binary was built. In general, if you
want Config.pm to say something different, you should rebuild and
reinstall perl and everything that comes with it. If you've changed
some of the really important things in Config.pm, you may need to
rebuild some or all of the extra modules you've installed, too.
On the other hand, that's a lot of work considering the result. (Do
you want or need to alter the headings on scripts installed with perl
or other modules?) You'll re-install hundreds of files, but only a few
of them are only slightly changed. If you don't need to rebuild perl
for another reason, you might be able to get away with merely editing
the Config.pm file. That's not always appropriate, but in this case it
might be the right answer.
On the gripping hand, another right answer might be to hack up a
utility to munge the shebang lines. How hard could it be? Somebody is
probably making a one-liner to do that right now....
Good luck with it!
--Tom Phoenix
Stonehenge Perl Training
| |
| Mayuresh Nirhali 2007-12-29, 7:59 am |
| Thanks Tom,
I agree that it aint a big deal to write a oneliner hacking the shebang
line, but, thought overriding some variables during the MakeMaker make would
be more cleaner. I looked around for some information and finally ended up
sending this mail.
In my make environment surrounding the DBI compilation, I have a perl script
which is used during 'make install' instead of default install binary. I
realized that MakeMaker will ignore such INSTALL variable overriding. The
ideal place for that onliner in my env is to be included in this install
perl script, but that will not work as I mentioned earlier. any ideas here
??
cheers
Mayuresh
On Dec 29, 2007 1:13 AM, Tom Phoenix <tom@stonehenge.com> wrote:
> On Dec 28, 2007 12:39 AM, Mayuresh Nirhali <mayureshnirhali@gmail.com>
> wrote:
>
> shebang
> latest
> a
> path
>
> The value of $Config{startperl} comes from your Config.pm file, which
> in turn was built when your perl binary was built. In general, if you
> want Config.pm to say something different, you should rebuild and
> reinstall perl and everything that comes with it. If you've changed
> some of the really important things in Config.pm, you may need to
> rebuild some or all of the extra modules you've installed, too.
>
> On the other hand, that's a lot of work considering the result. (Do
> you want or need to alter the headings on scripts installed with perl
> or other modules?) You'll re-install hundreds of files, but only a few
> of them are only slightly changed. If you don't need to rebuild perl
> for another reason, you might be able to get away with merely editing
> the Config.pm file. That's not always appropriate, but in this case it
> might be the right answer.
>
> On the gripping hand, another right answer might be to hack up a
> utility to munge the shebang lines. How hard could it be? Somebody is
> probably making a one-liner to do that right now....
>
> Good luck with it!
>
> --Tom Phoenix
> Stonehenge Perl Training
>
--
Work like you don't need money !
Love like you've never been hurt !!
Dance like noone's watching you !!!
| |
| Tom Phoenix 2007-12-30, 7:01 pm |
| On Dec 28, 2007 9:10 PM, Mayuresh Nirhali <mayureshnirhali@gmail.com> wrote:
> In my make environment surrounding the DBI compilation, I have a perl script
> which is used during 'make install' instead of default install binary. I
> realized that MakeMaker will ignore such INSTALL variable overriding. The
> ideal place for that onliner in my env is to be included in this install
> perl script, but that will not work as I mentioned earlier. any ideas here
> ??
I'm not sure what's really going on here. It's usually straightforward
to install a module; if you have to write code just to get a module
installed, that's quite UNusual. Is your site that much different than
every other place where these modules get installed? I have the
feeling that you haven't said yet what makes your situation unusual,
and that may make all the difference.
Cheers!
--Tom Phoenix
Stonehenge Perl Training
|
|
|
|
|