PKG_PROG_PKG_CONFIG on MacOSX 10.5.8
I am building libsndfile from git on MacOSX 10.5.8. I know we have a port; I am experimenting with the source. Building from the source needs ./autogen.sh to be run. That's when I run into a problem: Script started on Wed Feb 20 21:41:40 2013 hans@mac:libsndfile$ ./autogen.sh -n checking for autogen ... yes -n checking for autoconf ... yes -n checking for automake ... yes -n checking for libtool ... glibtoolize -n checking for pkg-config ... yes -n checking for python ... yes Generating configuration files for libsndfile, please wait ... aclocal -I M4 configure.ac:297: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd M4/extra_pkg.m4:105: PKG_CHECK_MOD_VERSION is expanded from... configure.ac:297: the top level configure.ac:302: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:302: the top level configure.ac:305: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:305: the top level configure.ac:314: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:314: the top level configure.ac:315: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:315: the top level configure.ac:345: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:345: the top level glibtoolize --automake --force autoheader configure.ac:297: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd M4/extra_pkg.m4:105: PKG_CHECK_MOD_VERSION is expanded from... configure.ac:297: the top level configure.ac:302: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:302: the top level configure.ac:305: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:305: the top level configure.ac:314: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:314: the top level configure.ac:315: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:315: the top level configure.ac:345: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:345: the top level automake --add-missing configure.ac:297: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd M4/extra_pkg.m4:105: PKG_CHECK_MOD_VERSION is expanded from... configure.ac:297: the top level configure.ac:302: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:302: the top level configure.ac:305: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:305: the top level configure.ac:314: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:314: the top level configure.ac:315: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:315: the top level configure.ac:345: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:345: the top level autoconf configure.ac:297: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd M4/extra_pkg.m4:105: PKG_CHECK_MOD_VERSION is expanded from... configure.ac:297: the top level configure.ac:302: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:302: the top level configure.ac:305: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:305: the top level configure.ac:314: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:314: the top level configure.ac:315: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:315: the top level configure.ac:345: warning: PKG_PROG_PKG_CONFIG is m4_require'd but not m4_defun'd configure.ac:345: the top level I _do_ have pkg-config installed, and is in my PATH: hans@mac:libsndfile$ pkg-config --version 0.27.1 ./configure is produced, but is unusable: ./configure: line 26359: PKG_PROG_PKG_CONFIG: command not found ./configure: line 26374: syntax error near unexpected token `FLAC_CFLAGS,' ./configure: line 26374: `_PKG_CONFIG(FLAC_CFLAGS, cflags, flac = 1.2.1)' Upstream says this is likely a problem with my pkgconfig: On Feb 21 11:28:28, er...@mega-nerd.com wrote: I _do_ have pkg-config installed, and is in my PATH: hans@mac:libsndfile$ pkg-config --version 0.27.1 ./configure is produced, but is unusable: ./configure: line 26359: PKG_PROG_PKG_CONFIG: command not found ./configure: line 26374: syntax error near unexpected token `FLAC_CFLAGS,' ./configure: line 26374: `_PKG_CONFIG(FLAC_CFLAGS, cflags, flac = 1.2.1)' What could be causing this? That M4 macro should get installed with pkg-config. Not sure why its not on your system. Could someone who knows the pkg-config internals please enlighten me on this? Is it really the case that our pkg-config (as installed by devel/pkgconfig) does not have the PKG_PROG_PKG_CONFIG macro? Jan
Re: UNIX commands font
On Feb 13 18:59:45, lar...@macports.org wrote: On Feb 13, 2013, at 6:23 PM, Alejandro Imass aim...@yabarana.com wrote: Linux tutorials (which are plentiful) will work as well, but remember that Mac OS X is more BSD-like with some Linux accents like the bash shell. I don't see how bash is a Linux-ism. Nobody said linuxism, but the Linuces indeed tend to use the bash shell. Do modern BSDs tend to default to another shell? Yes. In any case, changing shells is trivial. Yes, diverting from the default and subscribing to something incompatible with the default shell is indeed trivial. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Macports stopped working after xcode 4.6 upgrade
[Lawrence Velázquez lar...@macports.org (2013-02-21 06:31:44 UTC)] Very annoying. I've actually filed a Radar about this. http://openradar.appspot.com/radar?id=2620402 Good. (Should this be in the FAQ?) Considering that we don't recommend using /etc/paths or /etc/paths.d anywhere, I'm not sure it needs to be. The reason would be to inform people who know about these, or discover them, may want to use them in the way I suggested. But if it doesn't satisfy the F in FAQ, then perhaps it should not be included. Tha balancing act between supplying too little information and too much is always tricky. – Harald ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: parental internet filter from MacPorts
On Feb 19 21:38:06, guanoape...@gmx.ch wrote: Is there a black list for Tarot and other Black magic? I took the liberty of creating one for you: Tarot Black Magic My customer wishes internet filter based on Catholic Church morale. I assume your customer is demented, or at least cannot be bothered to raise his kids. After all, we have technology. In that case, there is a lot of companies willing to take your customer's money in exchange for keeping his soul pure on the internet. If he merely wants people to stop using condoms, there are entire websites dedicated to petitions. Any recommendations? Slay a black goat and spill its blood on your customer's DNS resolver. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: UNIX commands font
Indeed, bash is the default shell on linux ... by default. You can change it, and for instance, certain database softwares will require that either csh or ksh be the login shell. I don't see how bash is a Linux-ism. I see the point: bash tends to be associated with Linux. However, you may run bash on pretty much any *nix. Do modern BSDs tend to default to another shell? Yes. FreeBSD defaults to csh, OpenBSD and NetBSD to ksh. In any case, changing shells is trivial. Easier than to pronounce: chsh. Yes, diverting from the default and subscribing to something incompatible with the default shell is indeed trivial. That's why well-written scripts start with a SheBanghttp://en.wikipedia.org/wiki/Shebang_(Unix): rule of scriptisation #287, never assume anything about the environment your script will run on. -- Jean Gobin, CCENT, CCNA, CCNA Security http://newsfromjean.blogspot.com/ ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: PKG_PROG_PKG_CONFIG on MacOSX 10.5.8
On Feb 21, 2013, at 3:06 AM, Jan Stary h...@stare.cz wrote: Could someone who knows the pkg-config internals please enlighten me on this? Is it really the case that our pkg-config (as installed by devel/pkgconfig) does not have the PKG_PROG_PKG_CONFIG macro? Looks defined to me. From /opt/local/share/aclocal/pkg.m4, which is provided by pkgconfig @0.27.1_2: # PKG_PROG_PKG_CONFIG([MIN-VERSION]) # -- AC_DEFUN([PKG_PROG_PKG_CONFIG], [m4_pattern_forbid([^_?PKG_[A-Z_]+$]) m4_pattern_allow([^PKG_CONFIG(_(PATH|LIBDIR|SYSROOT_DIR|ALLOW_SYSTEM_(CFLAGS|LIBS)))?$]) m4_pattern_allow([^PKG_CONFIG_(DISABLE_UNINSTALLED|TOP_BUILD_DIR|DEBUG_SPEW)$]) AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility]) AC_ARG_VAR([PKG_CONFIG_PATH], [directories to add to pkg-config's search path]) AC_ARG_VAR([PKG_CONFIG_LIBDIR], [path overriding pkg-config's built-in search path]) if test x$ac_cv_env_PKG_CONFIG_set != xset; then AC_PATH_TOOL([PKG_CONFIG], [pkg-config]) fi if test -n $PKG_CONFIG; then _pkg_min_version=m4_default([$1], [0.9.0]) AC_MSG_CHECKING([pkg-config is at least version $_pkg_min_version]) if $PKG_CONFIG --atleast-pkgconfig-version $_pkg_min_version; then AC_MSG_RESULT([yes]) else AC_MSG_RESULT([no]) PKG_CONFIG= fi fi[]dnl ])# PKG_PROG_PKG_CONFIG vq ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Broken perl configuration
Hello folks; I'm new here, and actually only seldom a mac user, but I do develop software that colleagues run -- or used to run on -- a mac. The software uses the standard Makefile.PL/ MakeMaker set up to build install the executable scripts in a standard place. That is, it NOWHERE indicates which directory to install to, it installs wherever the perl installation says to. Until recently that was /opt/local/bin, which is in most mac user's, or at least most macports user's, $PATH. 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. It looks like all normal Perl scripts, including software installed from CPAN, are affected. 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 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. With the minor cost that _nothing_ runs. 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). And finally someone suggests that this mailing list is a better place to ask or report bugs than the bug tracker. S: What is the suggested way to install perl scripts under Macports? How should I modify my Makefile.PL? Thanks; bruce ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: UNIX commands font
On Feb 21, 2013, at 4:02 AM, Jean Gobin jeanfgo...@gmail.com wrote: FreeBSD defaults to csh, OpenBSD and NetBSD to ksh. Up until recently ?? Tiger maybe?? ... OSX also defaulted to ksh. T.T.F.N. William H. Magill # iMac11,3 Core i7 [2.93GHz - 8 GB 1067MHz] OS X 10.8.2 # MacBook Pro4.1 Core 2 Duo [2.5GHz - 4GB 667] OS X 10.6.8 # Macmini6,1 Intel Core i5 [2.5 Ghz - 4GB 1600MHz] OS X 10.8.1 mag...@mac.com whmag...@gmail.com ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: UNIX commands font
On 2/21/13 10:15 AM, William H. Magill wrote: Up until recently ?? Tiger maybe?? ... OSX also defaulted to ksh. I don't think that's correct. On 10.2 OS X defaulted to tcsh, then switched to bash on 10.3. I remember this because the syntax of shell scripts was so different. -- Kevin Walzer Code by Kevin/Mobile Code by Kevin http://www.codebykevin.com http://www.wtmobilesoftware.com ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: UNIX commands font
On Thu, Feb 21, 2013 at 10:15 AM, William H. Magill mag...@mac.com wrote: On Feb 21, 2013, at 4:02 AM, Jean Gobin jeanfgo...@gmail.com wrote: FreeBSD defaults to csh, OpenBSD and NetBSD to ksh. Up until recently ?? Tiger maybe?? ... OSX also defaulted to ksh. Pre-Tiger, user accounts had csh, as I understand it. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: UNIX commands font
On Feb 21, 2013, at 10:18 AM, Kevin Walzer k...@codebykevin.com wrote: On 2/21/13 10:15 AM, William H. Magill wrote: Up until recently ?? Tiger maybe?? ... OSX also defaulted to ksh. I don't think that's correct. On 10.2 OS X defaulted to tcsh, then switched to bash on 10.3. I remember this because the syntax of shell scripts was so different. Aha... you are correct. ... I think that while tsch was the default, ksh was also present... or maybe it was ksh configured to be tsch or vice versaor was that zsh? Over the years, I have supported and run on so many different *nixs that I have a whole stable of set-up scripts that configure them all to look the same. Consequently, they all run together anymore -- one of the advantages :) of being retired. T.T.F.N. William H. Magill # iMac11,3 Core i7 [2.93GHz - 8 GB 1067MHz] OS X 10.8.2 # MacBook Pro4.1 Core 2 Duo [2.5GHz - 4GB 667] OS X 10.6.8 # Macmini6,1 Intel Core i5 [2.5 Ghz - 4GB 1600MHz] OS X 10.8.1 mag...@mac.com whmag...@gmail.com ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
About iStumbler
I have been an iStumbler user for many years, lately via MacPorts, and recently have had some folks ask me about it's status. If you visit www.istumbler.net -- it does not support Mountain Lion, and only the beta of iStumbler 100 supports 10.7 Lion. Clearly, the MacPorts implementation runs on 10.8 Mountain Lion. So, the question becomes... 1- is anybody supporting iStumbler anymore? It doesn't look dead -- but it is clearly not current. 2- Is there a sourceforge repository? 3- I note that there is an iStumbler Facebook page which seems to be active. 4- Is twit the only way to contact the author? T.T.F.N. William H. Magill # iMac11,3 Core i7 [2.93GHz - 8 GB 1067MHz] OS X 10.8.2 # MacBook Pro4.1 Core 2 Duo [2.5GHz - 4GB 667] OS X 10.6.8 # Macmini6,1 Intel Core i5 [2.5 Ghz - 4GB 1600MHz] OS X 10.8.1 mag...@mac.com whmag...@gmail.com ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: About iStumbler
1- is anybody supporting iStumbler anymore? It doesn't look dead -- but it
is clearly not current.
Looks like it gets touched up by whomever feels like it:
http://trac.macports.org/log/trunk/dports/aqua/istumbler/Portfile
Note that +use_binary is the default variant, which installs a .app bundle
rather than building anything.
2- Is there a sourceforge repository?
Only the main website is used for obtaining files:
master_sites \
http://www.istumbler.net/downloads/ \
http://www.istumbler.net/archive/release${version}/downloads/
3- I note that there is an iStumbler Facebook page which seems to be active.
In light of the shell emails earlier: people still use Facebook?
4- Is twit the only way to contact the author?
Until you find another method, yes :-)
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Broken perl configuration
On Feb 21, 2013, at 10:05 AM, Bruce Miller bruce.mil...@nist.gov 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?
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
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.
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 ;-)
How should I modify my Makefile.PL?
you shouldn't, you should modify your Portfile.
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...
--
Daniel J. Luke
++
| * dl...@geeklair.net * |
| *-- http://www.geeklair.net -* |
++
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
++
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Broken perl configuration
On 02/21/2013 11:05 AM, Daniel J. Luke wrote:
On Feb 21, 2013, at 10:05 AM, Bruce Miller bruce.mil...@nist.gov 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
++
| * dl...@geeklair.net * |
| *-- http://www.geeklair.net -* |
++
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
++
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Broken perl configuration
On Feb 21, 2013, at 11:37 AM, Bruce Miller bruce.mil...@nist.gov wrote: 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. ... and those people tend to not ever use the terminal ... ;-) If you're going to use the command line, you probably need to know (at least a little) 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? you can, I guess, but I don't know if you'll get any action on it. It might make sense to set vendorbin like we're doing, but leave sitebin alone (allowing people who install outside of macports to shoot themselves in the foot). 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. because there's a bug somewhere, or just because they can't be bothered to use the absolute path or set $PATH? 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...? Your definition of 'work' is different from mine. I'm not saying that, but I don't think that having scripts/binaries installed into a place that isn't in $PATH means that something is broken. 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? Nope, but in general MacPorts (or any package management system) works best when you 'buy in' and just use it for all your install management. -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Broken perl configuration
On Thu, Feb 21, 2013 at 11:37 AM, Bruce Miller bruce.mil...@nist.govwrote: 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. Only if you stick to Apple-approved stuff. MacPorts, despite tacit support from Apple, is an outsider and ultimately can never really integrate seamlessly. (See for another example the discussion about /etc/paths.d / path_helper. And all the stuff about XCode in the FAQ and ProblemHotList.) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Broken perl configuration
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. Only if you stick to Apple-approved stuff. MacPorts, despite tacit support from Apple, is an outsider and ultimately can never really integrate seamlessly. (See for another example the discussion about /etc/paths.d / path_helper. And all the stuff about XCode in the FAQ and ProblemHotList.) Can `perl -V` be parsed to find out where things will be for a given perl? Perhaps adding a parsing of this to your $PATH will help avoid manually typing fullpaths and be a one-time tweak of the $PATH. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Broken perl configuration
On 02/21/2013 11:46 AM, Daniel J. Luke wrote: On Feb 21, 2013, at 11:37 AM, Bruce Miller bruce.mil...@nist.gov wrote: 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. ... and those people tend to not ever use the terminal ... ;-) If you're going to use the command line, you probably need to know (at least a little) about $PATH. Jumping in the deep end! : 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? you can, I guess, but I don't know if you'll get any action on it. It might make sense to set vendorbin like we're doing, but leave sitebin alone (allowing people who install outside of macports to shoot themselves in the foot). I don't know if its really outside of macports; isn't the /opt/local/bin basically only for macports? [I vaguely recall that's not in the path on a stock mac, and needed to be added to run anything from macports] 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. because there's a bug somewhere, or just because they can't be bothered to use the absolute path or set $PATH? Well, firstly after a long email cycle of It don't run and I don't see any errors, we gradually discover that it DID install successfully just somewhere odd. OK, now I know that it will go somewhere odd, so I can save that step in the future. But I still have to tell them to scan the logs to figure out where it went _this_ time! And probably also to suggest that they never run port update (or whatever it is) because everything will break? 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...? Your definition of 'work' is different from mine. I'm not saying that, but I don't think that having scripts/binaries installed into a place that isn't in $PATH means that something is broken. So you do think that people should modify their PATH everytime they install or update software? How would a script installed via a portfile handle this? Is Macports also installing a symlink from a standard place to the version specific place? (and if so how is that different from the normal non-versioned collision). Or does it have some sort of alternatives management going on? (as was mentioned in another response) 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? Nope, but in general MacPorts (or any package management system) works best when you 'buy in' and just use it for all your install management. Completely agree with you. Although it's really only bad (at least in the linux world) when you try to run manually installed software alongside managed versions of the same software. Of course, when I have a nice fresh system install, I can only hold my breath so long until I have to hold my nose and install _something_ from source, or CPAN or... bruce -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Broken perl configuration
Is Macports also installing a symlink from a standard place to the version specific place? (and if so how is that different from the normal non-versioned collision). Or does it have some sort of alternatives management going on? (as was mentioned in another response) The versions of perl are swapped around in PATH with symlinks, like alternatives, via `port select perl [...]`. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Broken perl configuration
On Feb 21, 2013, at 12:09 PM, Bruce Miller bruce.mil...@nist.gov wrote:
It might make sense to set vendorbin like we're doing, but leave sitebin
alone (allowing people who install outside of macports to shoot themselves
in the foot).
I don't know if its really outside of macports;
isn't the /opt/local/bin basically only for macports?
yes. What I'm saying is if you do ${prefix}/bin/perl Makefile.PL make
make install you're installing something into MacPorts' ${prefix} that MacPorts
doesn't know about - it's much better to use 'port' to manage installs and
whatnot for ${prefix}
Your definition of 'work' is different from mine. I'm not saying that, but I
don't think that having scripts/binaries installed into a place that isn't
in $PATH means that something is broken.
So you do think that people should modify their PATH
everytime they install or update software?
How would a script installed via a portfile
handle this? Is Macports also installing
a symlink from a standard place to the version
specific place?
I believe the default behavior is to install a versioned symlink in
${prefix}/bin
(and if so how is that different
from the normal non-versioned collision).
Or does it have some sort of alternatives management
going on? (as was mentioned in another response)
I believe some specific Portfiles will install an unversioned symlink in
${prefix}/bin IFF there isn't already one there.
--
Daniel J. Luke
++
| * dl...@geeklair.net * |
| *-- http://www.geeklair.net -* |
++
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
++
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Broken perl configuration
On 02/21/2013 12:14 PM, Daniel J. Luke wrote:
On Feb 21, 2013, at 12:09 PM, Bruce Miller bruce.mil...@nist.gov wrote:
It might make sense to set vendorbin like we're doing, but leave sitebin alone
(allowing people who install outside of macports to shoot themselves in the
foot).
I don't know if its really outside of macports;
isn't the /opt/local/bin basically only for macports?
yes. What I'm saying is if you do ${prefix}/bin/perl Makefile.PL make
make install you're installing something into MacPorts' ${prefix} that MacPorts doesn't know
about - it's much better to use 'port' to manage installs and whatnot for ${prefix}
Well, I don't quite say that: My instructions for users that want
to mess with svn checkout is simply
perl Makefile.PL
make
(sudo) make install
Under normal circumstances they'd be getting the perl
(with macports, presumably the one isntalled in /opt/local/bin ?)
So, it seems that $prefix IS the one that macports should know about.
Your definition of 'work' is different from mine. I'm not saying that, but I
don't think that having scripts/binaries installed into a place that isn't in
$PATH means that something is broken.
So you do think that people should modify their PATH
everytime they install or update software?
How would a script installed via a portfile
handle this? Is Macports also installing
a symlink from a standard place to the version
specific place?
I believe the default behavior is to install a versioned symlink in
${prefix}/bin
(and if so how is that different
from the normal non-versioned collision).
Or does it have some sort of alternatives management
going on? (as was mentioned in another response)
I believe some specific Portfiles will install an unversioned symlink in
${prefix}/bin IFF there isn't already one there.
--
Daniel J. Luke
++
| * dl...@geeklair.net * |
| *-- http://www.geeklair.net -* |
++
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
++
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Broken perl configuration
On Feb 21, 2013, at 12:30 PM, Bruce Miller bruce.mil...@nist.gov wrote:
yes. What I'm saying is if you do ${prefix}/bin/perl Makefile.PL make
make install you're installing something into MacPorts' ${prefix} that
MacPorts doesn't know about - it's much better to use 'port' to manage
installs and whatnot for ${prefix}
Well, I don't quite say that: My instructions for users that want
to mess with svn checkout is simply
perl Makefile.PL
make
(sudo) make install
Under normal circumstances they'd be getting the perl
(with macports, presumably the one isntalled in /opt/local/bin ?)
So, it seems that $prefix IS the one that macports should know about.
yes, you are telling your users to install stuff into ${prefix} without using
the 'port' command. This means they are installing files that MacPorts doesn't
know about.
--
Daniel J. Luke
++
| * dl...@geeklair.net * |
| *-- http://www.geeklair.net -* |
++
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
++
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Broken perl configuration
Sorry for replying out-of-thread; I just got myself subscribed. Some comments:
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?
Maybe they don't care what their $PATH looks like, but I don't think that's the
right issue. The fact is that $PREFIX/libexec is not in the standard MacPorts
user's $PATH, and I don't think there's a mechanism in place to adjust those
$PATH entries in order to favor, say, $PREFIX/libexec/perl5.14.2/sitebin over
perl5.14.1/sitebin whenever Perl5 gets a version bump. Or if there is, it's
not getting done.
What is the suggested way to install perl scripts under Macports
Using macports ;-)
... in general MacPorts (or any package management system) works best when
you 'buy in' and just use it for all your install management.
It might make sense to set vendorbin like we're doing, but leave sitebin
alone (allowing people who install outside of macports to shoot themselves in
the foot)
True, but in addition to what Bruce mentioned, the p5-* Macports namespace does
not cover all of CPAN (I'm not arguing that it should). Nor is it constantly
updated. Witness p5-devel-cover @0.820.0 and all the updates that have taken
place since then (http://backpan.perl.org/authors/id/P/PJ/PJCJ/). I haven't
tried to install p5-devel-cover from MacPorts, so I don't know where it puts
its executables, but it is probably into libexec. Which means that if someone
installs p5-devel-cover and then tries to run 'cover', they will get a 'command
not found'. But I would be very interested if I were wrong on that.
I understand that by installing CPAN modules into the macports filespace,
macports is not aware of those modules. So every time MacPorts updates my Perl
I go back to CPAN to update. The alternative is telling CPAN to install to
~/local/perl5 or wherever. But I think (but have not tested) that the same
problem will crop up when say 5.12 gets deactiviated and suddenly there is
nothing in my personal 5.14 site_perl. So it's a horse apiece.
Can `perl -V` be parsed to find out where things will be for a given perl?
Perhaps adding a parsing of this to your $PATH will help avoid manually
typing fullpaths and be a one-time tweak of the $PATH.
Sort of. e.g.,
perl -MConfig -wE 'say Perl module executable install location is .
($Config::Config{sitebin}=~/libexec/ ? not ok : ok) ;'
vs. the same thing but with /usr/bin/perl
It is possible to override all this libexec stuff with
perl Makefile.PL INSTALLSITEBIN=/opt/local/bin INSTALLSITESCRIPT=/opt/local/bin
and just trust (hope?) that the version being installed should be overwriting
the old version. Which is effectively what the old behavior of MacPorts Perl
was.
cheers,
Derek
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Broken perl configuration
On 02/21/2013 12:33 PM, Daniel J. Luke wrote:
On Feb 21, 2013, at 12:30 PM, Bruce Millerbruce.mil...@nist.gov wrote:
yes. What I'm saying is if you do ${prefix}/bin/perl Makefile.PL make
make install you're installing something into MacPorts' ${prefix} that MacPorts doesn't know
about - it's much better to use 'port' to manage installs and whatnot for ${prefix}
Well, I don't quite say that: My instructions for users that want
to mess with svn checkout is simply
perl Makefile.PL
make
(sudo) make install
Under normal circumstances they'd be getting the perl
(with macports, presumably the one isntalled in /opt/local/bin ?)
So, it seems that $prefix IS the one that macports should know about.
yes, you are telling your users to install stuff into ${prefix} without using
the 'port' command. This means they are installing files that MacPorts doesn't
know about.
Sure, macports doesn't know about the stuff that was installed;
I thought you were saying installing into a directory that
macports doesn't know about. It knows about the directory,
but it doesn't know about the stuff.
Whatever
As much as you or I may like to stay within managed packages,
you never can keep up with CPAN and shouldn't try.
And occasionally, there's really useful stuff that ought
to be usable without jumping through hoops.
Thanks;
bruce
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Broken perl configuration
On 02/21/2013 11:37 AM, Bruce Miller wrote: 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? In view of all the comments, maybe I should re-pose the question: When the perl Makefile.PL; make; make install sequence is invoked within a Portfile, use a perl with appropriate flags/switches such that it will use the use the versioned directories. Then Portfiles will work as you want them to. But a plain perl used from commands like perl Makefile.PL will use the more common installation directories, like macports used to do, and every other OS does. bruce ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Broken perl configuration
On Feb 21, 2013, at 17:19, Bruce R Miller wrote:
As much as you or I may like to stay within managed packages,
you never can keep up with CPAN and shouldn't try.
We can and do try to keep up with CPAN actually. That's why there are almost
1000 ports whose names begin with p5-. If any of them are out of date, or if
we're missing one you need, please file a ticket. As has been said, installing
things into ${prefix}, without using MacPorts, where that be by running make
install or some cpan command or manually copying files there is something we
recommend users not do.
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Broken perl configuration
On Feb 21, 2013, at 6:19 PM, Bruce R Miller bruce.mil...@nist.gov wrote:
But a plain perl used from commands like
perl Makefile.PL
will use the more common installation directories,
like macports used to do, and every other OS does.
which just exchanges the specific behavior you don't want for a different
broken behavior (think about what happens if/when you upgrade your macports
perl but you have something in ${prefix}/bin that you installed locally that is
now missing components...)
--
Daniel J. Luke
++
| * dl...@geeklair.net * |
| *-- http://www.geeklair.net -* |
++
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
++
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
