crosscompiling macports, how hard is it?

[Kevin Ballard]

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.

-- 
Kevin Ballard
http://kevin.sb.org
eridius at macports.org
http://www.tildesoft.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-users/attachments/20070102/390ab3ae/attachment.html