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
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
[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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 -
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
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
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
28 matches
Mail list logo
