1362 Views 3 Replies Latest reply: Apr 30, 2009 2:11 PM by MrHoffman
You'll have loaded Xcode by now, so go launch it, and select the documentation tab under "help" there. The Xcode documentation is extensive, and usually complete. The documentation there is usually a good source for most any programming or porting or Mac OS X software question you might have.
In particular, you'll find goodies such as links to the manual entitled [Universal Binary Programming Guidelines,
Second Edition|http://developer.apple.com/documentation/MacOSX/Conceptual/universalbinary/universalbinary.pdf], and various other discussions.
For examples of builds for specific tools, check the MacPorts or [DarwinPorts|http://ssed.darwinports.com> both for the ports of various tools, and for the procedures used to build those tools.
Also take the time to learn the [file and directory path norms for Mac OS X environments|http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileS ystem/BPFileSystem.pdf]; learn where your pieces should fit, so that you don't romp on Mac system files, and so that a Mac OS X patch kit or the Snow Leopard upgrade won't romp on your own tools and files.
Thanks for your help.... I'm just a little overwhelmed by all the information there.
I'm just using "./configure && make" on the commandline, not XCode, so a lot of that information doesn't apply, at least, I don't think it does.
I'm not a programmer. I'm a guy who knows how to do "configure && make" so these are kind of deep waters for me to tread.
I'm not a huge fan of the autoconfigure tools, and even the make tools stuff is often unnecessary complexity for most uses and for end users and one-shot ports; other than somebody that's regularly building the tool on a lower-end box or building a bigger tool (cases where a dependency build can help), the use of make tends to obfuscate the whole build process. But I digress.
Look at what was done over in MacPorts and DarwinPorts for those ports; look for a [pre-existing port of the GNU sed tool (MacPorts)|http://filiptepper.com/2009/04/15/hint-gnu-sed-on-os-x-with-macports >.
Consider why you're building fat binaries, too. Are you hauling the resulting files around among various boxes and architectures? If not, then you can choose to "just build it" for the local architecture. (So you have to build it twice. Is that a big deal? If not, build it and move on.)
Various of the packages based on GNU autoconf and configure don't tend to directly port; when you're using these tools off of a GNU platform, you'll generally have to do some tweaking here and there.
You are aware there's sed (BSD-flavor) available at the command shell, right?
And Google can be your friend, too. Toss /GNU sed os x/ at the engine, and you'll find discussions including [building sed for os x|http://blog.apokalyptik.com/2008/04/24/building-sed-for-osx> and [building rsync|http://www.jaharmi.com/2008/08/01/compilinga_five_way_universal_binary_of_rsync_3_with_llvm_gcc_onleopard] and [Octave|http://wiki.octave.org/wiki.pl?OctaveForMac] and other such. The last time I ran into what looks to be a similar case, I ended up having to escape the pieces of the compile command for the architectures (I wish I had that code handy right now, too), and some hacking around in the build procedure. Best case here is to dig around in the build procedure; if you're interested in learning how these pieces work, there's no better time than now. Otherwise, look to use MacPorts or DarwinPorts.