Hi all, @Ryan: Thanks for bringing this topic as such back in a constructive way. One remark though on the section below, which "slightly hurt" me as OSX builder :-)
I think this also accounts for the new OSX builders but this time I only speak for myself. 2009/11/18 Ryan Sleevi <[email protected] <ryan%[email protected]>> - What about 32-bit and 64-bit binaries? They *are* different, they *do* > have different build steps and, while their dependencies are the same, > actually resolving those dependencies requires quite a few different steps. > For Linux and Mac this is much easier, but on a platform like Windows, with > a build system like CMake, a compiler like MSVC, and a (justifiable) policy > of static linking, this is a whole new set of challenges. > When you compile hugin only for your own mac, so no distribution, you are right: it is much easier like building on linux. To build a bundle on OSX for publication and release, we need to cross-compile for ppc architecture and i386 architecture. After compiling, these binaries are merged, to create so called Universal binaries and libraries. This due to the fact that Mac was based on ppc and is now moving to the intel platform. All universal binaries though should be able to run on both platforms. When compiling for the new 64bit architectures as well, we cross-compile for ppc, i386, x86_64 and ppc64 and merge these four binaries and all libraries (also the underlying dependency libraries). MacOSX is the only platform that comes with merged multi-platform binaries/libraries. To be able to build on Leopard (10.5.x) and make it work on Tiger (10.4.x), we also need to twist the Posix_2003 compliancy, which limits you by default to only build for your own OS version (For example: This is also why every Ubuntu or Fedora (sub-)version need a new Hugin build). We can "trick" gcc on MacOSX to build for multiple OS versions, but this is an active configuration action. All this can't be done by cmake so therefore we use XCode, the MSVC counterpart. We also need quite some shell scripts to "knit" the (c)make/autoconf and XCode "ends" to each other. Next to that: OSX uses "install_names" which means that the path to a library or binary is hard-coded into the library/binary. So inside libpng, you will find the path to libpng itself, but also to libtiff and libjpeg and others. When building for a bundle, all these "install_names" need to be rewritten to point to internal paths inside the bundle where binaries, frameworks and libraries all reside on different locations. This enables you to build a "self-contained" bundle but at the same time it also complicates the build process quite a bit. Cross-compiling and merging, overcome OS level boundaries and these "install_names" is what really makes it complicated on OSX. This is also why it takes some time to train a builder on OSX. I only wanted to make everyone more aware of this complexity on OSX. I mentioned in an earlier mail: *"I asked for Hugin OSX builders in my recent "Hugin OSX publication" mails. Three of them reacted on that and are now learning to build a bundle where one of them is ready IMO to release his own bundle now."* So this mail is also to give them the credits they deserve. Kind regards, Harry -- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
