On Jan 2, 2007, at 5:41 PM, Jordan K. Hubbard wrote:
On Jan 2, 2007, at 2:08 PM, Kevin Ballard wrote:
If you're going to distribute software, you don't want to build it with macports (because all the linker paths will be absolute and pointing at /opt/local, which is not how you want to distribute anything). Because of this, I don't think crosscompiling is an issue, since when building just for yourself, you don't need the other architecture.
I'm a little puzzled by this statement. Unless you're willing to make all of your distributed applications and libraries into bundles, which is quite a bit of work that most folks aren't willing to go to anyway, you're going to have hard-coded linker paths pointing somewhere no matter what you do! Since you also can't install directly into locations like /usr/bin and /usr/lib (well, you can, but a special hit squad of Mac OS X engineers will be dispatched to terminate you and your software with extreme prejudice if you do), /opt/local is as good a location as /sw, /usr/local or pretty much any other location you might come up with.
There's 2 options in cases like this. The first is to make a bundle, which really isn't all that hard. In this case, your linker paths should be point at some variation of @executable_path/../Frameworks/foo.
The other option is to install somewhere like, say, /usr/local. I disagree that /opt/local is as good a place to install stuff as any - I don't want anything touching /opt/local but MacPorts. /usr/local is the common choice for stuff like this as well, so precedent is on your side if you pick that.
In fact, if the MacPorts project ever gets off its collective duff and starts distributing binary packages (in some, any, package format) like was originally intended at the start of all this, one can reasonably expect to see a lot of users whacking stuff into /opt/local without really even being aware of it.
Sure, if MacPorts ever starts distributing binaries, at that point cross-compiling will become useful (although the argument can be made that separate binaries for ppc vs. i686 should be used instead, as it cuts down on filesize).
As a note, I once downloaded a program which had just released a new version that used openjade for HTML validation. It didn't work. Why? Because the author had built openjade using MacPorts and bundled it that way. It worked fine on his system, but on anybody else's system it was looking for libraries in /opt/local/lib that simply weren't there. Beware distribution of MacPorts-built binaries.
No offense, but you're barking up the wrong tree with that analysis. The problem wasn't that the author had built openjade using MacPorts, the problem was that he didn't instruct you to install the dependent libraries as well or simply bundle them with his software too. That's one of the reasons that the MacPorts community always gets so hung up on package management - they want to distribute packages, but they also want to ensure that any system which installs those packages also follows dependencies, deals with upgrades and otherwise handles all the messy details of making that software work exactly the way it did on the package author's system.
He did in fact bundle all the dependencies with his software. He just didn't realize that those bundled dependencies weren't actually being used - I don't know what he was thinking, but I guess he assumed if they existed in the bundle Frameworks dir they'd take precedence, which isn't the case.
So the problem was he built stuff using a package management system, and then bundled his app the way he'd seen other people bundle it, but the binaries were still all linking against /opt/local/lib rather than the bundled libraries. Sure, this is basically a 1-D-10-T ission, but if he had built libraries by hand it would have forced him to think about this stuff.
The basic point is building stuff via MacPorts that you intend to distribute basically won't work unless you put extra effort in, probably more effort than it would have taken to just build everything yourself correctly.
Someday, one hopes, MacPorts will finally reach parity with its FreeBSD/Gentoo/Red Hat cousins and offer such a collection, after which problems like the ones you're describing will go away and be replaced by an entirely new and different set of problems which, at least, will be interesting and relevant to a wider audience. :-)
Haha.