On 02/21/2013 11:05 AM, Daniel J. Luke wrote:
On Feb 21, 2013, at 10:05 AM, Bruce Miller <[email protected]> wrote:
With MacPort's perl 5.12, the executable is installed in
  /opt/local/libexec/perl5.12/sitebin
which is *NOT* where people expect to find programs.
And it's NOT a directory people want to maintain in
their $PATH.

why? Why would people care whether they have /opt/local/bin or 
/opt/local/libexec/perl5.12/sitebin or /my/nonstandard/macports/prefix/bin in 
their $PATH?

People care if they have to maintain $PATH themselves,
and then they have to keep track of the versions of Perl
and whatever else they're using so that the appropriate
versions appear in the $PATH.

And, let's be frank; Macs cater (wisely, perhaps) to
a group of users who don't know about, or want to know about, $PATH.

This is all due to a configuration change with MacPort's perl,
and there's a ticket about this
  https://trac.macports.org/ticket/36980

well, my read of that ticket is that 'libexec' isn't really the right place

So, should we file a new ticket that is more specific?

The reason for the configuration change
is to achieve the noble goal of being able
to install multiple versions of Perl, and
multiple versions of software running under
those Perls.

yeah it's a version specific directory for things to install into (could have 
been ${prefix}/bin/perl5.12/ or something like that instead)

With the minor cost that
_nothing_ runs.

not really, it all runs fine - you just have to deal with $PATH or use the full 
path to the script you want to run.

Well, for half my mac users it doesn't run.

I've tried, on the above ticket, to suggest
that the approach used may not be the best one;
or at any rate, please tell me a workaround.
I only got a vague answer about symlinks
(which doesn't really solve much).

symlinks would be the 'normal' macports way to solve this (ie one would install 
the perl module via MacPorts, it would install the scripts into the 
perl-specified location that you hate, and you could optionally create symlinks 
in ${prefix}/bin).

  What is the suggested way to install perl scripts
under Macports?

Using macports ;-)

Sure, although I'm sadly behind in getting an official release,
I _do_ have a portfile....

But are you seriously saying that the Perl that comes with MacPorts
shouldn't be expected to work with non-macports Makes or CPAN or...?

Even if I have the portfile adjusted, it would be nice
if people could check out a more recent version of
my software from svn.  Now I'll grant that svn
isn't for the most naive user.  But if I have to add
"Now scan through the meg of log data looking for where
the damn thing got installed _this_ time",
it starts to bet pretty inconvenient.

How should I modify my Makefile.PL?


you shouldn't, you should modify your Portfile.

So the Perl really only supports MacPorts,
and shouldn't be expected for general use?

How about you configure Perl so that Portfiles will
deal with all the versioning magic and hide things where
you want.  But a plain old Makefile.PL will just do the
Right Thing.
Would that be workable?

No, I guess I can answer that myself; you've got the
executables being installed in two different places,
potentially both on the $PATH, which is what I'm trying
to avoid.  So, nevermind that.

As an aside, I personally don't feel that the benefits of having multiple perl 
versions available is worth it - I think we would be better served by just 
pushing the current stable perl...

I can't disagree.

--
Daniel J. Luke
+========================================================+
| *---------------- [email protected] ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
|   Opinions expressed are mine and do not necessarily   |
|          reflect the opinions of my employer.          |
+========================================================+




_______________________________________________
macports-users mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-users

Reply via email to