Re: env_helper
Very weird, I was working on path_helper yesterday!
I like the port env idea.
We need rpath and lpath -- to add to the beginning or end of a PATH
Here's what we use at work:
#!/bin/ksh
#
# Script to define path-related manipulation functions. Must be run with .
#
# Revision history: 1.0 MRM 940204 Functions from Chris Flatters' .profile
# with permission
# 1.1 MRM 950817 Corrections updates from Chris
# Define some useful functions for setting paths:
# PrependPath pathname dir makes dir the first element of
# the search path stored in pathname unless the first element
# of the path is the current working directory (.), in which case
# dir becomes the second element of the search path, or unless
# dir is already an element of the search path, in which case
# the search path is left unchanged.
function PrependPath
{
typeset path
eval path=\${${1}}
if [ -n $path ]
then
case $path in
${2}*);;# Directory already at beginning
*:${2}*) ;;# Directory already present
.:*) eval ${1}=.:${2}:${path##.:} ;;
*) eval ${1}=${2}:$path ;;
esac
else eval export ${1}=${2}
fi
}
# PostpendPath pathname dir makes dir the last element of
# the search path stored in pathname unless the last element
# of the path is the current working directory (.), in which case
# dir becomes the second-last element of the search path, or unless
# dir is already an element of the search path, in which case
# the search path is left unchanged.
function PostpendPath
{
typeset path
eval path=\${${1}}
if [ -n $path ]
then
case $path in
${2}*);; # Directory already at beginning
*:${2}*) ;; # Directory already present
*:.) eval ${1}=${path%%:.}:${2}:. ;;
*) eval ${1}=$path:${2} ;;
esac
else eval export ${1}=${2}
fi
}
# PrependXPath pathname dir prepends a set of pathnames
# for XtResolvePathname rooted at dir to the path stored
# in pathname. This is intended for use with XFILESEARCHPATH
# etc.
function PrependXPath
{
typeset dir
eval dir=${2}
# Items suggested in X11R6 man page for XtResolvePathname
PrependPath ${1} ${dir}/%T/%N%S
PrependPath ${1} ${dir}/%l/%T/%N%S
PrependPath ${1} ${dir}/%L/%T/%N%S
PrependPath ${1} ${dir}/%T/%N%C%S
PrependPath ${1} ${dir}/%l/%T/%N%C%S
PrependPath ${1} ${dir}/%L/%T/%N%C%S
}
# PostpendXPath pathname dir appends a set of pathnames
# for XtResolvePathname rooted at dir to the path stored
# in pathname. This is intended for use with XFILESEARCHPATH
# etc.
function PostpendXPath
{
typeset dir
eval dir=${2}
# Items suggested in X11R6 man page for XtResolvePathname
PostpendPath ${1} ${dir}/%L/%T/%N%C%S
PostpendPath ${1} ${dir}/%l/%T/%N%C%S
PostpendPath ${1} ${dir}/%T/%N%C%S
PostpendPath ${1} ${dir}/%L/%T/%N%S
PostpendPath ${1} ${dir}/%l/%T/%N%S
PostpendPath ${1} ${dir}/%T/%N%S
}
# PrependUIDPath pathname dir prepends a set of pathnames
# for the Mrm functions rooted at dir to the path stored
# in pathname. If the path begins with %U%S then the new
# entries will be inserted following %U%S
function PrependUIDPath
{
typeset dir
typeset path
typeset pcu
eval dir=${2}
eval path=\${${1}}
pcu=%U # To get around SCCS %U% keyword substitution
case $path in
%U?S*)eval ${1}=${path#\%U\%S}
eval path=\${${1}}
eval ${1}=${path#:}
PrependPath ${1} ${dir}/%T/$pcu%S
PrependPath ${1} ${dir}/%l/%T/$pcu%S
PrependPath ${1} ${dir}/%L/%T/$pcu%S
eval ${1}=$pcu%S:\${${1}}
;;
*)PrependPath ${1} ${dir}/%T/$pcu%S
PrependPath ${1} ${dir}/%l/%T/$pcu%S
PrependPath ${1} ${dir}/%L/%T/$pcu%S
;;
esac
}
# PostpendUIDPath pathname dir appends a set of pathnames
# for the Mrm functions rooted at dir to the path stored
# in pathname.
function PostpendUIDPath
{
typeset dir
typeset pcu
eval dir=${2}
pcu=%U # Get around SCCS %U% substitution
PostpendPath ${1} ${dir}/%L/%T/$pcu%S
PostpendPath ${1} ${dir}/%l/%T/$pcu%S
PostpendPath ${1} ${dir}/%T/$pcu%S
}
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: New XCode version
On Jul 13, 2008, at 10:23 AM, William Davis wrote: FYI: a new version of XCode dated 11 July 08 is available on ADC. Interestingly, it includes gcc 4.2 as well as 4.0. Interesting; it's probably the iPhone SDK version that shipped last Friday. Apple has been great about posting the GCC 4.0 patches associated with the various iPhone SDK releases, but they haven't released the patches for GCC 42 (last gcc-4.2 patch was 5553). See http://www.opensource.apple.com/darwinsource/tarballs/other/ http://r.research.att.com I expect that they will eventually release newer patches, I could really use them! I am *almost* done with a full quad-architecture (ppc,intel,32-bit,64- bit) GCC 4.2 that incorporates changes from ATT so that gfortran can be built as well as Objective-C. But it requires testing. Here's what I've got so far... so close... Portfile Description: Binary data make-universal-gcc.sh Description: Binary data I'd really like newer patches from Apple, because Apple builds before have an inline-assembly bug (rdar://5705060) - boyd Boyd Waters Scientific Programmer National Radio Astronomy Observatory https://wikio.nrao.edu/bin/view/Software/ObtainingCasaMacIntel ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: gcc 4.2 on 10.4 tiger: ld: unknown flag: -compatibility_version
On Jul 13, 2008, at 8:44 PM, Peter O'Gorman wrote:
Easiest solutions are to update the libtool version in the package
that
you are attempting to build (autoreconf -fi) or simple sed out ${wl}
before the -compatibility_version etc in ltmain.sh
This is what I committed when the gcc build problem was reported:
http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=eee885d7c58eea2b9fef52798ef2a1e7adb9be4f
Using sed to remove the '${wl}' from verstring in ltmain.sh before
configure should work fine:
sed -e '/verstring=/s/\${wl}//g' ltmain.sh ltmain.fixed; mv
ltmain.fixed ltmain.sh
Peter:
This explanation helps me a *lot*, thanks!
In our collection of ~50 MacPorts, I've had to twiddle libtool in a
number of them. I just applied a patch to the libtool script that
comes with the package, essentially what your sed example does. Now I
know why.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [Pythonmac-SIG] 64-bit Python?
On Jul 1, 2008, at 8:29 AM, Blair Zajac wrote: How would a quad-architecture build work with other C/C++ modules? I haven't tested other modules yet; I'm still building quad- architecture GCC 4.2.4 with ATT and Apple patches. Got that MacPorted yesterday after two weeks' work... now we have a gfortran that plays nice with Apple-patched GCC, I think. Having a 64-bit itself would be nice, but that would require all Python modules also be compiled in 64-bit, such as Qt, Subversion, anything that is a C/C++ package on its own that has a Python module. So I think the ramifications of going to a pure 64-bit Python would be large and would have to be decided by MacPorts group as a whole if we want to move in that direction. Yes, I am hoping to build up our local NRAO/CASA package toolchain quad-architecture. I don't know how far I can get. I already have an Intel 32/64-bit Qt; that's TrollTech's Cocoa version (expected to release as Qt 4.5). I would need to build all of SciPy quad-arch to make this fly... - boyd Boyd Waters Scientific Programmer National Radio Astronomy Observatory Socorro, New Mexico ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Variables, options, and keys -- oh my!
On Jun 19, 2008, at 10:42 PM, Ryan Schmidt wrote: But I manage a build system that uses 30-40 ports, and I've had to tweak individual portfiles rather than modify a global parameter. Why do you need to tweak the portfiles? What's the matter with them the way they're written? If they're not working, please report bugs so we can fix the portfiles so everyone can benefit from the fixes. Well, you are absolutely right... there's no use in thinking about vague things. I'll post some bugs. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: gcc-4.2 for Leopard
On Jun 18, 2008, at 10:11 PM, Ryan Schmidt wrote: If there's an option you want to have set globally, it should be in the macports.conf So if I set configure.compiler in macports.conf, it gets picked up unless overridden in the Port file? Is that documented anywhere? ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Variables, options, and keys -- oh my!
On Jun 19, 2008, at 5:57 PM, Rainer Müller wrote: Boyd Waters wrote: So if I set configure.compiler in macports.conf, it gets picked up unless overridden in the Port file? There is no option yet in macports.conf, that's what I am proposing here. Currently you can only use it from command line, but this will override configure.compiler from the Portfile. Ok, thanks. I thought I was missing something really fundamental. So here's a fundamental question: why can't we set port parameters in the macports.conf? Then if the option is set in the Portfile, it overrides what is in the macports.conf. And if the user specifies it on the command line, that overrides anything in either of them. If the option isn't set anywhere, use a reasonable default value. Most of my users never look inside that macports.conf file, they are not aware it exists. They would be safe. But I manage a build system that uses 30-40 ports, and I've had to tweak individual portfiles rather than modify a global parameter. - boyd Boyd Waters Scientific Programmer National Radio Astronomy Observatory Socorro, New Mexico ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: gcc-4.2 for Leopard
Is there some way to specify a global set of command-line arguments? You can set EXTRA_ENV in macports.conf, but not command-line args? I've had to hack portconfigure.tcl in order to get what I want. Is there a better way? On Jun 18, 2008, at 4:22 PM, Rainer Müller wrote: Ryan Schmidt wrote: I don't want to introduce yet more ways for two users to think they have installed the same thing but in fact they haven't. You're just creating more support headaches that way. It is already possible to choose another compiler from the command line: $ sudo port install portname configure.compiler=gcc-4.2 So adding a new option in macports.conf just moves this from the command line to a config file. But I can understand your concerns that users might be blindly choosing gcc-4.2 (that's the one with the greater number!) without knowledge. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: Building python2.5 extensions under MacPorts
I have a Python 2.5.2 port that builds just fine with PyQt4. I also have one that builds quad-architecture universal (with quad- architecture Qt4). I've only tested it on Leopard, and I'm working on it now with another Mac, and testing Tiger as well. I'll post the port to this list later tonight. On May 12, 2008, at 7:14 PM, Blair Zajac wrote: Robert Liesenfeld wrote: Anyone built any Python extensions, specifically for Python 2.5? I'm trying to make a py25-pyqt4 port, and i'm running into trouble with building the extension .so's; they keep getting linked against the system (i.e. Apple-provided) Python, not the MacPorts Python: The python 2.5 provided by MacPorts is not a framework Python, which I'm pretty sure is required by PyQt. There's a thread that was started last week about getting Python 2.5 to a Framework build. Regards, Blair ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Versioned ports (again)
Rainer: Thanks for the clarification! Ah, I see... put things in the portgroup. Of course... On Mar 6, 2008, at 11:48 AM, Rainer Müller wrote: I am pretty sure I don't understand all the issues, I still think that MacPorts versioning (-24, -25, -30) is profoundly flawed, aside from installation issues. Do you have any other solution? This is a bit unrelated to the framework transition. Multiple versions of the same software also apply to gcc and perl. Well, I don't want to kick over old sand, but I came to MacPorts after years of Gentoo on Linux. It may not seem like a big deal to have some port dirs with versions, and some without, but I find it quite difficult to manage. I prefer having the Port *files* have versions. The way MacPorts manages the *installation* of gcc versions is fine: * specify a trailing version specifier on the files or dirs that get installed: for example gcc-mp-4.2 * provide a packagename-select utility to modify symlinks that point gcc - gcc-mp-4.2 (among other things) Gentoo also had this notion of provides and slots. I haven't used Gentoo for a while, so I'm trying to think of an example relevant to MacPorts. Well, I know that the Python Tkinter port has a variant to use the system (OS X-provided) Tk, rather than a MacPorts one. Another example might be X11 packages, or GCC (Apple 4.x versus MacPorts 4.x) -- the idea that a port dep can be satisfied by something that occupies a certain slot or role, rather than a specific file at a specific location. So the GCC 4.x dependency could be satisfied by either Apple's or MacPort's package. Not a great example, perhaps someone else can help explain. But I don't think it's OK to add a specific version number to each port dir, without some notion of slot. Port groups are some of that, but upside-down, as every leaf-level port needs to be aware of a particular port group. For example I've been hacking through the Python ports on Leopard, teaching them about the Apple-supplied Python 2.5.1... I added a port group python-25-apple to make that happen, but now I need to touch *every* python port and change their port group membership. In this case, it isn't a version: both the MacPort and the Apple Pythons are 2.5.1. It's something else, and the leaf- level ports should NOT have to know about that. I felt comfortable contributing Gentoo ports, because I could add versions or whatnot without changing the whole framework, and it was easy to drop something in. I have been quite nervous about perturbing the MacPorts, because if I have a different notion of Python deployment (for example) then that's too destructive, the framework has to be changed a bit to accommodate that, and certainly not everyone is going to want to do it my way. But I can't provide easy hooks to switch between my way and the default way. I hope these comments help. I suspect they won't make any sense to people who haven't used Gentoo much. It's not the same thing as the FreeBSD ports tree. Thanks! - boyd Boyd Waters http://www.aoc.nrao.edu/~bwaters ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't
On Feb 18, 2008, at 9:53 AM, Markus Weissmann wrote: For people who don't need e.g. tk-support, building all those dependencies is unnecessary. Yes! And for those who are banging on a 64-bit Python, we can't touch anything that uses a Carbon API. Like Tk. Has anyone successfully built a 64-bit version of Python 2.5.1 on Macintosh? - boyd Boyd Waters National Radio Astronomy Observaotory New Mexico, USA, Earth ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: 'Lingon' for launchd items (on 10.5)
On Dec 19, 2007, at 2:19 PM, Markus Weissmann wrote: Hi folks, does anyone here use 'Lingon' [1] for managing his/her launchd items? I'd be interested to hear if this tool rocks -- if so, we could give advice to users to more easily use our launchd items on 10.5. Anyone? Markus: I have used Lingon on 10.4.x, and it helped me get started. So I think it may be a good tool to learn the launchd options, complementing the man pages. It is a good tool. I think that after a bit of experience with launchd configuration items, the tool is not necessary. I have not yet used Lingon with Leopard. But if you have not played with Lingon, and you're interested in launchd items, I'd recommend that you give it a try! http://lingon.sourceforge.net - boyd Boyd Waters http://www.aoc.nrao.edu/~bwaters ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Patchfile naming guidelines (was: Re: [31766] trunk/dports/audio/libao)
On Dec 11, 2007, at 7:58 PM, Ryan Schmidt wrote: To the best of my knowledge, Mac OS X cannot assign a file to an application based on a filename prefix. It can only do so based on a filename extension. And for viewing them: How do you highlight diff files? Currently, TextWrangler uses no syntax highlighting on diff files. This is better than the incorrect syntax highlighting that could result by trying to highlight based on the rules of the diffed file. There is such a thing as a multiline comment, or a multiline string. It's possible a diff might include either the opening or closing quote or comment mark, but not the other one, which would result in chaotic highlighting. I have seen this before. In the future, I might write my own syntax highlighting rules for diff files which could, for example, color lines beginning with a + or - in green and red, respectively, similar to what we see in the Trac repository browser or the commit mails. FWIW... TextMate does highlighting of diff files if the file is named '*.diff' or if you explicitly select diff as the mode. It does not attempt to do _syntax_ highlighting _within_ a diff -- so no C or Perl or whatever syntax highlighting. - boyd Boyd Waters Scientific Programmer National Radio Astronomy Observatory Socorro, New Mexico ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [Pythonmac-SIG] Round 2 with Leopard+Python
FYI: On Leopard, sudo filters environment variables, including PYTHONPATH. I have not tested this with MacPorts yet; I've been running MacPorts as a normal user without sudo. Will this matter for MacPorts? Running sudo -V as root shows sudo's settings; part of that is environment variables that it will not pass on or that it will check for dangerous content. On Nov 2, 2007, at 2:59 PM, Boyd Waters wrote: One work-around is to add this line to /etc/sudoers: Defaultsenv_keep += PYTHONPATH But that would involve editing a file in /etc as root. Straightforward enough, but likely to get overwritten and what if the user screws this up? So Plan B - what if you added something in a .pth file in /Library/Python/2.5/ site-packages that re-orders the sys.path? Wouldn't that always work? On Nov 2, 2007, at 2:49 PM, Boyd Waters wrote: On Nov 2, 2007, at 10:16 AM, Brian Granger wrote: First, if you have set PYTHONPATH to point sys.path at the site-packages in /Library, this setting will be lost when you do: sudo python setup.py install Ouch, another good one... This is almost certainly not a bug, but rather a security feature. The administrator can add a line to the sudoers file: Defaults env_reset that will reset the environment to only contain the variables HOME, LOGNAME, PATH, SHELL, TERM, and USER, preventing this attack. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [28120] trunk/dports/lang/python24/Portfile
On Aug 21, 2007, at 9:18 AM, Anders F Björklund wrote:
This change will break ports that depends on python24 and then
try to use the python binary, either directly with #!/opt/local/
bin/python or with e.g. #!/usr/bin/env python.
Maybe those ports using port:python24 should be patched to use
python2.4 instead ?
Ouch, I agree...
Does python-select set a link to python24 or python25 ?
If so, then things should work... ${prefix}/bin/python should be a
link to the currently-selected Python.
And of course ${prefix}/Frameworks/Python/Current should be set to
point to the correct version, as well.
- boyd
Boyd Waters
National Radio Astronomy Observatory
Socorro, New Mexico
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [28120] trunk/dports/lang/python24/Portfile
On Aug 21, 2007, at 11:01 AM, Blair Zajac wrote: I think we we should have separate Framework directories for each Python version, otherwise if you have 2.4 and 2.5 installed on your system, then the Current symlink will point to 2.5, presumably, and you won't be able to do a framework build against 2.4. I'm glad we're discussing this, but isn't the version issue exactly what the Framework structure is supposed to address? I will look into Framework/Versions and see if I can't suggest something better, but in any event I vote against multiple, top-level Python framework directories (such as Libarary/Frameworks/Python24). Regards, - boyd ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [27155] trunk/dports/python/py-psyco/Portfile
On Jul 22, 2007, at 2:10 PM, Rainer Müller wrote: Do we really need to take care of other Operating Systems than Mac OS X? I mean, it's called MacPorts now and is targeted on users of Mac OS X. Who is using it on another system? We use MacPorts for a large software system that is Mac and Linux at the moment, and our group is considering using MacPorts for managing our Linux dependencies, as well. So we'd perhaps port MacPorts to Linux. And also see the wine port again, LDFLAGS like -framework won't work on other platforms... As platform is set to darwin, I think this is okay, but contrary to your statement above. Exactly what the platform tag is designed to do: we'd add platform linux stanzas to our ports, that would (of course) not have settings like -framework in them. Many (if not most) open-source packages already target linux successfully, so in most cases autoconf would determine the correct settings. I think. We haven't started a Linux port in earnest yet. Of course, I'm one of those nut jobs who tried to bring gentoo portage to Mac OS X about five years ago. Oy. - boyd Boyd Waters Scientific Programmer (no, really, that's what they call me) National Radio Astronomy Observatory Socorro, New Mexico ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: deploying pre-build ports with macports
On Jul 5, 2007, at 12:04 PM, Barry Wark wrote: I'm planning a deployment of scientific software to several users in my lab. The software depends on several libraries that aren't installed by default on OS X. We've settled on macports for providing those dependencies (and have been very impressed with the whole project- kudos!). I would like to deploy our whole package I had the same sort of project for our astronomy software. My first thing was to create a meta-package that installed binary versions of all of our MacPorts dependencies. Then I ran another package that installed our (non-MacPorts) things. Note that the binary packages that MacPorts creates have little to do with MacPorts itself: in particular, they do not create MacPorts receipts. If you expect to be able to install binary packages on top of a standard MacPorts distribution, and then subsequently build MacPorts that depend upon the binary-installed things, then you'll be in for a surprise: MacPorts will go ahead and install everything from source, ignoring the binary packages. That is, the binaries and the source ports are two different things and don't talk to one another. For us, this lead to lots of confusion for everyone: scientists, IT staff, developers. So now, I just build everything I need to - MacPorts for the community- developed things! - and then I create a tarball installer that includes all of our stuff (which isn't in MacPorts yet), and the handful of dynamic libs and binary commands that are required by our system (mostly Python). I don't know if my response helps you, but if you have other questions, I'd be happy to discuss them with you -- I'd like to know how other scientific applications are being deployed when using MacPorts. Regards, - boyd Boyd Waters National Radio Astronomy Observatory Socorro, New Mexico ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: deploying pre-build ports with macports
On Jul 5, 2007, at 1:11 PM, Barry Wark wrote:
Boyd,
It sounds like you've been down this road already, then :)
From your answer, it sounds like things won't work. I'm a bit
confused, though. I thought that macports would keep receipts for the
installed ports (e.g. hdf5) (in /opt/local/var/db/dports/?) and that
those receipts would do the trick on the client machine as well. I
planned to compile the dependencies (e.g. hdf5) using port install
XXX--a source install--, then to make an installer that has it's root
at /opt/local and with an install target of /opt/local. Wouldn't the
client macports still have those receipts?
Sorry for my confusion.
Wow, you don't need to be sorry -- I think it is confusing.
The binary package created with port pkg won't write that receipt to
${prefix}/var/db/dports/?
I'm talking about binary packages created with MacPorts -- via the
port pkg command -- they cause me no end of trouble. My opinion. I'd
like to find the time to fix the MacPorts package-creation stuff, but
my Tcl skills may not be adequate.
Anyway. I created a large collection of packages - one for each port -
via the port pkg command.
I gave these to my fellow developers, and many scientists, who also
had Macports installed.
They double-click the pkg file, which launches the Apple installer,
and installs the libraries, binaries, under /opt/local.
Great.
Then later they want to go build some MacPorts that need the packages
that they've already installed with the bianry installer.
Example: I gave them the fortran compiler as a binary package created
from MacPorts, and they want to install (from source) a package that
needs this compiler.
When they say port build fortran-thing, MacPorts *ignores* the
binary-installed fortran compiler -- even though it came from a
MacPorts-created binary package -- and goes ahead and builds every
last little thing. Which may take hours. And may fail, depending upon
which MacPorts tree they have.
MacPorts packages that I have created have another nasty nasty bug, in
that they cannot handle symbolic links in directory paths. The example
I gave earlier on this list was MacPorts emacs -- which all of our
users assumed they needed (they don't know that OS X already has it).
The emacs package wants to add a file to /etc/X11. But /etc is a
symlink to /private/etc. Since the MacPorts installer doesn't handle
that, it *deletes* the symlink to /private/etc, creates a new, blank
directory at /etc, and then write its file, and claims that
installation completed successfully. Rendering the Macintosh unusable
in the process.
So I gave up on distributing binary packages created from MacPorts,
and I just rely upon MacPorts on my developer-build box, and roll a
tarball by hand for our scientific application. The tarball includes
its own distribution of Python, Qt, etc.
Since we roll out the application to people in different institutions,
different configurations, this is the most robust: we try to assume as
little as possible about what might already be set up on the end-
users' Macs.
Hope this helps! Some..
- boyd
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
symbolic link traversal
Howdy all! When you get finished playing with your shiny new iPhone, I have a maybe-stupid question about symbolic links: 1) Does MacPorts traverse symlinks in the middle of a path/like/this (where like would be a symlink) I found a likely bit of Tcl code, and attempted to set it up to recursively resolve symlinks correctly during path traversal, but was not able to fix the problem. I've been holding off on committing my Python ports -- which permit multiple, parallel versions of MacPorts to co-exist on a system -- but I would rather get this path-traversal thing addressed and then clean up the work-arounds in my ports. A related issue: the binary PKG files that are produced by MacPorts are very dangerous for a similar reason: they don't resolve intermediate symlinks, either. Instead, the installer with *wipe out* the intermediate symlink, replacing it with a real directory -- which of course only contains the stuff in that particular package. For example, /etc -- which is a symlink to /private/etc -- is *deleted* and *replaced* by an /etc that only contains an X11 subdir by the emacs binary pkg installer. Ouch! 2) I will try to clean up pkg-creation, unless someone else wants to hit it. Who maintains the PKG binary-installer part of MacPorts? Thanks! - boyd Boyd Waters National Radio Astronomy Observatory middle of nowhere New Mexico USA ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
