https://wiki.panotools.org/api.php?action=feedcontributions&user=Ippei&feedformat=atomPanoTools.org Wiki - User contributions [en]2024-03-19T12:31:43ZUser contributionsMediaWiki 1.35.3https://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10731Build a MacOSX Universal Hugin bundle with Xcode2008-08-21T04:57:53Z<p>Ippei: /* Configure */ Run multiple times</p>
<hr />
<div>=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Necessary Tools===<br />
Before start, we need to install couple of tools used in the process:<br />
# Subversion (Tiger users only)<br />
# GNU gettext<br />
<br />
You may use either binary distributions like MacPorts and Fink, or download official version and manually compile and install ("./configure; make; sudo make install").<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install:<br />
<blockquote><pre><br />
$ sudo port install subversion #Tiger users only<br />
$ sudo port install gettext<br />
</pre></blockquote><br />
<br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre><br />
$ sudo apt-get install svn #Tiger users only<br />
$ sudo apt-get install gettext<br />
</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Checking Project Info===<br />
Double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. Changing this value is not recommended.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Configure====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less. Please run this target for 2 to 3 times as it sometimes updates Xcode project setting itself and the updated variables are only used in the following execution.<br />
<br />
In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br /><br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
This build target updates the pre-release version tags, and is not propagated (does not automatically run) from other targets. You should run this target after every SVN update. Also, before compiling anything that you give away to other people, make sure that you "Clean all targets" and then build this "configure" target first.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "Hugin" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br /><br />
<br />
''Tips:'' If you have multiple Mac OS X machines, you may be able to distribute the compilation over multiple machines on the same network. Install Xcode Tools on all machines and check out the Preferences of Xcode, under "Distributed Builds".<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br /><br />
Note that the build may have succeeded even though you see some error messages (in this screen dump). Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Quick test can be done by "Run" (Cmd-R) within Xcode. If Hugin launches, it's a party time!!! So, go party and when you're finished come back for the next test.<br />
<br />
"Run"ing in Xcode is useful for debugging with Xcode, but unfortunately using external executable within Hugin confuses the GDB and Xcode, so you cannot stitch or run autopano programs this way. If Hugin.app launches finely from Xcode, get to Finder and double-click the Huing.app icon and try to make a panorama. If that works fine, go for another glass of wine.<br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. <br />
<br />
As this is not always possible, You could follow the following dirty technique: <br /><br />
'''Warning:''' This is not exactly a safe operation. Do at your own risk. <br /><br />
*Copy your Hugin.app to another location on your mac and rename<br />
** your mac directory inside your hugin source directory to mac.org,<br />
** your /opt/local to /opt/local.org (in case you have Macports),<br />
** your /sw directory to /sw.org (in case you have Fink),<br />
** your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br /><br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br />
<br />
The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the library paths inside Hugin and inside the libraries to "internal" paths relative to the executable location, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br />
<br />
To see errors directly you can start Hugin.app from the command line, e.g. from a terminal: <pre>$ Hugin.app/Contents/MacOS/Hugin &</pre> Alternatively you can double-click Hugin.app from Finder while following the (error) messages on <tt>/Applicatons/Utilities/Console.app</tt>.<br />
<br />
Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). The same crash logs may be displayed by the CrashReporter immediately after Hugin crashes. You can configure the CrashReporter's behaviour with <tt>/Developer/Applications/Utilities/CrashReporterPrefs.app</tt>.<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations! <br/><br />
Have a big celebration and have a happy hacking Hugin time!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
===Statically linked command-line tools===<br />
There are some command line tools in Hugin package and related tool chain that users would want to use independently of Hugin.app. The best way to make those command line tools is to build them statically linked of all non-standard libraries.<br />
<br />
You need to (that's a lie, but let me simplify) compile another binary depository with this time compiling the second list in <tt>ExternalPrograms/readme.txt</tt>. If you have taken the 'outside' approach, you can just make another repository and proceed the next step. If not, the right location to have your repository will be given in the next step. That's all for tools that are built in ''External Programs'' manner including enblend and autopano-sift-c.<br />
<br />
For Xcode, the trick is to make another folder that parallels <tt>mac/</tt> in the Hugin source:<br />
# Make a new folder next to <tt>mac/</tt> and name it "<tt>mac-static</tt>".<br />
# Copy BuildConfig.xcconfig, Version.xcconfig, and Hugin.xcodeproj files to the new folder.<br />
# Make a new folder in tt>mac-static/</tt> named "<tt>ExternalPrograms</tt>".<br />
# Either make the static repository here, or place a symbolic link named "repository" to the outside one.<br />
# Edit BuildConfig.xcconfig and update the REPOSITORY_ABSOLUTE_PATH variable.<br />
<br />
Now you are ready for Xcode. Just get the Hugin.xcodeproj open, run the 'configure' build target as usual, select the 'static tools' target or any specific 'static' tools, and build. You are done. If you check the compiled executable file with 'otool -L ', you should see only the libraries in standard OS X installation (that is, usually, ones in '/usr/lib').<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
- [http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/index.html Cross-Development Programming Guide] and [http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/index.html Universal Binary Programming Guidelines, Second Edition]– more about building fully compatible universal binaries on OS X<br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10661Build a MacOSX Universal Hugin bundle with Xcode2008-07-09T00:18:04Z<p>Ippei: /* '''Notes''' */ static build</p>
<hr />
<div>=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Necessary Tools===<br />
Before start, we need to install couple of tools used in the process:<br />
# Subversion (Tiger users only)<br />
# GNU gettext<br />
<br />
You may use either binary distributions like MacPorts and Fink, or download official version and manually compile and install ("./configure; make; sudo make install").<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install:<br />
<blockquote><pre><br />
$ sudo port install subversion #Tiger users only<br />
$ sudo port install gettext<br />
</pre></blockquote><br />
<br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre><br />
$ sudo apt-get install svn #Tiger users only<br />
$ sudo apt-get install gettext<br />
</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Checking Project Info===<br />
Double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. Changing this value is not recommended.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Configure====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less.<br />
<br />
In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br /><br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
This build target updates the pre-release version tags, and is not propagated (does not automatically run) from other targets. You should run this target after every SVN update. Also, before compiling anything that you give away to other people, make sure that you "Clean all targets" and then build this "configure" target first.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "Hugin" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br /><br />
<br />
''Tips:'' If you have multiple Mac OS X machines, you may be able to distribute the compilation over multiple machines on the same network. Install Xcode Tools on all machines and check out the Preferences of Xcode, under "Distributed Builds".<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br /><br />
Note that the build may have succeeded even though you see some error messages (in this screen dump). Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Quick test can be done by "Run" (Cmd-R) within Xcode. If Hugin launches, it's a party time!!! So, go party and when you're finished come back for the next test.<br />
<br />
"Run"ing in Xcode is useful for debugging with Xcode, but unfortunately using external executable within Hugin confuses the GDB and Xcode, so you cannot stitch or run autopano programs this way. If Hugin.app launches finely from Xcode, get to Finder and double-click the Huing.app icon and try to make a panorama. If that works fine, go for another glass of wine.<br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. <br />
<br />
As this is not always possible, You could follow the following dirty technique: <br /><br />
'''Warning:''' This is not exactly a safe operation. Do at your own risk. <br /><br />
*Copy your Hugin.app to another location on your mac and rename<br />
** your mac directory inside your hugin source directory to mac.org,<br />
** your /opt/local to /opt/local.org (in case you have Macports),<br />
** your /sw directory to /sw.org (in case you have Fink),<br />
** your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br /><br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br />
<br />
The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the library paths inside Hugin and inside the libraries to "internal" paths relative to the executable location, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br />
<br />
To see errors directly you can start Hugin.app from the command line, e.g. from a terminal: <pre>$ Hugin.app/Contents/MacOS/Hugin &</pre> Alternatively you can double-click Hugin.app from Finder while following the (error) messages on <tt>/Applicatons/Utilities/Console.app</tt>.<br />
<br />
Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). The same crash logs may be displayed by the CrashReporter immediately after Hugin crashes. You can configure the CrashReporter's behaviour with <tt>/Developer/Applications/Utilities/CrashReporterPrefs.app</tt>.<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations! <br/><br />
Have a big celebration and have a happy hacking Hugin time!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
===Statically linked command-line tools===<br />
There are some command line tools in Hugin package and related tool chain that users would want to use independently of Hugin.app. The best way to make those command line tools is to build them statically linked of all non-standard libraries.<br />
<br />
You need to (that's a lie, but let me simplify) compile another binary depository with this time compiling the second list in <tt>ExternalPrograms/readme.txt</tt>. If you have taken the 'outside' approach, you can just make another repository and proceed the next step. If not, the right location to have your repository will be given in the next step. That's all for tools that are built in ''External Programs'' manner including enblend and autopano-sift-c.<br />
<br />
For Xcode, the trick is to make another folder that parallels <tt>mac/</tt> in the Hugin source:<br />
# Make a new folder next to <tt>mac/</tt> and name it "<tt>mac-static</tt>".<br />
# Copy BuildConfig.xcconfig, Version.xcconfig, and Hugin.xcodeproj files to the new folder.<br />
# Make a new folder in tt>mac-static/</tt> named "<tt>ExternalPrograms</tt>".<br />
# Either make the static repository here, or place a symbolic link named "repository" to the outside one.<br />
# Edit BuildConfig.xcconfig and update the REPOSITORY_ABSOLUTE_PATH variable.<br />
<br />
Now you are ready for Xcode. Just get the Hugin.xcodeproj open, run the 'configure' build target as usual, select the 'static tools' target or any specific 'static' tools, and build. You are done. If you check the compiled executable file with 'otool -L ', you should see only the libraries in standard OS X installation (that is, usually, ones in '/usr/lib').<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
- [http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/index.html Cross-Development Programming Guide] and [http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/index.html Universal Binary Programming Guidelines, Second Edition]– more about building fully compatible universal binaries on OS X<br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10650Build a MacOSX Universal Hugin bundle with Xcode2008-07-06T10:27:40Z<p>Ippei: /* Building Hugin.app */</p>
<hr />
<div>=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Necessary Tools===<br />
Before start, we need to install couple of tools used in the process:<br />
# Subversion (Tiger users only)<br />
# GNU gettext<br />
<br />
You may use either binary distributions like MacPorts and Fink, or download official version and manually compile and install ("./configure; make; sudo make install").<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install:<br />
<blockquote><pre><br />
$ sudo port install subversion #Tiger users only<br />
$ sudo port install gettext<br />
</pre></blockquote><br />
<br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre><br />
$ sudo apt-get install svn #Tiger users only<br />
$ sudo apt-get install gettext<br />
</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Checking Project Info===<br />
Double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. Changing this value is not recommended.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Configure====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less.<br />
<br />
In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br /><br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
This build target updates the pre-release version tags, and is not propagated (does not automatically run) from other targets. You should run this target after every SVN update. Also, before compiling anything that you give away to other people, make sure that you "Clean all targets" and then build this "configure" target first.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "Hugin" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br /><br />
<br />
''Tips:'' If you have multiple Mac OS X machines, you may be able to distribute the compilation over multiple machines on the same network. Install Xcode Tools on all machines and check out the Preferences of Xcode, under "Distributed Builds".<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br /><br />
Note that the build may have succeeded even though you see some error messages (in this screen dump). Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Quick test can be done by "Run" (Cmd-R) within Xcode. If Hugin launches, it's a party time!!! So, go party and when you're finished come back for the next test.<br />
<br />
"Run"ing in Xcode is useful for debugging with Xcode, but unfortunately using external executable within Hugin confuses the GDB and Xcode, so you cannot stitch or run autopano programs this way. If Hugin.app launches finely from Xcode, get to Finder and double-click the Huing.app icon and try to make a panorama. If that works fine, go for another glass of wine.<br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. <br />
<br />
As this is not always possible, You could follow the following dirty technique: <br /><br />
'''Warning:''' This is not exactly a safe operation. Do at your own risk. <br /><br />
*Copy your Hugin.app to another location on your mac and rename<br />
** your mac directory inside your hugin source directory to mac.org,<br />
** your /opt/local to /opt/local.org (in case you have Macports),<br />
** your /sw directory to /sw.org (in case you have Fink),<br />
** your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br /><br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br />
<br />
The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the library paths inside Hugin and inside the libraries to "internal" paths relative to the executable location, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br />
<br />
To see errors directly you can start Hugin.app from the command line, e.g. from a terminal: <pre>$ Hugin.app/Contents/MacOS/Hugin &</pre> Alternatively you can double-click Hugin.app from Finder while following the (error) messages on <tt>/Applicatons/Utilities/Console.app</tt>.<br />
<br />
Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). The same crash logs may be displayed by the CrashReporter immediately after Hugin crashes. You can configure the CrashReporter's behaviour with <tt>/Developer/Applications/Utilities/CrashReporterPrefs.app</tt>.<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations! <br/><br />
Have a big celebration and have a happy hacking Hugin time!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
- [http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/index.html Cross-Development Programming Guide] and [http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/index.html Universal Binary Programming Guidelines, Second Edition]– more about building fully compatible universal binaries on OS X<br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10649Build a MacOSX Universal Hugin bundle with Xcode2008-07-06T10:14:26Z<p>Ippei: /* Installing Necessary Tools */</p>
<hr />
<div>=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Necessary Tools===<br />
Before start, we need to install couple of tools used in the process:<br />
# Subversion (Tiger users only)<br />
# GNU gettext<br />
<br />
You may use either binary distributions like MacPorts and Fink, or download official version and manually compile and install ("./configure; make; sudo make install").<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install:<br />
<blockquote><pre><br />
$ sudo port install subversion #Tiger users only<br />
$ sudo port install gettext<br />
</pre></blockquote><br />
<br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre><br />
$ sudo apt-get install svn #Tiger users only<br />
$ sudo apt-get install gettext<br />
</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Checking Project Info===<br />
Double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. Changing this value is not recommended.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Configure====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less.<br />
<br />
In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br /><br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
This build target updates the pre-release version tags, and is not propagated (does not automatically run) from other targets. You should run this target after every SVN update. Also, before compiling anything that you give away to other people, make sure that you "Clean all targets" and then build this "configure" target first.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "Hugin" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Quick test can be done by "Run" (Cmd-R) within Xcode. If Hugin launches, it's a party time!!! So, go party and when you're finished come back for the next test.<br />
<br />
"Run"ing in Xcode is useful for debugging with Xcode, but unfortunately using external executable within Hugin confuses the GDB and Xcode, so you cannot stitch or run autopano programs this way. If Hugin.app launches finely from Xcode, get to Finder and double-click the Huing.app icon and try to make a panorama. If that works fine, go for another glass of wine.<br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. <br />
<br />
As this is not always possible, You could follow the following dirty technique: <br /><br />
'''Warning:''' This is not exactly a safe operation. Do at your own risk. <br /><br />
*Copy your Hugin.app to another location on your mac and rename<br />
** your mac directory inside your hugin source directory to mac.org,<br />
** your /opt/local to /opt/local.org (in case you have Macports),<br />
** your /sw directory to /sw.org (in case you have Fink),<br />
** your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br /><br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br />
<br />
The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the library paths inside Hugin and inside the libraries to "internal" paths relative to the executable location, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br />
<br />
To see errors directly you can start Hugin.app from the command line, e.g. from a terminal: <pre>$ Hugin.app/Contents/MacOS/Hugin &</pre> Alternatively you can double-click Hugin.app from Finder while following the (error) messages on <tt>/Applicatons/Utilities/Console.app</tt>.<br />
<br />
Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). The same crash logs may be displayed by the CrashReporter immediately after Hugin crashes. You can configure the CrashReporter's behaviour with <tt>/Developer/Applications/Utilities/CrashReporterPrefs.app</tt>.<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations! <br/><br />
Have a big celebration and have a happy hacking Hugin time!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
- [http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/index.html Cross-Development Programming Guide] and [http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/index.html Universal Binary Programming Guidelines, Second Edition]– more about building fully compatible universal binaries on OS X<br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10648Build a MacOSX Universal Hugin bundle with Xcode2008-07-06T10:13:33Z<p>Ippei: /* Installing Subversion (SVN) */ now not only SVN</p>
<hr />
<div>=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Necessary Tools===<br />
''(Note: Tiger users only)''<br />
<br />
Before start, we need to install couple of tools used in the process:<br />
# Subversion (Tiger users only)<br />
# GNU gettext<br />
<br />
You may use either binary distributions like MacPorts and Fink, or download official version and manually compile and install ("./configure; make; sudo make install").<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install:<br />
<blockquote><pre><br />
$ sudo port install subversion #Tiger users only<br />
$ sudo port install gettext<br />
</pre></blockquote><br />
<br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre><br />
$ sudo apt-get install svn #Tiger users only<br />
$ sudo apt-get install gettext<br />
</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Checking Project Info===<br />
Double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. Changing this value is not recommended.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Configure====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less.<br />
<br />
In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br /><br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
This build target updates the pre-release version tags, and is not propagated (does not automatically run) from other targets. You should run this target after every SVN update. Also, before compiling anything that you give away to other people, make sure that you "Clean all targets" and then build this "configure" target first.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "Hugin" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Quick test can be done by "Run" (Cmd-R) within Xcode. If Hugin launches, it's a party time!!! So, go party and when you're finished come back for the next test.<br />
<br />
"Run"ing in Xcode is useful for debugging with Xcode, but unfortunately using external executable within Hugin confuses the GDB and Xcode, so you cannot stitch or run autopano programs this way. If Hugin.app launches finely from Xcode, get to Finder and double-click the Huing.app icon and try to make a panorama. If that works fine, go for another glass of wine.<br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. <br />
<br />
As this is not always possible, You could follow the following dirty technique: <br /><br />
'''Warning:''' This is not exactly a safe operation. Do at your own risk. <br /><br />
*Copy your Hugin.app to another location on your mac and rename<br />
** your mac directory inside your hugin source directory to mac.org,<br />
** your /opt/local to /opt/local.org (in case you have Macports),<br />
** your /sw directory to /sw.org (in case you have Fink),<br />
** your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br /><br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br />
<br />
The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the library paths inside Hugin and inside the libraries to "internal" paths relative to the executable location, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br />
<br />
To see errors directly you can start Hugin.app from the command line, e.g. from a terminal: <pre>$ Hugin.app/Contents/MacOS/Hugin &</pre> Alternatively you can double-click Hugin.app from Finder while following the (error) messages on <tt>/Applicatons/Utilities/Console.app</tt>.<br />
<br />
Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). The same crash logs may be displayed by the CrashReporter immediately after Hugin crashes. You can configure the CrashReporter's behaviour with <tt>/Developer/Applications/Utilities/CrashReporterPrefs.app</tt>.<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations! <br/><br />
Have a big celebration and have a happy hacking Hugin time!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
- [http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/index.html Cross-Development Programming Guide] and [http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/index.html Universal Binary Programming Guidelines, Second Edition]– more about building fully compatible universal binaries on OS X<br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10647Build a MacOSX Universal Hugin bundle with Xcode2008-07-06T10:05:34Z<p>Ippei: Undo revision 10646 by Ippei (Talk)</p>
<hr />
<div>=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Checking Project Info===<br />
Double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. Changing this value is not recommended.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Configure====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less.<br />
<br />
In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br /><br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
This build target updates the pre-release version tags, and is not propagated (does not automatically run) from other targets. You should run this target after every SVN update. Also, before compiling anything that you give away to other people, make sure that you "Clean all targets" and then build this "configure" target first.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "Hugin" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Quick test can be done by "Run" (Cmd-R) within Xcode. If Hugin launches, it's a party time!!! So, go party and when you're finished come back for the next test.<br />
<br />
"Run"ing in Xcode is useful for debugging with Xcode, but unfortunately using external executable within Hugin confuses the GDB and Xcode, so you cannot stitch or run autopano programs this way. If Hugin.app launches finely from Xcode, get to Finder and double-click the Huing.app icon and try to make a panorama. If that works fine, go for another glass of wine.<br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. <br />
<br />
As this is not always possible, You could follow the following dirty technique: <br /><br />
'''Warning:''' This is not exactly a safe operation. Do at your own risk. <br /><br />
*Copy your Hugin.app to another location on your mac and rename<br />
** your mac directory inside your hugin source directory to mac.org,<br />
** your /opt/local to /opt/local.org (in case you have Macports),<br />
** your /sw directory to /sw.org (in case you have Fink),<br />
** your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br /><br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br />
<br />
The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the library paths inside Hugin and inside the libraries to "internal" paths relative to the executable location, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br />
<br />
To see errors directly you can start Hugin.app from the command line, e.g. from a terminal: <pre>$ Hugin.app/Contents/MacOS/Hugin &</pre> Alternatively you can double-click Hugin.app from Finder while following the (error) messages on <tt>/Applicatons/Utilities/Console.app</tt>.<br />
<br />
Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). The same crash logs may be displayed by the CrashReporter immediately after Hugin crashes. You can configure the CrashReporter's behaviour with <tt>/Developer/Applications/Utilities/CrashReporterPrefs.app</tt>.<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations! <br/><br />
Have a big celebration and have a happy hacking Hugin time!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
- [http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/index.html Cross-Development Programming Guide] and [http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/index.html Universal Binary Programming Guidelines, Second Edition]– more about building fully compatible universal binaries on OS X<br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10646Build a MacOSX Universal Hugin bundle with Xcode2008-07-06T10:03:18Z<p>Ippei: added gettext installaton</p>
<hr />
<div>=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
<br />
<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Checking Project Info===<br />
Double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. Changing this value is not recommended.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Configure====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less.<br />
<br />
In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br /><br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
This build target updates the pre-release version tags, and is not propagated (does not automatically run) from other targets. You should run this target after every SVN update. Also, before compiling anything that you give away to other people, make sure that you "Clean all targets" and then build this "configure" target first.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "Hugin" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Quick test can be done by "Run" (Cmd-R) within Xcode. If Hugin launches, it's a party time!!! So, go party and when you're finished come back for the next test.<br />
<br />
"Run"ing in Xcode is useful for debugging with Xcode, but unfortunately using external executable within Hugin confuses the GDB and Xcode, so you cannot stitch or run autopano programs this way. If Hugin.app launches finely from Xcode, get to Finder and double-click the Huing.app icon and try to make a panorama. If that works fine, go for another glass of wine.<br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. <br />
<br />
As this is not always possible, You could follow the following dirty technique: <br /><br />
'''Warning:''' This is not exactly a safe operation. Do at your own risk. <br /><br />
*Copy your Hugin.app to another location on your mac and rename<br />
** your mac directory inside your hugin source directory to mac.org,<br />
** your /opt/local to /opt/local.org (in case you have Macports),<br />
** your /sw directory to /sw.org (in case you have Fink),<br />
** your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br /><br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br />
<br />
The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the library paths inside Hugin and inside the libraries to "internal" paths relative to the executable location, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br />
<br />
To see errors directly you can start Hugin.app from the command line, e.g. from a terminal: <pre>$ Hugin.app/Contents/MacOS/Hugin &</pre> Alternatively you can double-click Hugin.app from Finder while following the (error) messages on <tt>/Applicatons/Utilities/Console.app</tt>.<br />
<br />
Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). The same crash logs may be displayed by the CrashReporter immediately after Hugin crashes. You can configure the CrashReporter's behaviour with <tt>/Developer/Applications/Utilities/CrashReporterPrefs.app</tt>.<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations! <br/><br />
Have a big celebration and have a happy hacking Hugin time!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
- [http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/index.html Cross-Development Programming Guide] and [http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/index.html Universal Binary Programming Guidelines, Second Edition]– more about building fully compatible universal binaries on OS X<br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10645Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T19:32:14Z<p>Ippei: /* Checking Project Info */</p>
<hr />
<div>=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Checking Project Info===<br />
Double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. Changing this value is not recommended.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Configure====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less.<br />
<br />
In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br /><br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
This build target updates the pre-release version tags, and is not propagated (does not automatically run) from other targets. You should run this target after every SVN update. Also, before compiling anything that you give away to other people, make sure that you "Clean all targets" and then build this "configure" target first.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "Hugin" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Quick test can be done by "Run" (Cmd-R) within Xcode. If Hugin launches, it's a party time!!! So, go party and when you're finished come back for the next test.<br />
<br />
"Run"ing in Xcode is useful for debugging with Xcode, but unfortunately using external executable within Hugin confuses the GDB and Xcode, so you cannot stitch or run autopano programs this way. If Hugin.app launches finely from Xcode, get to Finder and double-click the Huing.app icon and try to make a panorama. If that works fine, go for another glass of wine.<br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. <br />
<br />
As this is not always possible, You could follow the following dirty technique: <br /><br />
'''Warning:''' This is not exactly a safe operation. Do at your own risk. <br /><br />
*Copy your Hugin.app to another location on your mac and rename<br />
** your mac directory inside your hugin source directory to mac.org,<br />
** your /opt/local to /opt/local.org (in case you have Macports),<br />
** your /sw directory to /sw.org (in case you have Fink),<br />
** your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br /><br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br />
<br />
The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the library paths inside Hugin and inside the libraries to "internal" paths relative to the executable location, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br />
<br />
To see errors directly you can start Hugin.app from the command line, e.g. from a terminal: <pre>$ Hugin.app/Contents/MacOS/Hugin &</pre> Alternatively you can double-click Hugin.app from Finder while following the (error) messages on <tt>/Applicatons/Utilities/Console.app</tt>.<br />
<br />
Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). The same crash logs may be displayed by the CrashReporter immediately after Hugin crashes. You can configure the CrashReporter's behaviour with <tt>/Developer/Applications/Utilities/CrashReporterPrefs.app</tt>.<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations! <br/><br />
Have a big celebration and have a happy hacking Hugin time!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
- [http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/index.html Cross-Development Programming Guide] and [http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/index.html Universal Binary Programming Guidelines, Second Edition]– more about building fully compatible universal binaries on OS X<br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10644Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T19:31:19Z<p>Ippei: /* Prepare the project for our configuration */</p>
<hr />
<div>=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Checking Project Info===<br />
Double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Configure====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less.<br />
<br />
In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br /><br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
This build target updates the pre-release version tags, and is not propagated (does not automatically run) from other targets. You should run this target after every SVN update. Also, before compiling anything that you give away to other people, make sure that you "Clean all targets" and then build this "configure" target first.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "Hugin" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Quick test can be done by "Run" (Cmd-R) within Xcode. If Hugin launches, it's a party time!!! So, go party and when you're finished come back for the next test.<br />
<br />
"Run"ing in Xcode is useful for debugging with Xcode, but unfortunately using external executable within Hugin confuses the GDB and Xcode, so you cannot stitch or run autopano programs this way. If Hugin.app launches finely from Xcode, get to Finder and double-click the Huing.app icon and try to make a panorama. If that works fine, go for another glass of wine.<br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. <br />
<br />
As this is not always possible, You could follow the following dirty technique: <br /><br />
'''Warning:''' This is not exactly a safe operation. Do at your own risk. <br /><br />
*Copy your Hugin.app to another location on your mac and rename<br />
** your mac directory inside your hugin source directory to mac.org,<br />
** your /opt/local to /opt/local.org (in case you have Macports),<br />
** your /sw directory to /sw.org (in case you have Fink),<br />
** your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br /><br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br />
<br />
The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the library paths inside Hugin and inside the libraries to "internal" paths relative to the executable location, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br />
<br />
To see errors directly you can start Hugin.app from the command line, e.g. from a terminal: <pre>$ Hugin.app/Contents/MacOS/Hugin &</pre> Alternatively you can double-click Hugin.app from Finder while following the (error) messages on <tt>/Applicatons/Utilities/Console.app</tt>.<br />
<br />
Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). The same crash logs may be displayed by the CrashReporter immediately after Hugin crashes. You can configure the CrashReporter's behaviour with <tt>/Developer/Applications/Utilities/CrashReporterPrefs.app</tt>.<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations! <br/><br />
Have a big celebration and have a happy hacking Hugin time!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
- [http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/index.html Cross-Development Programming Guide] and [http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/index.html Universal Binary Programming Guidelines, Second Edition]– more about building fully compatible universal binaries on OS X<br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10643Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T19:26:28Z<p>Ippei: not a draft anymore I'd say!</p>
<hr />
<div>=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Configure====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less.<br />
<br />
In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br /><br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
This build target updates the pre-release version tags, and is not propagated (does not automatically run) from other targets. You should run this target after every SVN update. Also, before compiling anything that you give away to other people, make sure that you "Clean all targets" and then build this "configure" target first.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "Hugin" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Quick test can be done by "Run" (Cmd-R) within Xcode. If Hugin launches, it's a party time!!! So, go party and when you're finished come back for the next test.<br />
<br />
"Run"ing in Xcode is useful for debugging with Xcode, but unfortunately using external executable within Hugin confuses the GDB and Xcode, so you cannot stitch or run autopano programs this way. If Hugin.app launches finely from Xcode, get to Finder and double-click the Huing.app icon and try to make a panorama. If that works fine, go for another glass of wine.<br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. <br />
<br />
As this is not always possible, You could follow the following dirty technique: <br /><br />
'''Warning:''' This is not exactly a safe operation. Do at your own risk. <br /><br />
*Copy your Hugin.app to another location on your mac and rename<br />
** your mac directory inside your hugin source directory to mac.org,<br />
** your /opt/local to /opt/local.org (in case you have Macports),<br />
** your /sw directory to /sw.org (in case you have Fink),<br />
** your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br /><br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br />
<br />
The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the library paths inside Hugin and inside the libraries to "internal" paths relative to the executable location, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br />
<br />
To see errors directly you can start Hugin.app from the command line, e.g. from a terminal: <pre>$ Hugin.app/Contents/MacOS/Hugin &</pre> Alternatively you can double-click Hugin.app from Finder while following the (error) messages on <tt>/Applicatons/Utilities/Console.app</tt>.<br />
<br />
Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). The same crash logs may be displayed by the CrashReporter immediately after Hugin crashes. You can configure the CrashReporter's behaviour with <tt>/Developer/Applications/Utilities/CrashReporterPrefs.app</tt>.<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations! <br/><br />
Have a big celebration and have a happy hacking Hugin time!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
- [http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/index.html Cross-Development Programming Guide] and [http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/index.html Universal Binary Programming Guidelines, Second Edition]– more about building fully compatible universal binaries on OS X<br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10642Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T19:22:35Z<p>Ippei: /* '''External Links''' */</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Configure====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less.<br />
<br />
In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br /><br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
This build target updates the pre-release version tags, and is not propagated (does not automatically run) from other targets. You should run this target after every SVN update. Also, before compiling anything that you give away to other people, make sure that you "Clean all targets" and then build this "configure" target first.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "Hugin" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Quick test can be done by "Run" (Cmd-R) within Xcode. If Hugin launches, it's a party time!!! So, go party and when you're finished come back for the next test.<br />
<br />
"Run"ing in Xcode is useful for debugging with Xcode, but unfortunately using external executable within Hugin confuses the GDB and Xcode, so you cannot stitch or run autopano programs this way. If Hugin.app launches finely from Xcode, get to Finder and double-click the Huing.app icon and try to make a panorama. If that works fine, go for another glass of wine.<br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. <br />
<br />
As this is not always possible, You could follow the following dirty technique: <br /><br />
'''Warning:''' This is not exactly a safe operation. Do at your own risk. <br /><br />
*Copy your Hugin.app to another location on your mac and rename<br />
** your mac directory inside your hugin source directory to mac.org,<br />
** your /opt/local to /opt/local.org (in case you have Macports),<br />
** your /sw directory to /sw.org (in case you have Fink),<br />
** your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br /><br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br />
<br />
The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the library paths inside Hugin and inside the libraries to "internal" paths relative to the executable location, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br />
<br />
To see errors directly you can start Hugin.app from the command line, e.g. from a terminal: <pre>$ Hugin.app/Contents/MacOS/Hugin &</pre> Alternatively you can double-click Hugin.app from Finder while following the (error) messages on <tt>/Applicatons/Utilities/Console.app</tt>.<br />
<br />
Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). The same crash logs may be displayed by the CrashReporter immediately after Hugin crashes. You can configure the CrashReporter's behaviour with <tt>/Developer/Applications/Utilities/CrashReporterPrefs.app</tt>.<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations! <br/><br />
Have a big celebration and have a happy hacking Hugin time!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
- [http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/index.html Cross-Development Programming Guide] and [http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/index.html Universal Binary Programming Guidelines, Second Edition]– more about building fully compatible universal binaries on OS X<br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10641Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T19:18:59Z<p>Ippei: /* '''External Links''' */</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Configure====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less.<br />
<br />
In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br /><br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
This build target updates the pre-release version tags, and is not propagated (does not automatically run) from other targets. You should run this target after every SVN update. Also, before compiling anything that you give away to other people, make sure that you "Clean all targets" and then build this "configure" target first.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "Hugin" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Quick test can be done by "Run" (Cmd-R) within Xcode. If Hugin launches, it's a party time!!! So, go party and when you're finished come back for the next test.<br />
<br />
"Run"ing in Xcode is useful for debugging with Xcode, but unfortunately using external executable within Hugin confuses the GDB and Xcode, so you cannot stitch or run autopano programs this way. If Hugin.app launches finely from Xcode, get to Finder and double-click the Huing.app icon and try to make a panorama. If that works fine, go for another glass of wine.<br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. <br />
<br />
As this is not always possible, You could follow the following dirty technique: <br /><br />
'''Warning:''' This is not exactly a safe operation. Do at your own risk. <br /><br />
*Copy your Hugin.app to another location on your mac and rename<br />
** your mac directory inside your hugin source directory to mac.org,<br />
** your /opt/local to /opt/local.org (in case you have Macports),<br />
** your /sw directory to /sw.org (in case you have Fink),<br />
** your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br /><br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br />
<br />
The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the library paths inside Hugin and inside the libraries to "internal" paths relative to the executable location, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br />
<br />
To see errors directly you can start Hugin.app from the command line, e.g. from a terminal: <pre>$ Hugin.app/Contents/MacOS/Hugin &</pre> Alternatively you can double-click Hugin.app from Finder while following the (error) messages on <tt>/Applicatons/Utilities/Console.app</tt>.<br />
<br />
Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). The same crash logs may be displayed by the CrashReporter immediately after Hugin crashes. You can configure the CrashReporter's behaviour with <tt>/Developer/Applications/Utilities/CrashReporterPrefs.app</tt>.<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations! <br/><br />
Have a big celebration and have a happy hacking Hugin time!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
- [http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/index.html Cross-Development Programming Guide]<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]] – more about building universal binary on OS X</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10640Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T19:15:23Z<p>Ippei: /* Testing Hugin.app */</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Configure====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less.<br />
<br />
In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br /><br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
This build target updates the pre-release version tags, and is not propagated (does not automatically run) from other targets. You should run this target after every SVN update. Also, before compiling anything that you give away to other people, make sure that you "Clean all targets" and then build this "configure" target first.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "Hugin" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Quick test can be done by "Run" (Cmd-R) within Xcode. If Hugin launches, it's a party time!!! So, go party and when you're finished come back for the next test.<br />
<br />
"Run"ing in Xcode is useful for debugging with Xcode, but unfortunately using external executable within Hugin confuses the GDB and Xcode, so you cannot stitch or run autopano programs this way. If Hugin.app launches finely from Xcode, get to Finder and double-click the Huing.app icon and try to make a panorama. If that works fine, go for another glass of wine.<br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. <br />
<br />
As this is not always possible, You could follow the following dirty technique: <br /><br />
'''Warning:''' This is not exactly a safe operation. Do at your own risk. <br /><br />
*Copy your Hugin.app to another location on your mac and rename<br />
** your mac directory inside your hugin source directory to mac.org,<br />
** your /opt/local to /opt/local.org (in case you have Macports),<br />
** your /sw directory to /sw.org (in case you have Fink),<br />
** your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br /><br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br />
<br />
The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the library paths inside Hugin and inside the libraries to "internal" paths relative to the executable location, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br />
<br />
To see errors directly you can start Hugin.app from the command line, e.g. from a terminal: <pre>$ Hugin.app/Contents/MacOS/Hugin &</pre> Alternatively you can double-click Hugin.app from Finder while following the (error) messages on <tt>/Applicatons/Utilities/Console.app</tt>.<br />
<br />
Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). The same crash logs may be displayed by the CrashReporter immediately after Hugin crashes. You can configure the CrashReporter's behaviour with <tt>/Developer/Applications/Utilities/CrashReporterPrefs.app</tt>.<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations! <br/><br />
Have a big celebration and have a happy hacking Hugin time!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10639Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T19:00:27Z<p>Ippei: /* Testing Hugin.app */</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Configure====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less.<br />
<br />
In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br /><br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
This build target updates the pre-release version tags, and is not propagated (does not automatically run) from other targets. You should run this target after every SVN update. Also, before compiling anything that you give away to other people, make sure that you "Clean all targets" and then build this "configure" target first.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "Hugin" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Double-click it and try to make a panorama. If this works, it's party time!!! So, go party and when you're finished come back for the next test.<br /><br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. <br />
<br />
As this is not always possible, You could follow the following dirty technique: <br /><br />
'''Warning:''' This is not exactly a safe operation. Do at your own risk. <br /><br />
*Copy your Hugin.app to another location on your mac and rename<br /><br />
** your mac directory inside your hugin source directory to mac.org,<br />
** your /opt/local to /opt/local.org (in case you have Macports),<br />
** your /sw directory to /sw.org (in case you have Fink),<br />
** your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br /><br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br />
<br />
The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the library paths inside Hugin and inside the libraries to "internal" paths relative to the executable location, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br />
<br />
To see errors directly you can start Hugin.app from the command line, e.g. from a terminal: <pre>$ Hugin.app/Contents/MacOS/Hugin &</pre> Alternatively you can double-click Hugin.app from Finder while following the (error) messages on <tt>/Applicatons/Utilities/Console.app</tt>.<br />
<br />
Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). The same crash logs may be displayed by the CrashReporter immediately after Hugin crashes. You can configure the CrashReporter's behaviour with <tt>/Developer/Applications/Utilities/CrashReporterPrefs.app</tt>.<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10638Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T18:42:22Z<p>Ippei: /* Building Hugin.app */</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Configure====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less.<br />
<br />
In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br /><br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
This build target updates the pre-release version tags, and is not propagated (does not automatically run) from other targets. You should run this target after every SVN update. Also, before compiling anything that you give away to other people, make sure that you "Clean all targets" and then build this "configure" target first.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "Hugin" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Double-click it and try to make a panorama. If this works, it's party time!!! So, go party and when you're finished come back for the next test.<br /><br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. As this is not always possible, copy your Hugin.app to another location on your mac and rename<br /><br />
* your mac directory inside your hugin source directory to mac.org,<br />
* your /opt/local to /opt/local.org (in case you have Macports),<br />
* your /sw directory to /sw.org (in case you have Fink),<br />
* your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br /> The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the "hard linked" paths inside Hugin and inside the libraries to "internal" paths, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br /><br />
<br />
''Note:'' To see errors directly you need to start Hugin.app from the command line, e.g. from a terminal. Issue the command <pre>$ open Hugin.app &</pre> to do that (in case you didn't know). If you double-click Hugin.app from Finder you won't see (error) messages.<br />Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). <br />
<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10637Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T18:41:15Z<p>Ippei: /* Final check */</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Configure====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less.<br />
<br />
In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br /><br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
This build target updates the pre-release version tags, and is not propagated (does not automatically run) from other targets. You should run this target after every SVN update. Also, before compiling anything that you give away to other people, make sure that you "Clean all targets" and then build this "configure" target first.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "all" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Double-click it and try to make a panorama. If this works, it's party time!!! So, go party and when you're finished come back for the next test.<br /><br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. As this is not always possible, copy your Hugin.app to another location on your mac and rename<br /><br />
* your mac directory inside your hugin source directory to mac.org,<br />
* your /opt/local to /opt/local.org (in case you have Macports),<br />
* your /sw directory to /sw.org (in case you have Fink),<br />
* your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br /> The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the "hard linked" paths inside Hugin and inside the libraries to "internal" paths, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br /><br />
<br />
''Note:'' To see errors directly you need to start Hugin.app from the command line, e.g. from a terminal. Issue the command <pre>$ open Hugin.app &</pre> to do that (in case you didn't know). If you double-click Hugin.app from Finder you won't see (error) messages.<br />Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). <br />
<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10636Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T18:32:49Z<p>Ippei: /* Prepare the project for our configuration */</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br />
<br />
You can use Subversion with Xcode. It is a very handy feature to use in order to keep the files up-to-date and, especially with [http://developer.apple.com/documentation/DeveloperTools/Conceptual/XcodeSourceManagement/30_Source_Control/chapter_3_section_2.html Xcode 3's improved Subversion integration], to commit changes back to repository. Follow the configuration of "SCM System".<br />
<br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
This is the list of master configuration of the project. The values that you have set in <tt>BuildConfig.xcconfig</tt> (above) are reflected, and referenced by other settings. All relative paths are relative to the location of the hugin.xcodeproj directory structure. You should not need to change anything, but do check. Please note some of the settings are different among "Configuration", e.g. Release, Debug, Development, etc. but paths should not be different among them.<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Compile and build our Hugin.app===<br />
====Final check====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less. In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br />
<br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "all" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Double-click it and try to make a panorama. If this works, it's party time!!! So, go party and when you're finished come back for the next test.<br /><br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. As this is not always possible, copy your Hugin.app to another location on your mac and rename<br /><br />
* your mac directory inside your hugin source directory to mac.org,<br />
* your /opt/local to /opt/local.org (in case you have Macports),<br />
* your /sw directory to /sw.org (in case you have Fink),<br />
* your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br /> The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the "hard linked" paths inside Hugin and inside the libraries to "internal" paths, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br /><br />
<br />
''Note:'' To see errors directly you need to start Hugin.app from the command line, e.g. from a terminal. Issue the command <pre>$ open Hugin.app &</pre> to do that (in case you didn't know). If you double-click Hugin.app from Finder you won't see (error) messages.<br />Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). <br />
<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10635Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T18:08:45Z<p>Ippei: /* Prepare the scripts before building */ remove obsolete</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br /><br /><br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
You need to check, and if necessary change, the values for:<br />
* Library Search Paths<br />
* REPOSITORY_DIR<br />
* WX_INCLUDE_DIR<br />
* WX_INCLUDE_DIR_LIB<br />
* WX_MAJOR_VERSOIN (note that it says VERSOIN in stead of VERSION. Leave it like that!)<br />
All path's are relative to the location of the hugin.xcodeproj directory structure. If you did build the libraries that Hugin depends on according the steps described above, you do not need to change anything. But do check!<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
<br />
<br />
===Compile and build our Hugin.app===<br />
====Final check====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less. In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br />
<br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "all" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Double-click it and try to make a panorama. If this works, it's party time!!! So, go party and when you're finished come back for the next test.<br /><br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. As this is not always possible, copy your Hugin.app to another location on your mac and rename<br /><br />
* your mac directory inside your hugin source directory to mac.org,<br />
* your /opt/local to /opt/local.org (in case you have Macports),<br />
* your /sw directory to /sw.org (in case you have Fink),<br />
* your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br /> The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the "hard linked" paths inside Hugin and inside the libraries to "internal" paths, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br /><br />
<br />
''Note:'' To see errors directly you need to start Hugin.app from the command line, e.g. from a terminal. Issue the command <pre>$ open Hugin.app &</pre> to do that (in case you didn't know). If you double-click Hugin.app from Finder you won't see (error) messages.<br />Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). <br />
<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10634Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T18:07:57Z<p>Ippei: /* Xcode compiling Hugin */ added BuildConfig.xcconfig</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===BuildConfig.xcconfig===<br />
First, you should edit the configuration file. Duplicate <tt>BuildConfig.xcconfig.orig</tt> and name the new copy "'''<tt>BuildConfig.xcconfig</tt>'''". <br />
<br />
Inside, you will find variables that needs be matched with your External Programs configuration. Please edit at least the following variables accordingly:<br />
<pre><br />
REPOSITORY_ABSOLUTE_PATH<br />
WX_LOCALE_DIR<br />
EXIFTOOL_DIR<br />
</pre><br />
<br />
If you have chosen to compile 4-way universal binary with 64bit support, uncomment <tt>RELEASE_ARCHS_64</tt> line.<br />
<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use Xcode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br /><br /><br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
You need to check, and if necessary change, the values for:<br />
* Library Search Paths<br />
* REPOSITORY_DIR<br />
* WX_INCLUDE_DIR<br />
* WX_INCLUDE_DIR_LIB<br />
* WX_MAJOR_VERSOIN (note that it says VERSOIN in stead of VERSION. Leave it like that!)<br />
All path's are relative to the location of the hugin.xcodeproj directory structure. If you did build the libraries that Hugin depends on according the steps described above, you do not need to change anything. But do check!<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Prepare the scripts before building===<br />
<table border="0" width="600"><TR><TD>[[Image:Xcode script preparation.png | left | frame | 271px | Some of the necessary scripts]]</TD><TD valign="TOP"> The project uses a couple of shell scripts to get everything into the bundle. In an Xcode project you can define steps for this in your Targets. These steps then consist of these scripts.<br />
Note though that if these scripts are not correct, Xcode will generate a non-fatal error. However, this non-fatal error for Xcode will quite often be a fatal error for your final bundle as it will miss "something" and it will simply not run or not run correctly.<br />
Yoy can take a look at the target Hugin: Open Targets -> Hugin and double-click (for example) the entry "Complete bundle". This will show you how to embed scripts.<br />
Note however, that you do not edit the scripts from the Target(s) position. You edit the script inside the files section (see [[#XCode basic walk-through]]). In this project everything is already at it's correct position. </TD></TR></TABLE><br />
<br />
<br />
<br />
====Edit localised.sh====<br />
Move (back) in the navigation pane to the top of your project and open the top section (the "file" section), open the <tt>mac</tt> "directory" and locate <tt>localised.sh</tt>. Double-click <tt>localised.sh</tt> to open it.<br />
In the top of the script you will find the following lines:<br />
<pre>huginVer="$HUGIN_PACKAGE_VERSION"<br />
wxDir="./ExternalPrograms/wxMac-2.8.7"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
huginsrcdir="../src/hugin1/hugin"<br />
xrcsrcdir="$huginsrcdir/xrc"<br />
translationsdir="../src/translations"<br />
</pre><br />
Change the <tt>wxDir</tt> to the directory where your wxmac '''source code''' resides.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit Complete-bundle.sh====<br />
Locate the <tt>Complete-bundle.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>dylib_dir="../mac/ExternalPrograms/repository/lib"<br />
old_install_name_dirname="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib"<br />
dylib_install_loc="Libraries"<br />
new_install_name_dirname="@executable_path/../$dylib_install_loc"<br />
</pre><br />
Change the <tt>dylib_dir</tt> to the correct relative path.<br /><br />
Change the <tt>old_install_name_dirname</tt> to the correct '''absolute''' path.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit copyExifTool.sh====<br />
If you have Exiftool on your system, you need to edit this script too. As mentioned in the early lines of [[#Prepare the scripts before building]] Xcode will generate a non-fatal error if Exiftool is not available (or if you configured the script incorrectly), but in this case Hugin will run without it as it is an "extra" tool and Hugin can run without it.<br /><br />
Locate the <tt>copyExifTool.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>exiftoolDir="./ExternalPrograms/Image-ExifTool-7.25"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
</pre><br />
Change the <tt>exiftoolDir</tt> path to the path where your Exiftool resides.<br /><br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
===Compile and build our Hugin.app===<br />
====Final check====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less. In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br />
<br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "all" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Double-click it and try to make a panorama. If this works, it's party time!!! So, go party and when you're finished come back for the next test.<br /><br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. As this is not always possible, copy your Hugin.app to another location on your mac and rename<br /><br />
* your mac directory inside your hugin source directory to mac.org,<br />
* your /opt/local to /opt/local.org (in case you have Macports),<br />
* your /sw directory to /sw.org (in case you have Fink),<br />
* your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br /> The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the "hard linked" paths inside Hugin and inside the libraries to "internal" paths, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br /><br />
<br />
''Note:'' To see errors directly you need to start Hugin.app from the command line, e.g. from a terminal. Issue the command <pre>$ open Hugin.app &</pre> to do that (in case you didn't know). If you double-click Hugin.app from Finder you won't see (error) messages.<br />Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). <br />
<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10633Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T17:49:35Z<p>Ippei: /* External Programs */</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs and their versions that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use XCode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br /><br /><br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
You need to check, and if necessary change, the values for:<br />
* Library Search Paths<br />
* REPOSITORY_DIR<br />
* WX_INCLUDE_DIR<br />
* WX_INCLUDE_DIR_LIB<br />
* WX_MAJOR_VERSOIN (note that it says VERSOIN in stead of VERSION. Leave it like that!)<br />
All path's are relative to the location of the hugin.xcodeproj directory structure. If you did build the libraries that Hugin depends on according the steps described above, you do not need to change anything. But do check!<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Prepare the scripts before building===<br />
<table border="0" width="600"><TR><TD>[[Image:Xcode script preparation.png | left | frame | 271px | Some of the necessary scripts]]</TD><TD valign="TOP"> The project uses a couple of shell scripts to get everything into the bundle. In an Xcode project you can define steps for this in your Targets. These steps then consist of these scripts.<br />
Note though that if these scripts are not correct, Xcode will generate a non-fatal error. However, this non-fatal error for Xcode will quite often be a fatal error for your final bundle as it will miss "something" and it will simply not run or not run correctly.<br />
Yoy can take a look at the target Hugin: Open Targets -> Hugin and double-click (for example) the entry "Complete bundle". This will show you how to embed scripts.<br />
Note however, that you do not edit the scripts from the Target(s) position. You edit the script inside the files section (see [[#XCode basic walk-through]]). In this project everything is already at it's correct position. </TD></TR></TABLE><br />
<br />
<br />
<br />
====Edit localised.sh====<br />
Move (back) in the navigation pane to the top of your project and open the top section (the "file" section), open the <tt>mac</tt> "directory" and locate <tt>localised.sh</tt>. Double-click <tt>localised.sh</tt> to open it.<br />
In the top of the script you will find the following lines:<br />
<pre>huginVer="$HUGIN_PACKAGE_VERSION"<br />
wxDir="./ExternalPrograms/wxMac-2.8.7"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
huginsrcdir="../src/hugin1/hugin"<br />
xrcsrcdir="$huginsrcdir/xrc"<br />
translationsdir="../src/translations"<br />
</pre><br />
Change the <tt>wxDir</tt> to the directory where your wxmac '''source code''' resides.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit Complete-bundle.sh====<br />
Locate the <tt>Complete-bundle.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>dylib_dir="../mac/ExternalPrograms/repository/lib"<br />
old_install_name_dirname="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib"<br />
dylib_install_loc="Libraries"<br />
new_install_name_dirname="@executable_path/../$dylib_install_loc"<br />
</pre><br />
Change the <tt>dylib_dir</tt> to the correct relative path.<br /><br />
Change the <tt>old_install_name_dirname</tt> to the correct '''absolute''' path.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit copyExifTool.sh====<br />
If you have Exiftool on your system, you need to edit this script too. As mentioned in the early lines of [[#Prepare the scripts before building]] Xcode will generate a non-fatal error if Exiftool is not available (or if you configured the script incorrectly), but in this case Hugin will run without it as it is an "extra" tool and Hugin can run without it.<br /><br />
Locate the <tt>copyExifTool.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>exiftoolDir="./ExternalPrograms/Image-ExifTool-7.25"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
</pre><br />
Change the <tt>exiftoolDir</tt> path to the path where your Exiftool resides.<br /><br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
===Compile and build our Hugin.app===<br />
====Final check====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less. In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br />
<br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "all" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Double-click it and try to make a panorama. If this works, it's party time!!! So, go party and when you're finished come back for the next test.<br /><br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. As this is not always possible, copy your Hugin.app to another location on your mac and rename<br /><br />
* your mac directory inside your hugin source directory to mac.org,<br />
* your /opt/local to /opt/local.org (in case you have Macports),<br />
* your /sw directory to /sw.org (in case you have Fink),<br />
* your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br /> The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the "hard linked" paths inside Hugin and inside the libraries to "internal" paths, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br /><br />
<br />
''Note:'' To see errors directly you need to start Hugin.app from the command line, e.g. from a terminal. Issue the command <pre>$ open Hugin.app &</pre> to do that (in case you didn't know). If you double-click Hugin.app from Finder you won't see (error) messages.<br />Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). <br />
<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10632Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T17:49:09Z<p>Ippei: /* Order of building the "External Programs" */</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names):<br /><br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the executables:<br /><br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh, panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use XCode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br /><br /><br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
You need to check, and if necessary change, the values for:<br />
* Library Search Paths<br />
* REPOSITORY_DIR<br />
* WX_INCLUDE_DIR<br />
* WX_INCLUDE_DIR_LIB<br />
* WX_MAJOR_VERSOIN (note that it says VERSOIN in stead of VERSION. Leave it like that!)<br />
All path's are relative to the location of the hugin.xcodeproj directory structure. If you did build the libraries that Hugin depends on according the steps described above, you do not need to change anything. But do check!<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Prepare the scripts before building===<br />
<table border="0" width="600"><TR><TD>[[Image:Xcode script preparation.png | left | frame | 271px | Some of the necessary scripts]]</TD><TD valign="TOP"> The project uses a couple of shell scripts to get everything into the bundle. In an Xcode project you can define steps for this in your Targets. These steps then consist of these scripts.<br />
Note though that if these scripts are not correct, Xcode will generate a non-fatal error. However, this non-fatal error for Xcode will quite often be a fatal error for your final bundle as it will miss "something" and it will simply not run or not run correctly.<br />
Yoy can take a look at the target Hugin: Open Targets -> Hugin and double-click (for example) the entry "Complete bundle". This will show you how to embed scripts.<br />
Note however, that you do not edit the scripts from the Target(s) position. You edit the script inside the files section (see [[#XCode basic walk-through]]). In this project everything is already at it's correct position. </TD></TR></TABLE><br />
<br />
<br />
<br />
====Edit localised.sh====<br />
Move (back) in the navigation pane to the top of your project and open the top section (the "file" section), open the <tt>mac</tt> "directory" and locate <tt>localised.sh</tt>. Double-click <tt>localised.sh</tt> to open it.<br />
In the top of the script you will find the following lines:<br />
<pre>huginVer="$HUGIN_PACKAGE_VERSION"<br />
wxDir="./ExternalPrograms/wxMac-2.8.7"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
huginsrcdir="../src/hugin1/hugin"<br />
xrcsrcdir="$huginsrcdir/xrc"<br />
translationsdir="../src/translations"<br />
</pre><br />
Change the <tt>wxDir</tt> to the directory where your wxmac '''source code''' resides.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit Complete-bundle.sh====<br />
Locate the <tt>Complete-bundle.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>dylib_dir="../mac/ExternalPrograms/repository/lib"<br />
old_install_name_dirname="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib"<br />
dylib_install_loc="Libraries"<br />
new_install_name_dirname="@executable_path/../$dylib_install_loc"<br />
</pre><br />
Change the <tt>dylib_dir</tt> to the correct relative path.<br /><br />
Change the <tt>old_install_name_dirname</tt> to the correct '''absolute''' path.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit copyExifTool.sh====<br />
If you have Exiftool on your system, you need to edit this script too. As mentioned in the early lines of [[#Prepare the scripts before building]] Xcode will generate a non-fatal error if Exiftool is not available (or if you configured the script incorrectly), but in this case Hugin will run without it as it is an "extra" tool and Hugin can run without it.<br /><br />
Locate the <tt>copyExifTool.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>exiftoolDir="./ExternalPrograms/Image-ExifTool-7.25"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
</pre><br />
Change the <tt>exiftoolDir</tt> path to the path where your Exiftool resides.<br /><br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
===Compile and build our Hugin.app===<br />
====Final check====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less. In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br />
<br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "all" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Double-click it and try to make a panorama. If this works, it's party time!!! So, go party and when you're finished come back for the next test.<br /><br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. As this is not always possible, copy your Hugin.app to another location on your mac and rename<br /><br />
* your mac directory inside your hugin source directory to mac.org,<br />
* your /opt/local to /opt/local.org (in case you have Macports),<br />
* your /sw directory to /sw.org (in case you have Fink),<br />
* your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br /> The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the "hard linked" paths inside Hugin and inside the libraries to "internal" paths, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br /><br />
<br />
''Note:'' To see errors directly you need to start Hugin.app from the command line, e.g. from a terminal. Issue the command <pre>$ open Hugin.app &</pre> to do that (in case you didn't know). If you double-click Hugin.app from Finder you won't see (error) messages.<br />Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). <br />
<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10631Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T17:06:28Z<p>Ippei: organisation, building</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Installing Subversion (SVN)===<br />
''(Note: Tiger users only)''<br />
<br />
Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to install it yourself.<br />
<br />
====MacPorts====<br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
====Fink====<br />
If you use Fink:<br />
<blockquote><pre>$ fink -b install svn</pre></blockquote><br />
or<br />
<blockquote><pre>$ sudo apt-get install svn</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
===="Inside" approach====<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
===="Outside" approach====<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and then create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><pre><br />
$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"<br />
$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"<br />
$ mkdir -p "$myExternalProgramsDir"<br />
$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"<br />
$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"<br />
$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"<br />
</pre></blockquote><br />
<br />
=='''Building the "External Programs"'''==<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you cannot resist to customise something for yourself.<br />
<br />
===External Programs===<br />
The list of programs that you should compile are given in the <tt>hugin/mac/ExternalPrograms/readme.txt</tt>. Some libraries are recommended not to be compiled as dynamically linked library, but as statically linked library instead. The scripts for static build are found in <tt>hugin/mac/ExternalPrograms/scripts/static/</tt>. <br />
<br />
''Note:'' There is a good chance those build scripts not on the list are outdated and do not work.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre><br />
$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24<br />
</pre></blockquote><br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names): <br />
boost.sh, libexpat.sh, libjpeg.sh, libpng.sh, libtiff.sh, wxmac28.sh, ilmbase.sh, openexr16.sh, pano13.sh, static/libexiv2.sh, static/lcms.sh, static/libxmi.sh, (static/glew.sh)<br />
<br />
And for the binaries:<br />
gnumake.sh, enblend31.sh, (autopano-sift-C.sh), (panomatic.sh)<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use XCode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br /><br /><br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
You need to check, and if necessary change, the values for:<br />
* Library Search Paths<br />
* REPOSITORY_DIR<br />
* WX_INCLUDE_DIR<br />
* WX_INCLUDE_DIR_LIB<br />
* WX_MAJOR_VERSOIN (note that it says VERSOIN in stead of VERSION. Leave it like that!)<br />
All path's are relative to the location of the hugin.xcodeproj directory structure. If you did build the libraries that Hugin depends on according the steps described above, you do not need to change anything. But do check!<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Prepare the scripts before building===<br />
<table border="0" width="600"><TR><TD>[[Image:Xcode script preparation.png | left | frame | 271px | Some of the necessary scripts]]</TD><TD valign="TOP"> The project uses a couple of shell scripts to get everything into the bundle. In an Xcode project you can define steps for this in your Targets. These steps then consist of these scripts.<br />
Note though that if these scripts are not correct, Xcode will generate a non-fatal error. However, this non-fatal error for Xcode will quite often be a fatal error for your final bundle as it will miss "something" and it will simply not run or not run correctly.<br />
Yoy can take a look at the target Hugin: Open Targets -> Hugin and double-click (for example) the entry "Complete bundle". This will show you how to embed scripts.<br />
Note however, that you do not edit the scripts from the Target(s) position. You edit the script inside the files section (see [[#XCode basic walk-through]]). In this project everything is already at it's correct position. </TD></TR></TABLE><br />
<br />
<br />
<br />
====Edit localised.sh====<br />
Move (back) in the navigation pane to the top of your project and open the top section (the "file" section), open the <tt>mac</tt> "directory" and locate <tt>localised.sh</tt>. Double-click <tt>localised.sh</tt> to open it.<br />
In the top of the script you will find the following lines:<br />
<pre>huginVer="$HUGIN_PACKAGE_VERSION"<br />
wxDir="./ExternalPrograms/wxMac-2.8.7"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
huginsrcdir="../src/hugin1/hugin"<br />
xrcsrcdir="$huginsrcdir/xrc"<br />
translationsdir="../src/translations"<br />
</pre><br />
Change the <tt>wxDir</tt> to the directory where your wxmac '''source code''' resides.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit Complete-bundle.sh====<br />
Locate the <tt>Complete-bundle.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>dylib_dir="../mac/ExternalPrograms/repository/lib"<br />
old_install_name_dirname="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib"<br />
dylib_install_loc="Libraries"<br />
new_install_name_dirname="@executable_path/../$dylib_install_loc"<br />
</pre><br />
Change the <tt>dylib_dir</tt> to the correct relative path.<br /><br />
Change the <tt>old_install_name_dirname</tt> to the correct '''absolute''' path.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit copyExifTool.sh====<br />
If you have Exiftool on your system, you need to edit this script too. As mentioned in the early lines of [[#Prepare the scripts before building]] Xcode will generate a non-fatal error if Exiftool is not available (or if you configured the script incorrectly), but in this case Hugin will run without it as it is an "extra" tool and Hugin can run without it.<br /><br />
Locate the <tt>copyExifTool.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>exiftoolDir="./ExternalPrograms/Image-ExifTool-7.25"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
</pre><br />
Change the <tt>exiftoolDir</tt> path to the path where your Exiftool resides.<br /><br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
===Compile and build our Hugin.app===<br />
====Final check====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less. In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br />
<br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "all" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Double-click it and try to make a panorama. If this works, it's party time!!! So, go party and when you're finished come back for the next test.<br /><br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. As this is not always possible, copy your Hugin.app to another location on your mac and rename<br /><br />
* your mac directory inside your hugin source directory to mac.org,<br />
* your /opt/local to /opt/local.org (in case you have Macports),<br />
* your /sw directory to /sw.org (in case you have Fink),<br />
* your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br /> The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the "hard linked" paths inside Hugin and inside the libraries to "internal" paths, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br /><br />
<br />
''Note:'' To see errors directly you need to start Hugin.app from the command line, e.g. from a terminal. Issue the command <pre>$ open Hugin.app &</pre> to do that (in case you didn't know). If you double-click Hugin.app from Finder you won't see (error) messages.<br />Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). <br />
<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10630Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T16:20:05Z<p>Ippei: /* 32bit versus 64bit */</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and to create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><br />
<tt>$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"</tt><br /><br />
<tt>$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"</tt><br /><br />
<tt>$ mkdir -p "$myExternalProgramsDir"</tt><br /><br />
<tt>$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"</tt><br /><br />
<tt>$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"</tt><br /><br />
<tt>$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"</tt><br /><br />
</blockquote><br />
<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you are brave enough to customise something for yourself.<br />
<br />
=='''Building the "External Programs"'''==<br />
===Building Subversion (SVN)===<br />
''(Note: Tiger and earlier only)''<br />Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to build it yourself.<br /><br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Get MacPorts and/or Fink out of the way===<br />
Now we really need to get MacPorts and/or Fink out of the way. We want to make a completely separate development tree. This means that we do not want to link to any library or binary outside our "External Programs" development tree (unless they are true Mac system libraries that are part of your MacOSX version). If we accidentally ''do'' link to non-system libraries outside our tree we will have problems when we build the bundle and certainly when we want to distribute it. So to get them out of the way, we do the following:<br />
<blockquote><pre>$ sudo mv /opt /opt.org<br />
$ sudo mv /sw /sw.org<br />
$ sudo mv /usr/local /usr/local.org</pre></blockquote><br />
Note: The <tt>usr/local</tt> is in case you have built libraries or binaries without MacPorts or Fink.<br /><br />
'''Note 2: Do not use "<tt>sudo mv /usr /usr.org</tt>" as <tt>/usr</tt> is vital for proper system functioning!!!''' If you accidentally do this, you need to reboot using your Mac DVD, go into the terminal and move it back.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre>$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24</pre></blockquote><br />
<br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv-universal.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names): <br />
libjpeg.sh, libtiff.sh, libpng.sh, expat.sh, lcms.sh, ilmbase.sh, openexr16.sh, boost.sh, wxmac28.sh, pano13.sh, libexiv2.sh<br />
<br />
And for the binaries:<br />
gnumake.sh, autopano-sift-C.sh, enblend31.sh, panomatic.sh<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use XCode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br /><br /><br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
You need to check, and if necessary change, the values for:<br />
* Library Search Paths<br />
* REPOSITORY_DIR<br />
* WX_INCLUDE_DIR<br />
* WX_INCLUDE_DIR_LIB<br />
* WX_MAJOR_VERSOIN (note that it says VERSOIN in stead of VERSION. Leave it like that!)<br />
All path's are relative to the location of the hugin.xcodeproj directory structure. If you did build the libraries that Hugin depends on according the steps described above, you do not need to change anything. But do check!<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Prepare the scripts before building===<br />
<table border="0" width="600"><TR><TD>[[Image:Xcode script preparation.png | left | frame | 271px | Some of the necessary scripts]]</TD><TD valign="TOP"> The project uses a couple of shell scripts to get everything into the bundle. In an Xcode project you can define steps for this in your Targets. These steps then consist of these scripts.<br />
Note though that if these scripts are not correct, Xcode will generate a non-fatal error. However, this non-fatal error for Xcode will quite often be a fatal error for your final bundle as it will miss "something" and it will simply not run or not run correctly.<br />
Yoy can take a look at the target Hugin: Open Targets -> Hugin and double-click (for example) the entry "Complete bundle". This will show you how to embed scripts.<br />
Note however, that you do not edit the scripts from the Target(s) position. You edit the script inside the files section (see [[#XCode basic walk-through]]). In this project everything is already at it's correct position. </TD></TR></TABLE><br />
<br />
<br />
<br />
====Edit localised.sh====<br />
Move (back) in the navigation pane to the top of your project and open the top section (the "file" section), open the <tt>mac</tt> "directory" and locate <tt>localised.sh</tt>. Double-click <tt>localised.sh</tt> to open it.<br />
In the top of the script you will find the following lines:<br />
<pre>huginVer="$HUGIN_PACKAGE_VERSION"<br />
wxDir="./ExternalPrograms/wxMac-2.8.7"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
huginsrcdir="../src/hugin1/hugin"<br />
xrcsrcdir="$huginsrcdir/xrc"<br />
translationsdir="../src/translations"<br />
</pre><br />
Change the <tt>wxDir</tt> to the directory where your wxmac '''source code''' resides.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit Complete-bundle.sh====<br />
Locate the <tt>Complete-bundle.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>dylib_dir="../mac/ExternalPrograms/repository/lib"<br />
old_install_name_dirname="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib"<br />
dylib_install_loc="Libraries"<br />
new_install_name_dirname="@executable_path/../$dylib_install_loc"<br />
</pre><br />
Change the <tt>dylib_dir</tt> to the correct relative path.<br /><br />
Change the <tt>old_install_name_dirname</tt> to the correct '''absolute''' path.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit copyExifTool.sh====<br />
If you have Exiftool on your system, you need to edit this script too. As mentioned in the early lines of [[#Prepare the scripts before building]] Xcode will generate a non-fatal error if Exiftool is not available (or if you configured the script incorrectly), but in this case Hugin will run without it as it is an "extra" tool and Hugin can run without it.<br /><br />
Locate the <tt>copyExifTool.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>exiftoolDir="./ExternalPrograms/Image-ExifTool-7.25"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
</pre><br />
Change the <tt>exiftoolDir</tt> path to the path where your Exiftool resides.<br /><br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
===Compile and build our Hugin.app===<br />
====Final check====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less. In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br />
<br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "all" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Double-click it and try to make a panorama. If this works, it's party time!!! So, go party and when you're finished come back for the next test.<br /><br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. As this is not always possible, copy your Hugin.app to another location on your mac and rename<br /><br />
* your mac directory inside your hugin source directory to mac.org,<br />
* your /opt/local to /opt/local.org (in case you have Macports),<br />
* your /sw directory to /sw.org (in case you have Fink),<br />
* your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br /> The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the "hard linked" paths inside Hugin and inside the libraries to "internal" paths, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br /><br />
<br />
''Note:'' To see errors directly you need to start Hugin.app from the command line, e.g. from a terminal. Issue the command <pre>$ open Hugin.app &</pre> to do that (in case you didn't know). If you double-click Hugin.app from Finder you won't see (error) messages.<br />Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). <br />
<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC64 and x86_64. If you want to do this, you should refer to SetEnv-leopard.txt. At this moment this is "''utterly experimental''" as:<br />
:# some "Linux derived" libraries and binaries may not work properly.<br />
:# they are not well optimized for Core 2 processors.<br />
:# most users do not benefit from 64bit because it is required only when making a huge panorama (>2GB).<br />
:# 64bit part is only for Leopard users on 64bit hardware (G5, Xeon, or Core 2). Those platforms can run 32bit anyway.<br />
:# almost doubles the binary size. The 2-part universal version alone weighs more than 65MB.<br />
<br />
Use at your own risk.<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10629Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T16:06:38Z<p>Ippei: /* Prepare the build environment */</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and to create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><br />
<tt>$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"</tt><br /><br />
<tt>$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"</tt><br /><br />
<tt>$ mkdir -p "$myExternalProgramsDir"</tt><br /><br />
<tt>$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"</tt><br /><br />
<tt>$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"</tt><br /><br />
<tt>$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"</tt><br /><br />
</blockquote><br />
<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. The template of those variables can be found inside <tt>hugin/mac/ExternalPrograms/scripts</tt>, named "<tt>SetEnv-universal.txt</tt>" and "<tt>SetEnv-leopard.txt</tt>". <tt>SetEnv-universal.txt</tt> is for conventional 2-way universal binary, and <tt>SetEnv-leopard.txt</tt> is for 4-way universal binary with 64bit computing support. We take <tt>SetEnv-universal.txt</tt> in this document. Read [[#32bit versus 64bit]] for more info.<br />
<br />
First, you should copy either of those files and name it "<tt>SetEnv.txt</tt>". In the top of this new file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/PATH2HUGIN/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use. This example show the (current) default one from the SVN. So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br />
<br />
You do not need to modify anything below this line, unless you are brave enough to customise something for yourself.<br />
<br />
=='''Building the "External Programs"'''==<br />
===Building Subversion (SVN)===<br />
''(Note: Tiger and earlier only)''<br />Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to build it yourself.<br /><br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Get MacPorts and/or Fink out of the way===<br />
Now we really need to get MacPorts and/or Fink out of the way. We want to make a completely separate development tree. This means that we do not want to link to any library or binary outside our "External Programs" development tree (unless they are true Mac system libraries that are part of your MacOSX version). If we accidentally ''do'' link to non-system libraries outside our tree we will have problems when we build the bundle and certainly when we want to distribute it. So to get them out of the way, we do the following:<br />
<blockquote><pre>$ sudo mv /opt /opt.org<br />
$ sudo mv /sw /sw.org<br />
$ sudo mv /usr/local /usr/local.org</pre></blockquote><br />
Note: The <tt>usr/local</tt> is in case you have built libraries or binaries without MacPorts or Fink.<br /><br />
'''Note 2: Do not use "<tt>sudo mv /usr /usr.org</tt>" as <tt>/usr</tt> is vital for proper system functioning!!!''' If you accidentally do this, you need to reboot using your Mac DVD, go into the terminal and move it back.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre>$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24</pre></blockquote><br />
<br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv-universal.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names): <br />
libjpeg.sh, libtiff.sh, libpng.sh, expat.sh, lcms.sh, ilmbase.sh, openexr16.sh, boost.sh, wxmac28.sh, pano13.sh, libexiv2.sh<br />
<br />
And for the binaries:<br />
gnumake.sh, autopano-sift-C.sh, enblend31.sh, panomatic.sh<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use XCode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br /><br /><br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
You need to check, and if necessary change, the values for:<br />
* Library Search Paths<br />
* REPOSITORY_DIR<br />
* WX_INCLUDE_DIR<br />
* WX_INCLUDE_DIR_LIB<br />
* WX_MAJOR_VERSOIN (note that it says VERSOIN in stead of VERSION. Leave it like that!)<br />
All path's are relative to the location of the hugin.xcodeproj directory structure. If you did build the libraries that Hugin depends on according the steps described above, you do not need to change anything. But do check!<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Prepare the scripts before building===<br />
<table border="0" width="600"><TR><TD>[[Image:Xcode script preparation.png | left | frame | 271px | Some of the necessary scripts]]</TD><TD valign="TOP"> The project uses a couple of shell scripts to get everything into the bundle. In an Xcode project you can define steps for this in your Targets. These steps then consist of these scripts.<br />
Note though that if these scripts are not correct, Xcode will generate a non-fatal error. However, this non-fatal error for Xcode will quite often be a fatal error for your final bundle as it will miss "something" and it will simply not run or not run correctly.<br />
Yoy can take a look at the target Hugin: Open Targets -> Hugin and double-click (for example) the entry "Complete bundle". This will show you how to embed scripts.<br />
Note however, that you do not edit the scripts from the Target(s) position. You edit the script inside the files section (see [[#XCode basic walk-through]]). In this project everything is already at it's correct position. </TD></TR></TABLE><br />
<br />
<br />
<br />
====Edit localised.sh====<br />
Move (back) in the navigation pane to the top of your project and open the top section (the "file" section), open the <tt>mac</tt> "directory" and locate <tt>localised.sh</tt>. Double-click <tt>localised.sh</tt> to open it.<br />
In the top of the script you will find the following lines:<br />
<pre>huginVer="$HUGIN_PACKAGE_VERSION"<br />
wxDir="./ExternalPrograms/wxMac-2.8.7"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
huginsrcdir="../src/hugin1/hugin"<br />
xrcsrcdir="$huginsrcdir/xrc"<br />
translationsdir="../src/translations"<br />
</pre><br />
Change the <tt>wxDir</tt> to the directory where your wxmac '''source code''' resides.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit Complete-bundle.sh====<br />
Locate the <tt>Complete-bundle.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>dylib_dir="../mac/ExternalPrograms/repository/lib"<br />
old_install_name_dirname="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib"<br />
dylib_install_loc="Libraries"<br />
new_install_name_dirname="@executable_path/../$dylib_install_loc"<br />
</pre><br />
Change the <tt>dylib_dir</tt> to the correct relative path.<br /><br />
Change the <tt>old_install_name_dirname</tt> to the correct '''absolute''' path.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit copyExifTool.sh====<br />
If you have Exiftool on your system, you need to edit this script too. As mentioned in the early lines of [[#Prepare the scripts before building]] Xcode will generate a non-fatal error if Exiftool is not available (or if you configured the script incorrectly), but in this case Hugin will run without it as it is an "extra" tool and Hugin can run without it.<br /><br />
Locate the <tt>copyExifTool.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>exiftoolDir="./ExternalPrograms/Image-ExifTool-7.25"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
</pre><br />
Change the <tt>exiftoolDir</tt> path to the path where your Exiftool resides.<br /><br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
===Compile and build our Hugin.app===<br />
====Final check====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less. In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br />
<br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "all" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Double-click it and try to make a panorama. If this works, it's party time!!! So, go party and when you're finished come back for the next test.<br /><br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. As this is not always possible, copy your Hugin.app to another location on your mac and rename<br /><br />
* your mac directory inside your hugin source directory to mac.org,<br />
* your /opt/local to /opt/local.org (in case you have Macports),<br />
* your /sw directory to /sw.org (in case you have Fink),<br />
* your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br /> The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the "hard linked" paths inside Hugin and inside the libraries to "internal" paths, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br /><br />
<br />
''Note:'' To see errors directly you need to start Hugin.app from the command line, e.g. from a terminal. Issue the command <pre>$ open Hugin.app &</pre> to do that (in case you didn't know). If you double-click Hugin.app from Finder you won't see (error) messages.<br />Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). <br />
<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC_64 (theoretically) and X86_64. If you want to do this you need to use SetEnv-leopard.txt. At this moment this is "''extremely and utterly experimental''" as:<br />
:# most "Linux derived" libraries and binaries will not compile for Apple 64bit.<br />
:# If they compile and build, they are not well optimized. <br />
:# only enblend can use the full potential of 64bit (currently).<br />
:# You build the 64bit part only for Leopard users on 64bit hardware. 32bit universal will run on ''every'' Mac.<br />
:# The current bundle is 85 MB. If you build for three architectures (ppc/i386/x86_64) it will be approx 120 MB.<br />
Use at your own risk. But for the time being: stay away from it.<br />
<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10628Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T15:55:19Z<p>Ippei: moved outside approach instruction</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working.<br />
<br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and to create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory. Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you have downloaded with SVN.<br />
<br />
The recommended for "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><br />
<tt>$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"</tt><br /><br />
<tt>$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"</tt><br /><br />
<tt>$ mkdir -p "$myExternalProgramsDir"</tt><br /><br />
<tt>$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"</tt><br /><br />
<tt>$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"</tt><br /><br />
<tt>$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"</tt><br /><br />
</blockquote><br />
<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. These variables are all set by calling a text file. This text file is "<tt>SetEnv-universal.txt</tt>". You can find this file inside <tt>hugin/mac/ExternalPrograms/scripts</tt>.<br />
In the top of this file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use (This example show the (current) default one from the SVN). So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/Spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br /><br />
You do not need to modify anything below this line.<br />
<br />
The "<tt>SetEnv-universal.txt</tt>" has a line containing ARCHS="ppc i386" and the <tt>SetEnv-leopard.txt</tt> has a line containing ARCHS="ppc i386 ppc64 x86_64". Even if you are on Leopard, please use the <tt>SetEnv-universal.txt</tt> and stay away from 64bit builds for the time being. Read [[#32bit versus 64bit]] for more info.<br />
<br />
=='''Building the "External Programs"'''==<br />
===Building Subversion (SVN)===<br />
''(Note: Tiger and earlier only)''<br />Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to build it yourself.<br /><br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Get MacPorts and/or Fink out of the way===<br />
Now we really need to get MacPorts and/or Fink out of the way. We want to make a completely separate development tree. This means that we do not want to link to any library or binary outside our "External Programs" development tree (unless they are true Mac system libraries that are part of your MacOSX version). If we accidentally ''do'' link to non-system libraries outside our tree we will have problems when we build the bundle and certainly when we want to distribute it. So to get them out of the way, we do the following:<br />
<blockquote><pre>$ sudo mv /opt /opt.org<br />
$ sudo mv /sw /sw.org<br />
$ sudo mv /usr/local /usr/local.org</pre></blockquote><br />
Note: The <tt>usr/local</tt> is in case you have built libraries or binaries without MacPorts or Fink.<br /><br />
'''Note 2: Do not use "<tt>sudo mv /usr /usr.org</tt>" as <tt>/usr</tt> is vital for proper system functioning!!!''' If you accidentally do this, you need to reboot using your Mac DVD, go into the terminal and move it back.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre>$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24</pre></blockquote><br />
<br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv-universal.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names): <br />
libjpeg.sh, libtiff.sh, libpng.sh, expat.sh, lcms.sh, ilmbase.sh, openexr16.sh, boost.sh, wxmac28.sh, pano13.sh, libexiv2.sh<br />
<br />
And for the binaries:<br />
gnumake.sh, autopano-sift-C.sh, enblend31.sh, panomatic.sh<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use XCode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br /><br /><br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
You need to check, and if necessary change, the values for:<br />
* Library Search Paths<br />
* REPOSITORY_DIR<br />
* WX_INCLUDE_DIR<br />
* WX_INCLUDE_DIR_LIB<br />
* WX_MAJOR_VERSOIN (note that it says VERSOIN in stead of VERSION. Leave it like that!)<br />
All path's are relative to the location of the hugin.xcodeproj directory structure. If you did build the libraries that Hugin depends on according the steps described above, you do not need to change anything. But do check!<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Prepare the scripts before building===<br />
<table border="0" width="600"><TR><TD>[[Image:Xcode script preparation.png | left | frame | 271px | Some of the necessary scripts]]</TD><TD valign="TOP"> The project uses a couple of shell scripts to get everything into the bundle. In an Xcode project you can define steps for this in your Targets. These steps then consist of these scripts.<br />
Note though that if these scripts are not correct, Xcode will generate a non-fatal error. However, this non-fatal error for Xcode will quite often be a fatal error for your final bundle as it will miss "something" and it will simply not run or not run correctly.<br />
Yoy can take a look at the target Hugin: Open Targets -> Hugin and double-click (for example) the entry "Complete bundle". This will show you how to embed scripts.<br />
Note however, that you do not edit the scripts from the Target(s) position. You edit the script inside the files section (see [[#XCode basic walk-through]]). In this project everything is already at it's correct position. </TD></TR></TABLE><br />
<br />
<br />
<br />
====Edit localised.sh====<br />
Move (back) in the navigation pane to the top of your project and open the top section (the "file" section), open the <tt>mac</tt> "directory" and locate <tt>localised.sh</tt>. Double-click <tt>localised.sh</tt> to open it.<br />
In the top of the script you will find the following lines:<br />
<pre>huginVer="$HUGIN_PACKAGE_VERSION"<br />
wxDir="./ExternalPrograms/wxMac-2.8.7"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
huginsrcdir="../src/hugin1/hugin"<br />
xrcsrcdir="$huginsrcdir/xrc"<br />
translationsdir="../src/translations"<br />
</pre><br />
Change the <tt>wxDir</tt> to the directory where your wxmac '''source code''' resides.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit Complete-bundle.sh====<br />
Locate the <tt>Complete-bundle.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>dylib_dir="../mac/ExternalPrograms/repository/lib"<br />
old_install_name_dirname="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib"<br />
dylib_install_loc="Libraries"<br />
new_install_name_dirname="@executable_path/../$dylib_install_loc"<br />
</pre><br />
Change the <tt>dylib_dir</tt> to the correct relative path.<br /><br />
Change the <tt>old_install_name_dirname</tt> to the correct '''absolute''' path.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit copyExifTool.sh====<br />
If you have Exiftool on your system, you need to edit this script too. As mentioned in the early lines of [[#Prepare the scripts before building]] Xcode will generate a non-fatal error if Exiftool is not available (or if you configured the script incorrectly), but in this case Hugin will run without it as it is an "extra" tool and Hugin can run without it.<br /><br />
Locate the <tt>copyExifTool.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>exiftoolDir="./ExternalPrograms/Image-ExifTool-7.25"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
</pre><br />
Change the <tt>exiftoolDir</tt> path to the path where your Exiftool resides.<br /><br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
===Compile and build our Hugin.app===<br />
====Final check====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less. In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br />
<br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "all" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Double-click it and try to make a panorama. If this works, it's party time!!! So, go party and when you're finished come back for the next test.<br /><br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. As this is not always possible, copy your Hugin.app to another location on your mac and rename<br /><br />
* your mac directory inside your hugin source directory to mac.org,<br />
* your /opt/local to /opt/local.org (in case you have Macports),<br />
* your /sw directory to /sw.org (in case you have Fink),<br />
* your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br /> The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the "hard linked" paths inside Hugin and inside the libraries to "internal" paths, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br /><br />
<br />
''Note:'' To see errors directly you need to start Hugin.app from the command line, e.g. from a terminal. Issue the command <pre>$ open Hugin.app &</pre> to do that (in case you didn't know). If you double-click Hugin.app from Finder you won't see (error) messages.<br />Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). <br />
<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC_64 (theoretically) and X86_64. If you want to do this you need to use SetEnv-leopard.txt. At this moment this is "''extremely and utterly experimental''" as:<br />
:# most "Linux derived" libraries and binaries will not compile for Apple 64bit.<br />
:# If they compile and build, they are not well optimized. <br />
:# only enblend can use the full potential of 64bit (currently).<br />
:# You build the 64bit part only for Leopard users on 64bit hardware. 32bit universal will run on ''every'' Mac.<br />
:# The current bundle is 85 MB. If you build for three architectures (ppc/i386/x86_64) it will be approx 120 MB.<br />
Use at your own risk. But for the time being: stay away from it.<br />
<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10627Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T15:47:03Z<p>Ippei: /* Location of the "External Programs" development tree */</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Location of the "External Programs" development tree===<br />
This part describes where we want to place the development tree for our "External Programs" that hugin depends on. Although the "External Programs" directory structure is placed inside the Hugin SVN tree by default, this does not necessarily need to be in the same place as the Hugin source itself. The easiest way to place those files in custom places is to put symbolic link in the default place.<br />
<br />
The first question is: where do you ''want'' to have your development tree? As you (might) know, the "normal" location is <tt>/usr/local</tt>, and MacPorts uses <tt>/opt/local</tt> by default and Fink, <tt>/sw</tt>. '''We do not want to use these locations'''! <br />
<br />
Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br />
<br />
So, from this moment "we" have decided to build our development tree in user space.<br />
<br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as root user. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
<br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is not meant for compiling cross-platform tools, but for hosting platform specific tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>. <br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote><br />
'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br />
''Cons:''<br />
* Many of the default paths assume the "inside" approach; you will have to map some of the directories with symbolic link.<br />
</blockquote><br />
<br />
Currently some part of hugin's Xcode project assumes the "binary repository" (explained below) is located at <tt>mac/ExternalPrograms/repository</tt>, inside the same directory as the source code you downloaded with SVN. The recommended "outside" approach is to:<br />
# make your "External Programs" directory<br />
# place symbolic link to the "binary repository" directory in your "External Programs" directory at <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/repository</tt><br />
# optionally place symbolic link to <tt>/&lt;path_to_hugin_source&gt;/mac/ExternalPrograms/scripts</tt> in your "External Programs" directory<br />
e.g.<br />
<blockquote><br />
<tt>$ myPathToHuginSource="/Users/&lt;your_username&gt;/development/hugin/hugin-svn"</tt><br /><br />
<tt>$ myExternalProgramsDir="/Users/&lt;your_username&gt;/development/hugin/ExternalPrograms"</tt><br /><br />
<tt>$ mkdir -p "$myExternalProgramsDir"</tt><br /><br />
<tt>$ mkdir -p "$myExternalProgramsDir/Repository-dynamic"</tt><br /><br />
<tt>$ ln -s "$myExternalProgramsDir/Repository-dynamic" "$myPathToHuginSource/mac/ExternalPrograms/repository"</tt><br /><br />
<tt>$ ln -s "$myPathToHuginSource/mac/ExternalPrograms/scripts" "$myExternalProgramsDir/scripts"</tt><br /><br />
</blockquote><br />
<br />
===Creation of the "External Programs" development tree===<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working. <br /><br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and to create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory.<br /><br />
As mentioned: This HowTo focuses on keeping it in the Hugin svn tree. You need to change the paths as mentioned in the rest of this HowTo, according to your choices.<br />
<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. These variables are all set by calling a text file. This text file is "<tt>SetEnv-universal.txt</tt>". You can find this file inside <tt>hugin/mac/ExternalPrograms/scripts</tt>.<br />
In the top of this file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use (This example show the (current) default one from the SVN). So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/Spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br /><br />
You do not need to modify anything below this line.<br />
<br />
The "<tt>SetEnv-universal.txt</tt>" has a line containing ARCHS="ppc i386" and the <tt>SetEnv-leopard.txt</tt> has a line containing ARCHS="ppc i386 ppc64 x86_64". Even if you are on Leopard, please use the <tt>SetEnv-universal.txt</tt> and stay away from 64bit builds for the time being. Read [[#32bit versus 64bit]] for more info.<br />
<br />
=='''Building the "External Programs"'''==<br />
===Building Subversion (SVN)===<br />
''(Note: Tiger and earlier only)''<br />Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to build it yourself.<br /><br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Get MacPorts and/or Fink out of the way===<br />
Now we really need to get MacPorts and/or Fink out of the way. We want to make a completely separate development tree. This means that we do not want to link to any library or binary outside our "External Programs" development tree (unless they are true Mac system libraries that are part of your MacOSX version). If we accidentally ''do'' link to non-system libraries outside our tree we will have problems when we build the bundle and certainly when we want to distribute it. So to get them out of the way, we do the following:<br />
<blockquote><pre>$ sudo mv /opt /opt.org<br />
$ sudo mv /sw /sw.org<br />
$ sudo mv /usr/local /usr/local.org</pre></blockquote><br />
Note: The <tt>usr/local</tt> is in case you have built libraries or binaries without MacPorts or Fink.<br /><br />
'''Note 2: Do not use "<tt>sudo mv /usr /usr.org</tt>" as <tt>/usr</tt> is vital for proper system functioning!!!''' If you accidentally do this, you need to reboot using your Mac DVD, go into the terminal and move it back.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre>$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24</pre></blockquote><br />
<br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv-universal.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names): <br />
libjpeg.sh, libtiff.sh, libpng.sh, expat.sh, lcms.sh, ilmbase.sh, openexr16.sh, boost.sh, wxmac28.sh, pano13.sh, libexiv2.sh<br />
<br />
And for the binaries:<br />
gnumake.sh, autopano-sift-C.sh, enblend31.sh, panomatic.sh<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use XCode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br /><br /><br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
You need to check, and if necessary change, the values for:<br />
* Library Search Paths<br />
* REPOSITORY_DIR<br />
* WX_INCLUDE_DIR<br />
* WX_INCLUDE_DIR_LIB<br />
* WX_MAJOR_VERSOIN (note that it says VERSOIN in stead of VERSION. Leave it like that!)<br />
All path's are relative to the location of the hugin.xcodeproj directory structure. If you did build the libraries that Hugin depends on according the steps described above, you do not need to change anything. But do check!<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Prepare the scripts before building===<br />
<table border="0" width="600"><TR><TD>[[Image:Xcode script preparation.png | left | frame | 271px | Some of the necessary scripts]]</TD><TD valign="TOP"> The project uses a couple of shell scripts to get everything into the bundle. In an Xcode project you can define steps for this in your Targets. These steps then consist of these scripts.<br />
Note though that if these scripts are not correct, Xcode will generate a non-fatal error. However, this non-fatal error for Xcode will quite often be a fatal error for your final bundle as it will miss "something" and it will simply not run or not run correctly.<br />
Yoy can take a look at the target Hugin: Open Targets -> Hugin and double-click (for example) the entry "Complete bundle". This will show you how to embed scripts.<br />
Note however, that you do not edit the scripts from the Target(s) position. You edit the script inside the files section (see [[#XCode basic walk-through]]). In this project everything is already at it's correct position. </TD></TR></TABLE><br />
<br />
<br />
<br />
====Edit localised.sh====<br />
Move (back) in the navigation pane to the top of your project and open the top section (the "file" section), open the <tt>mac</tt> "directory" and locate <tt>localised.sh</tt>. Double-click <tt>localised.sh</tt> to open it.<br />
In the top of the script you will find the following lines:<br />
<pre>huginVer="$HUGIN_PACKAGE_VERSION"<br />
wxDir="./ExternalPrograms/wxMac-2.8.7"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
huginsrcdir="../src/hugin1/hugin"<br />
xrcsrcdir="$huginsrcdir/xrc"<br />
translationsdir="../src/translations"<br />
</pre><br />
Change the <tt>wxDir</tt> to the directory where your wxmac '''source code''' resides.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit Complete-bundle.sh====<br />
Locate the <tt>Complete-bundle.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>dylib_dir="../mac/ExternalPrograms/repository/lib"<br />
old_install_name_dirname="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib"<br />
dylib_install_loc="Libraries"<br />
new_install_name_dirname="@executable_path/../$dylib_install_loc"<br />
</pre><br />
Change the <tt>dylib_dir</tt> to the correct relative path.<br /><br />
Change the <tt>old_install_name_dirname</tt> to the correct '''absolute''' path.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit copyExifTool.sh====<br />
If you have Exiftool on your system, you need to edit this script too. As mentioned in the early lines of [[#Prepare the scripts before building]] Xcode will generate a non-fatal error if Exiftool is not available (or if you configured the script incorrectly), but in this case Hugin will run without it as it is an "extra" tool and Hugin can run without it.<br /><br />
Locate the <tt>copyExifTool.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>exiftoolDir="./ExternalPrograms/Image-ExifTool-7.25"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
</pre><br />
Change the <tt>exiftoolDir</tt> path to the path where your Exiftool resides.<br /><br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
===Compile and build our Hugin.app===<br />
====Final check====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less. In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br />
<br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "all" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Double-click it and try to make a panorama. If this works, it's party time!!! So, go party and when you're finished come back for the next test.<br /><br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. As this is not always possible, copy your Hugin.app to another location on your mac and rename<br /><br />
* your mac directory inside your hugin source directory to mac.org,<br />
* your /opt/local to /opt/local.org (in case you have Macports),<br />
* your /sw directory to /sw.org (in case you have Fink),<br />
* your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br /> The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the "hard linked" paths inside Hugin and inside the libraries to "internal" paths, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br /><br />
<br />
''Note:'' To see errors directly you need to start Hugin.app from the command line, e.g. from a terminal. Issue the command <pre>$ open Hugin.app &</pre> to do that (in case you didn't know). If you double-click Hugin.app from Finder you won't see (error) messages.<br />Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). <br />
<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC_64 (theoretically) and X86_64. If you want to do this you need to use SetEnv-leopard.txt. At this moment this is "''extremely and utterly experimental''" as:<br />
:# most "Linux derived" libraries and binaries will not compile for Apple 64bit.<br />
:# If they compile and build, they are not well optimized. <br />
:# only enblend can use the full potential of 64bit (currently).<br />
:# You build the 64bit part only for Leopard users on 64bit hardware. 32bit universal will run on ''every'' Mac.<br />
:# The current bundle is 85 MB. If you build for three architectures (ppc/i386/x86_64) it will be approx 120 MB.<br />
Use at your own risk. But for the time being: stay away from it.<br />
<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10626Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T14:53:20Z<p>Ippei: /* Subversion (SVN) */</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Location of the "External Programs" development tree===<br />
To start with: This part describes where we want to place the development tree for our "External Programs" where hugin depends on. This does not necessarily need to be in the same place as the Hugin source itself although the "External Programs" directory structure is by default placed inside the Hugin SVN tree when you download Hugin.<br /><br />
The first question is: Where do you ''want'' to have your development tree? As you (might) know, the "normal" locations are <tt>/opt/local</tt> for MacPorts, <tt>/sw</tt> for Fink and finally <tt>/usr/local</tt> for all builds following "Linux" rules. '''We do not want to use these locations'''! Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. <br />
When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br /><br />
So, from this moment "we" have decided to build our development tree in user space.<br /><br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as sudo. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is meant for user added tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>.<br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote>'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br /><br />
''Cons:''<br />
* If updates in SVN are applied to the "External Programs" build scripts, you need to track that and manually copy these to your separate build tree.</blockquote><br />
(Currently I have my "External Programs" build tree inside hugin as I started it this way. I once needed to delete my hugin SVN tree and I first moved my <tt>mac</tt> directory (including <tt>ExternalPrograms</tt>) out of the way, deleted the hugin svn tree, downloaded the new hugin svn tree, moved the <tt>mac</tt> directory back inside and svn synced hugin again to get possible changes in the mac or scripts directory. You just have to remember that you need to do that.)<br />
<br />
===Creation of the "External Programs" development tree===<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working. <br /><br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and to create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory.<br /><br />
As mentioned: This HowTo focuses on keeping it in the Hugin svn tree. You need to change the paths as mentioned in the rest of this HowTo, according to your choices.<br />
<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. These variables are all set by calling a text file. This text file is "<tt>SetEnv-universal.txt</tt>". You can find this file inside <tt>hugin/mac/ExternalPrograms/scripts</tt>.<br />
In the top of this file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use (This example show the (current) default one from the SVN). So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/Spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br /><br />
You do not need to modify anything below this line.<br />
<br />
The "<tt>SetEnv-universal.txt</tt>" has a line containing ARCHS="ppc i386" and the <tt>SetEnv-leopard.txt</tt> has a line containing ARCHS="ppc i386 ppc64 x86_64". Even if you are on Leopard, please use the <tt>SetEnv-universal.txt</tt> and stay away from 64bit builds for the time being. Read [[#32bit versus 64bit]] for more info.<br />
<br />
=='''Building the "External Programs"'''==<br />
===Building Subversion (SVN)===<br />
''(Note: Tiger and earlier only)''<br />Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to build it yourself.<br /><br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Get MacPorts and/or Fink out of the way===<br />
Now we really need to get MacPorts and/or Fink out of the way. We want to make a completely separate development tree. This means that we do not want to link to any library or binary outside our "External Programs" development tree (unless they are true Mac system libraries that are part of your MacOSX version). If we accidentally ''do'' link to non-system libraries outside our tree we will have problems when we build the bundle and certainly when we want to distribute it. So to get them out of the way, we do the following:<br />
<blockquote><pre>$ sudo mv /opt /opt.org<br />
$ sudo mv /sw /sw.org<br />
$ sudo mv /usr/local /usr/local.org</pre></blockquote><br />
Note: The <tt>usr/local</tt> is in case you have built libraries or binaries without MacPorts or Fink.<br /><br />
'''Note 2: Do not use "<tt>sudo mv /usr /usr.org</tt>" as <tt>/usr</tt> is vital for proper system functioning!!!''' If you accidentally do this, you need to reboot using your Mac DVD, go into the terminal and move it back.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre>$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24</pre></blockquote><br />
<br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv-universal.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names): <br />
libjpeg.sh, libtiff.sh, libpng.sh, expat.sh, lcms.sh, ilmbase.sh, openexr16.sh, boost.sh, wxmac28.sh, pano13.sh, libexiv2.sh<br />
<br />
And for the binaries:<br />
gnumake.sh, autopano-sift-C.sh, enblend31.sh, panomatic.sh<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use XCode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br /><br /><br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
You need to check, and if necessary change, the values for:<br />
* Library Search Paths<br />
* REPOSITORY_DIR<br />
* WX_INCLUDE_DIR<br />
* WX_INCLUDE_DIR_LIB<br />
* WX_MAJOR_VERSOIN (note that it says VERSOIN in stead of VERSION. Leave it like that!)<br />
All path's are relative to the location of the hugin.xcodeproj directory structure. If you did build the libraries that Hugin depends on according the steps described above, you do not need to change anything. But do check!<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Prepare the scripts before building===<br />
<table border="0" width="600"><TR><TD>[[Image:Xcode script preparation.png | left | frame | 271px | Some of the necessary scripts]]</TD><TD valign="TOP"> The project uses a couple of shell scripts to get everything into the bundle. In an Xcode project you can define steps for this in your Targets. These steps then consist of these scripts.<br />
Note though that if these scripts are not correct, Xcode will generate a non-fatal error. However, this non-fatal error for Xcode will quite often be a fatal error for your final bundle as it will miss "something" and it will simply not run or not run correctly.<br />
Yoy can take a look at the target Hugin: Open Targets -> Hugin and double-click (for example) the entry "Complete bundle". This will show you how to embed scripts.<br />
Note however, that you do not edit the scripts from the Target(s) position. You edit the script inside the files section (see [[#XCode basic walk-through]]). In this project everything is already at it's correct position. </TD></TR></TABLE><br />
<br />
<br />
<br />
====Edit localised.sh====<br />
Move (back) in the navigation pane to the top of your project and open the top section (the "file" section), open the <tt>mac</tt> "directory" and locate <tt>localised.sh</tt>. Double-click <tt>localised.sh</tt> to open it.<br />
In the top of the script you will find the following lines:<br />
<pre>huginVer="$HUGIN_PACKAGE_VERSION"<br />
wxDir="./ExternalPrograms/wxMac-2.8.7"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
huginsrcdir="../src/hugin1/hugin"<br />
xrcsrcdir="$huginsrcdir/xrc"<br />
translationsdir="../src/translations"<br />
</pre><br />
Change the <tt>wxDir</tt> to the directory where your wxmac '''source code''' resides.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit Complete-bundle.sh====<br />
Locate the <tt>Complete-bundle.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>dylib_dir="../mac/ExternalPrograms/repository/lib"<br />
old_install_name_dirname="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib"<br />
dylib_install_loc="Libraries"<br />
new_install_name_dirname="@executable_path/../$dylib_install_loc"<br />
</pre><br />
Change the <tt>dylib_dir</tt> to the correct relative path.<br /><br />
Change the <tt>old_install_name_dirname</tt> to the correct '''absolute''' path.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit copyExifTool.sh====<br />
If you have Exiftool on your system, you need to edit this script too. As mentioned in the early lines of [[#Prepare the scripts before building]] Xcode will generate a non-fatal error if Exiftool is not available (or if you configured the script incorrectly), but in this case Hugin will run without it as it is an "extra" tool and Hugin can run without it.<br /><br />
Locate the <tt>copyExifTool.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>exiftoolDir="./ExternalPrograms/Image-ExifTool-7.25"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
</pre><br />
Change the <tt>exiftoolDir</tt> path to the path where your Exiftool resides.<br /><br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
===Compile and build our Hugin.app===<br />
====Final check====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less. In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br />
<br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "all" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Double-click it and try to make a panorama. If this works, it's party time!!! So, go party and when you're finished come back for the next test.<br /><br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. As this is not always possible, copy your Hugin.app to another location on your mac and rename<br /><br />
* your mac directory inside your hugin source directory to mac.org,<br />
* your /opt/local to /opt/local.org (in case you have Macports),<br />
* your /sw directory to /sw.org (in case you have Fink),<br />
* your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br /> The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the "hard linked" paths inside Hugin and inside the libraries to "internal" paths, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br /><br />
<br />
''Note:'' To see errors directly you need to start Hugin.app from the command line, e.g. from a terminal. Issue the command <pre>$ open Hugin.app &</pre> to do that (in case you didn't know). If you double-click Hugin.app from Finder you won't see (error) messages.<br />Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). <br />
<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC_64 (theoretically) and X86_64. If you want to do this you need to use SetEnv-leopard.txt. At this moment this is "''extremely and utterly experimental''" as:<br />
:# most "Linux derived" libraries and binaries will not compile for Apple 64bit.<br />
:# If they compile and build, they are not well optimized. <br />
:# only enblend can use the full potential of 64bit (currently).<br />
:# You build the 64bit part only for Leopard users on 64bit hardware. 32bit universal will run on ''every'' Mac.<br />
:# The current bundle is 85 MB. If you build for three architectures (ppc/i386/x86_64) it will be approx 120 MB.<br />
Use at your own risk. But for the time being: stay away from it.<br />
<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10625Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T14:52:20Z<p>Ippei: /* '''Prerequisites''' */ (side note: gcc 3.3 is not used at all)</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
You should have Mac OS X 10.4 or above. Older systems are not recommended and how to build on those systems will not be included in this document.<br />
<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the latest version of XCode Tools for your Mac OS X: Xcode 2.4.x for Mac OS X 10.4 (Tiger) and Xcode 3.x for 10.5 (Leopard). For Mac OS X 10.3.9 compatibility, we currently use 10.3.9 SDK which you can either turn on with custom install, or install separately from MaxOSX10.3.9.pkg in the "Packages" folder.<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger, you need to install it yourself. The simplest way to get SVN is to use MacPorts or Fink.<br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
You may also find [http://scplugin.tigris.org/ SCPlugin] handy for some quick operations.<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Location of the "External Programs" development tree===<br />
To start with: This part describes where we want to place the development tree for our "External Programs" where hugin depends on. This does not necessarily need to be in the same place as the Hugin source itself although the "External Programs" directory structure is by default placed inside the Hugin SVN tree when you download Hugin.<br /><br />
The first question is: Where do you ''want'' to have your development tree? As you (might) know, the "normal" locations are <tt>/opt/local</tt> for MacPorts, <tt>/sw</tt> for Fink and finally <tt>/usr/local</tt> for all builds following "Linux" rules. '''We do not want to use these locations'''! Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. <br />
When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br /><br />
So, from this moment "we" have decided to build our development tree in user space.<br /><br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as sudo. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is meant for user added tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>.<br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote>'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br /><br />
''Cons:''<br />
* If updates in SVN are applied to the "External Programs" build scripts, you need to track that and manually copy these to your separate build tree.</blockquote><br />
(Currently I have my "External Programs" build tree inside hugin as I started it this way. I once needed to delete my hugin SVN tree and I first moved my <tt>mac</tt> directory (including <tt>ExternalPrograms</tt>) out of the way, deleted the hugin svn tree, downloaded the new hugin svn tree, moved the <tt>mac</tt> directory back inside and svn synced hugin again to get possible changes in the mac or scripts directory. You just have to remember that you need to do that.)<br />
<br />
===Creation of the "External Programs" development tree===<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working. <br /><br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and to create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory.<br /><br />
As mentioned: This HowTo focuses on keeping it in the Hugin svn tree. You need to change the paths as mentioned in the rest of this HowTo, according to your choices.<br />
<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. These variables are all set by calling a text file. This text file is "<tt>SetEnv-universal.txt</tt>". You can find this file inside <tt>hugin/mac/ExternalPrograms/scripts</tt>.<br />
In the top of this file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use (This example show the (current) default one from the SVN). So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/Spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br /><br />
You do not need to modify anything below this line.<br />
<br />
The "<tt>SetEnv-universal.txt</tt>" has a line containing ARCHS="ppc i386" and the <tt>SetEnv-leopard.txt</tt> has a line containing ARCHS="ppc i386 ppc64 x86_64". Even if you are on Leopard, please use the <tt>SetEnv-universal.txt</tt> and stay away from 64bit builds for the time being. Read [[#32bit versus 64bit]] for more info.<br />
<br />
=='''Building the "External Programs"'''==<br />
===Building Subversion (SVN)===<br />
''(Note: Tiger and earlier only)''<br />Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to build it yourself.<br /><br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Get MacPorts and/or Fink out of the way===<br />
Now we really need to get MacPorts and/or Fink out of the way. We want to make a completely separate development tree. This means that we do not want to link to any library or binary outside our "External Programs" development tree (unless they are true Mac system libraries that are part of your MacOSX version). If we accidentally ''do'' link to non-system libraries outside our tree we will have problems when we build the bundle and certainly when we want to distribute it. So to get them out of the way, we do the following:<br />
<blockquote><pre>$ sudo mv /opt /opt.org<br />
$ sudo mv /sw /sw.org<br />
$ sudo mv /usr/local /usr/local.org</pre></blockquote><br />
Note: The <tt>usr/local</tt> is in case you have built libraries or binaries without MacPorts or Fink.<br /><br />
'''Note 2: Do not use "<tt>sudo mv /usr /usr.org</tt>" as <tt>/usr</tt> is vital for proper system functioning!!!''' If you accidentally do this, you need to reboot using your Mac DVD, go into the terminal and move it back.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre>$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24</pre></blockquote><br />
<br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv-universal.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names): <br />
libjpeg.sh, libtiff.sh, libpng.sh, expat.sh, lcms.sh, ilmbase.sh, openexr16.sh, boost.sh, wxmac28.sh, pano13.sh, libexiv2.sh<br />
<br />
And for the binaries:<br />
gnumake.sh, autopano-sift-C.sh, enblend31.sh, panomatic.sh<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use XCode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br /><br /><br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
You need to check, and if necessary change, the values for:<br />
* Library Search Paths<br />
* REPOSITORY_DIR<br />
* WX_INCLUDE_DIR<br />
* WX_INCLUDE_DIR_LIB<br />
* WX_MAJOR_VERSOIN (note that it says VERSOIN in stead of VERSION. Leave it like that!)<br />
All path's are relative to the location of the hugin.xcodeproj directory structure. If you did build the libraries that Hugin depends on according the steps described above, you do not need to change anything. But do check!<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Prepare the scripts before building===<br />
<table border="0" width="600"><TR><TD>[[Image:Xcode script preparation.png | left | frame | 271px | Some of the necessary scripts]]</TD><TD valign="TOP"> The project uses a couple of shell scripts to get everything into the bundle. In an Xcode project you can define steps for this in your Targets. These steps then consist of these scripts.<br />
Note though that if these scripts are not correct, Xcode will generate a non-fatal error. However, this non-fatal error for Xcode will quite often be a fatal error for your final bundle as it will miss "something" and it will simply not run or not run correctly.<br />
Yoy can take a look at the target Hugin: Open Targets -> Hugin and double-click (for example) the entry "Complete bundle". This will show you how to embed scripts.<br />
Note however, that you do not edit the scripts from the Target(s) position. You edit the script inside the files section (see [[#XCode basic walk-through]]). In this project everything is already at it's correct position. </TD></TR></TABLE><br />
<br />
<br />
<br />
====Edit localised.sh====<br />
Move (back) in the navigation pane to the top of your project and open the top section (the "file" section), open the <tt>mac</tt> "directory" and locate <tt>localised.sh</tt>. Double-click <tt>localised.sh</tt> to open it.<br />
In the top of the script you will find the following lines:<br />
<pre>huginVer="$HUGIN_PACKAGE_VERSION"<br />
wxDir="./ExternalPrograms/wxMac-2.8.7"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
huginsrcdir="../src/hugin1/hugin"<br />
xrcsrcdir="$huginsrcdir/xrc"<br />
translationsdir="../src/translations"<br />
</pre><br />
Change the <tt>wxDir</tt> to the directory where your wxmac '''source code''' resides.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit Complete-bundle.sh====<br />
Locate the <tt>Complete-bundle.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>dylib_dir="../mac/ExternalPrograms/repository/lib"<br />
old_install_name_dirname="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib"<br />
dylib_install_loc="Libraries"<br />
new_install_name_dirname="@executable_path/../$dylib_install_loc"<br />
</pre><br />
Change the <tt>dylib_dir</tt> to the correct relative path.<br /><br />
Change the <tt>old_install_name_dirname</tt> to the correct '''absolute''' path.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit copyExifTool.sh====<br />
If you have Exiftool on your system, you need to edit this script too. As mentioned in the early lines of [[#Prepare the scripts before building]] Xcode will generate a non-fatal error if Exiftool is not available (or if you configured the script incorrectly), but in this case Hugin will run without it as it is an "extra" tool and Hugin can run without it.<br /><br />
Locate the <tt>copyExifTool.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>exiftoolDir="./ExternalPrograms/Image-ExifTool-7.25"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
</pre><br />
Change the <tt>exiftoolDir</tt> path to the path where your Exiftool resides.<br /><br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
===Compile and build our Hugin.app===<br />
====Final check====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less. In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br />
<br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "all" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Double-click it and try to make a panorama. If this works, it's party time!!! So, go party and when you're finished come back for the next test.<br /><br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. As this is not always possible, copy your Hugin.app to another location on your mac and rename<br /><br />
* your mac directory inside your hugin source directory to mac.org,<br />
* your /opt/local to /opt/local.org (in case you have Macports),<br />
* your /sw directory to /sw.org (in case you have Fink),<br />
* your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br /> The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the "hard linked" paths inside Hugin and inside the libraries to "internal" paths, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br /><br />
<br />
''Note:'' To see errors directly you need to start Hugin.app from the command line, e.g. from a terminal. Issue the command <pre>$ open Hugin.app &</pre> to do that (in case you didn't know). If you double-click Hugin.app from Finder you won't see (error) messages.<br />Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). <br />
<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC_64 (theoretically) and X86_64. If you want to do this you need to use SetEnv-leopard.txt. At this moment this is "''extremely and utterly experimental''" as:<br />
:# most "Linux derived" libraries and binaries will not compile for Apple 64bit.<br />
:# If they compile and build, they are not well optimized. <br />
:# only enblend can use the full potential of 64bit (currently).<br />
:# You build the 64bit part only for Leopard users on 64bit hardware. 32bit universal will run on ''every'' Mac.<br />
:# The current bundle is 85 MB. If you build for three architectures (ppc/i386/x86_64) it will be approx 120 MB.<br />
Use at your own risk. But for the time being: stay away from it.<br />
<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Build_a_MacOSX_Universal_Hugin_bundle_with_Xcode&diff=10624Build a MacOSX Universal Hugin bundle with Xcode2008-07-05T14:33:21Z<p>Ippei: /* '''Introduction''' */</p>
<hr />
<div>'''''THIS IS STILL A DRAFT VERSION'''''<br />
<br />
=='''Introduction'''==<br />
<br />
The "normal" way of compiling Hugin is via Cmake. With the current versions of MacPorts, Fink and Cmake it is very difficult to make a universal bundle due to the way [[#Additional documentation| endianness]] is dealt with in MacPorts and Fink. This HowTo explains how to make a universal bundle with Xcode.<br />
<br />
The creation of a bundle is actually a two step process:<br />
# '''Build all libraries and binaries which Hugin depends on.''' This is done outside Xcode. From here on we will call these libraries and binaries "External Programs". To compile and build all "External Programs" as universal, we will follow a different process compared to the normal "straight-forward" process of building libraries with MacPorts or Finks as described in [http://wiki.panotools.org/Hugin_Compiling_OSX Hugin Compiling OSX]. We do not need nor use MacPorts and/or Fink. Some may even prefer to put them "out of the way" in order to make sure we will not link with the libraries they provide. However, they provide convenient ways to install a few of the tools that we require in the later process.<br />
# '''Build Hugin and it's "internal" tools in Xcode and create the bundle.''' As the title suggests: This is done in Xcode.<br />
<br />
''Note:'' This Howto does not explain how to build a Hugin the "cmake way". Follow the Howto [[Hugin_Compiling_OSX | Hugin Compiling OSX]].<br />
<br />
=='''Prerequisites'''==<br />
===Download and install XCode===<br />
[http://developer.apple.com/tools/download/ Download] and install the XCode Tools version for your MacOSX version: Xcode 2.4.x for MacOSX 10.4.x or below and Xcode 3.x for 10.5.x (Leopard). For those who are brave enough to ponder into the dark corners of the installed base: You will find a 4.x version and a 3.3 version of the GNU compiler and it's "companions". Do not remove either of them. The 4.x version is used for i386/X_64 builds and the 3.3 version is used for the "older" PPC builds. You need both to be able to build a [http://en.wikipedia.org/wiki/Universal_binary Universal binary] (No matter whether you use XCode only or Xcode as basis for MacPorts or Fink).<br /><br />
After the installation of XcodeTools.mpkg has finished, check the additional "Packages" folder and make sure to also install the gcc3.3.pkg and the MaxOSX10.3.9.pkg.<br />
<br />
===Install CMake===<br />
Get and install the build system CMake, version 2.4.7 or later, from [http://www.cmake.org/HTML/Download.html CMake].<br />
<br />
===Subversion (SVN)===<br />
Leopard comes with SVN installed. If you are on Tiger or below you need to build it yourself. The simplest way to get SVN is to use your MacPorts or Fink version. (Yes, I know. I said that you did not need MacPorts or Fink. I'll come back on it later).<br /><br />
If you fancy a nice GUI you can download the Open-Source [http://www.lachoseinteractive.net/en/community/subversion/svnx/features/?sid=b42441f308810ad0d36b779f90319391 SVNX]. You still need svn installed as it is only a graphical shell and I won't explain SVNX here (I only used it once, I still prefer the terminal).<br />
<br />
=='''Preparations for building the "External Programs"'''==<br />
===Introduction===<br />
Building the necessary "External Programs" (the libraries and binaries Hugin depends on) is completely scripted. This part describes not how to use "<tt>./configure</tt>" or "<tt>make; make install</tt>". It will explain (advise) how and where to create the necessary directory structure, configure the base environment script and, more or less, tell you in which order to run the package build scripts.<br />
<br />
===Location of the "External Programs" development tree===<br />
To start with: This part describes where we want to place the development tree for our "External Programs" where hugin depends on. This does not necessarily need to be in the same place as the Hugin source itself although the "External Programs" directory structure is by default placed inside the Hugin SVN tree when you download Hugin.<br /><br />
The first question is: Where do you ''want'' to have your development tree? As you (might) know, the "normal" locations are <tt>/opt/local</tt> for MacPorts, <tt>/sw</tt> for Fink and finally <tt>/usr/local</tt> for all builds following "Linux" rules. '''We do not want to use these locations'''! Apart from the fact that it is a bad idea to mix up development trees, another drawback is that these directories are not in "user space", therefore always requiring a root authorization, e.g. "<tt>sudo make install</tt>" as a last step. <br />
When keeping the development tree in user space (e.g. <tt>/Users/<your_username>/development/</tt> or <tt>/Users/Shared/development/</tt>), you don't need to "sudo". Note that the latter option also creates a <tt>development</tt> directory but keeps it away from your "normal" user data.<br /><br />
So, from this moment "we" have decided to build our development tree in user space.<br /><br />
''Note'': As mentioned before: If you position your development tree '''outside''' user space, you need to run ''everything'' as sudo. The scripts are not tailored towards that "sudo" kind of use and need modification to work that way.<br />
<br />
====Inside hugin SVN tree====<br />
The "External Programs" development tree is placed inside the hugin SVN tree when you download Hugin. After you downloaded Hugin from SVN, you will find inside the <tt>hugin</tt> directory the following directory structure:<br />
<blockquote><tt><br />
hugin<br /><br />
:/...other directories inside hugin<br /><br />
:::/'''mac'''<br /><br />
::::'''/Documents'''<br /><br />
::::'''/ExternalPrograms'''<br /><br />
:::::::::'''/scripts'''<br /><br />
:::/<more files inside mac><br />
:/...other directories inside hugin<br /><br />
</tt></blockquote><br />
Say you have downloaded hugin in <tt>/Users/<your_username>/development</tt> (Remember that "we" decided to keep it in user space?), than your "External Programs" build tree will be inside <tt>/Users/<your_username>/development/hugin/hugin/mac/ExternalPrograms/</tt>.<br /><br />
''Note'': You will also find a <tt>mac</tt> directory inside the <tt>platforms</tt> directory. This <tt>hugin/platforms/mac/</tt> directory is meant for user added tools like [http://www.erik-krause.de/ Erik Krause's] droplet scripts, which you will find in <tt>platforms/windows</tt>.<br />
<br />
====Outside Hugin SVN tree====<br />
Based on what I explained above you could also decide to place your build tree for the "External Programs" ''outside'' the hugin SVN tree. An option might be <tt>/Users/<your_username>/development/ExternalPrograms/</tt>.<br />
<br />
<blockquote>'''Pro's and Cons of "outside" Hugin SVN tree'''<br /><br />
''Pro's:''<br />
* You have your "External Programs" build tree separate from the hugin source. You can delete and recreate the Hugin SVN directory anyway and anytime you want without touching your carefully built "External Programs".<br />
* If you plan to build more universal software using this approach, you can share this directory (or just as well build another one).<br /><br />
''Cons:''<br />
* If updates in SVN are applied to the "External Programs" build scripts, you need to track that and manually copy these to your separate build tree.</blockquote><br />
(Currently I have my "External Programs" build tree inside hugin as I started it this way. I once needed to delete my hugin SVN tree and I first moved my <tt>mac</tt> directory (including <tt>ExternalPrograms</tt>) out of the way, deleted the hugin svn tree, downloaded the new hugin svn tree, moved the <tt>mac</tt> directory back inside and svn synced hugin again to get possible changes in the mac or scripts directory. You just have to remember that you need to do that.)<br />
<br />
===Creation of the "External Programs" development tree===<br />
If you leave the "External Programs" development tree inside the Hugin SVN tree, you don't have to do anything and for simplicity this HowTo focuses on that way of working. <br /><br />
If you want to create it outside the hugin svn tree, I advise you to first create a <tt>development</tt> directory inside your home directory and to create the <tt>ExternalPrograms</tt> directory inside that <tt>development</tt> directory.<br /><br />
As mentioned: This HowTo focuses on keeping it in the Hugin svn tree. You need to change the paths as mentioned in the rest of this HowTo, according to your choices.<br />
<br />
===Prepare the build environment===<br />
Our build environment uses a lot of preset environment variables. These variables are all set by calling a text file. This text file is "<tt>SetEnv-universal.txt</tt>". You can find this file inside <tt>hugin/mac/ExternalPrograms/scripts</tt>.<br />
In the top of this file you will find the following two lines:<br />
<pre># has to be the absolute path from /<br />
myREPOSITORYDIR="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository";</pre><br />
The path in the <tt>myREPOSITORYDIR</tt> variable needs to exactly match the path you use (This example show the (current) default one from the SVN). So, if you are Spiderman and you build inside your HOME directory you need to specify:<br />
<pre>myREPOSITORYDIR="/Users/Spiderman/development/hugin/mac/ExternalPrograms/repository";</pre><br />
Check it, and check it again !!<br /><br />
You do not need to modify anything below this line.<br />
<br />
The "<tt>SetEnv-universal.txt</tt>" has a line containing ARCHS="ppc i386" and the <tt>SetEnv-leopard.txt</tt> has a line containing ARCHS="ppc i386 ppc64 x86_64". Even if you are on Leopard, please use the <tt>SetEnv-universal.txt</tt> and stay away from 64bit builds for the time being. Read [[#32bit versus 64bit]] for more info.<br />
<br />
=='''Building the "External Programs"'''==<br />
===Building Subversion (SVN)===<br />
''(Note: Tiger and earlier only)''<br />Before being able to download Hugin from svn we need to have svn in place. If you are on Leopard (MacOSX 10.5.x), you are fine and you can skip this step. If you are on Tiger (MacOSX 10.4.x) or an earlier version you need to build it yourself.<br /><br />
You first need to [[Hugin_Compiling_OSX#Install_Macports | Install Macports]] (if you did not already do so) as described in [[Hugin_Compiling_OSX | Hugin Compiling OSX]]. Then you need to install Subversion (svn) like:<br />
<blockquote><pre>$ sudo port install subversion</pre></blockquote><br />
<br />
===Get Hugin from SVN===<br />
Cd into your development tree and download hugin from svn like: <blockquote><pre>$ cd ~<br />
$ cd development<br />
$ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin</pre></blockquote><br />
Inside <tt>/Users/<your_username>/development</tt>, you will now have a directory <tt>hugin</tt>. The full path to your "External Programs" development tree will be <tt>/Users/<your_username>/development/hugin/mac/ExternalPrograms</tt>.<br />
<br />
===Get MacPorts and/or Fink out of the way===<br />
Now we really need to get MacPorts and/or Fink out of the way. We want to make a completely separate development tree. This means that we do not want to link to any library or binary outside our "External Programs" development tree (unless they are true Mac system libraries that are part of your MacOSX version). If we accidentally ''do'' link to non-system libraries outside our tree we will have problems when we build the bundle and certainly when we want to distribute it. So to get them out of the way, we do the following:<br />
<blockquote><pre>$ sudo mv /opt /opt.org<br />
$ sudo mv /sw /sw.org<br />
$ sudo mv /usr/local /usr/local.org</pre></blockquote><br />
Note: The <tt>usr/local</tt> is in case you have built libraries or binaries without MacPorts or Fink.<br /><br />
'''Note 2: Do not use "<tt>sudo mv /usr /usr.org</tt>" as <tt>/usr</tt> is vital for proper system functioning!!!''' If you accidentally do this, you need to reboot using your Mac DVD, go into the terminal and move it back.<br />
<br />
===Build the "External Programs"===<br />
Building the necessary libraries and binaries which Hugin depends on, the so called "External Programs" is now relatively easy.<br />
* You <tt>cd</tt> into your ExternalPrograms subdirectory, like <blockquote><pre>cd /<path_to>/ExternalPrograms</pre></blockquote><br />
* Download the necessary source packages (Google for it, copy them from your MacPorts and/or Fink base if available). The script names tell you which ones you need.<br />
* untar/unbzip2 the source packages. It's best to do this in the ExternalPrograms directory so that you will have all kind of subdirectories containing the source, like jpeg-6b, tiff-3.8.2, enblend, wxMac-2.8.7 and so on.<br />
<br />
And as an example for libpng:<br />
<blockquote><pre>$ bunzip2 libpng-1.2.24.tar.bz2<br />
$ tar -xvf libpng-1.2.24.tar<br />
$ cd libpng-1.2.24</pre></blockquote><br />
<br />
<br />
As mentioned in [[#Prepare the build environment]] we need to set our build environment before we can start compiling our libraries and binaries.<br />
This setting can be done anywhere from the system and doesn't need to been done from our library directory.<br />
But assuming we are still in our libpng directory we issue the command:<br />
<blockquote><pre>$ source ../scripts/SetEnv-universal.txt</pre></blockquote><br />
<br />
Now we can really start building our libraries and binaries. You do this by calling the right shell compilation script (still using libpng as an example).<br />
<blockquote><pre>$ sh ../scripts/libpng.sh</pre></blockquote><br />
<br />
===Order of building the "External Programs"===<br />
Some libraries and programs are dependent on other libraries. This means that these libraries need to be built first. As a rule of thumb, build your libraries in the following order (shell script names): <br />
libjpeg.sh, libtiff.sh, libpng.sh, expat.sh, lcms.sh, ilmbase.sh, openexr16.sh, boost.sh, wxmac28.sh, pano13.sh, libexiv2.sh<br />
<br />
And for the binaries:<br />
gnumake.sh, autopano-sift-C.sh, enblend31.sh, panomatic.sh<br />
<br />
''Note: You need to examine the scripts before executing them as some script use major and minor library numbers. These numbers are set from the script and need to be changed if your library version changes.''<br />
<br />
===Cleaning up===<br />
Apart from the wxmac (wxwindows) source tree, you can remove every library source tree if you want to. <br />
The wxmac source tree is necessary for the Xcode project. Xcode needs the “localization” source files.<br />
When you are finished building you can also reinstate the Macports or Fink directories you had disabled (see [[#Get MacPorts and/or Fink out of the way]]).<br /><br /><br />
<br />
==Xcode compiling Hugin==<br />
===XCode basic walk-through===<br />
This HowTo will not discuss how to use XCode. It will only explain some very basic steps to get you going. The rest is up to you (''Xcode - the Final Frontier...............To boldly go where no man has gone before.'')<br />
Sometimes small changes need to be made to the Xcode project due to added tools (matchpoint recently) or added or removed source files. These kind of actions will not be explained either in this HowTo.<br />
<br />
When you double-click the hugin.xcodeproj, Xcode will start and show you the following screen: <br />
In the Top section you see the Menu/Toolbar.<br />
On the left side you see the navigation panel.<br />
On the right side you see the File section.<br /><br />
[[Image:Xcode screen.png|700px|Xcode screen layout]]<br />
<br />
<br />
<br /><br /><table border="0" width="600"><TR><TD>[[Image:Xcode files section.png | 229px | left | frame | Xcode "files" section]]</TD><TD valign="top">In the left Navigation panel you see little triangles in front of the icons and their descriptions. These triangles can be used to open or close the sub-sections. Double-clicking the icons has another function and will bring you to the properties of that subsection. If you click the little triangle in front of Hugin, you see the directory structure of the files the Hugin project uses. Please note that this is not a real representation of the hugin directory but a user-created representation. Note however that the "files" in here are actually links to your real files. If you double-click them, the Xcode editor will open them for editing and save them back to the file system.<br /><br /></TD></TR><br />
<TR><TD>[[Image:Xcode targets section.png | 180px | left | frame | Xcode Targets section]]</TD><TD valign="top">Below the Hugin icon/description, you'll find the Targets section. Here you need to define what needs to be compiled, linked, copied and so on to create a binary or library, or a bundle containing these binaries and libraries. In case of a complex build project like Hugin, you first need to compile underlying tools and libraries, than build hugin and link hugin against these underlying tools and libraries, and finally create the bundle including "some copy work" to get the "External Programs" like autopano-sift-c, panomatic, the PT* tools, enblend, enfuse and the like inside the bundle.</TD></TR></TABLE><br />
Other options in the Navigation panel are not relevant or interesting, although you might see the error part quite frequently in your early attempts.<br />
<br />
===Prepare the project for our configuration===<br />
You need to tell the project where you installed your "External Programs" (wxmac, boost, libtiff and so on) to be able to compile Hugin. Also a couple of shell scripts need to be adapted. This can all be done from inside Xcode.<br />
<br />
The first thing to do is to double-click the blue icon before Hugin [[Image:Xcode huginproject icon.png]] in the top-left corner of the Navigation pane. If you do this, the following screen will open.<br /><br />
[[Image:Hugin projectinfo general.png | 700px]]<br /><br />
This "General" tab defines the location where your Hugin.app, and the intermediate files, will be built. By default a build directory will be created in the same directory where your Hugin.xcodeproj resides. If you want another location you can change that here, but unless you know what you're doing leave it as it is.<br /><br /><br />
The second tab is the "Build" tab (see below).<br /><br />
[[Image:Hugin projectinfo build.png | 700px]]<br /><br />
You need to check, and if necessary change, the values for:<br />
* Library Search Paths<br />
* REPOSITORY_DIR<br />
* WX_INCLUDE_DIR<br />
* WX_INCLUDE_DIR_LIB<br />
* WX_MAJOR_VERSOIN (note that it says VERSOIN in stead of VERSION. Leave it like that!)<br />
All path's are relative to the location of the hugin.xcodeproj directory structure. If you did build the libraries that Hugin depends on according the steps described above, you do not need to change anything. But do check!<br />
<br />
The other tabs are not relevant, but feel free to expand your knowledge.<br />
<br />
===Prepare the scripts before building===<br />
<table border="0" width="600"><TR><TD>[[Image:Xcode script preparation.png | left | frame | 271px | Some of the necessary scripts]]</TD><TD valign="TOP"> The project uses a couple of shell scripts to get everything into the bundle. In an Xcode project you can define steps for this in your Targets. These steps then consist of these scripts.<br />
Note though that if these scripts are not correct, Xcode will generate a non-fatal error. However, this non-fatal error for Xcode will quite often be a fatal error for your final bundle as it will miss "something" and it will simply not run or not run correctly.<br />
Yoy can take a look at the target Hugin: Open Targets -> Hugin and double-click (for example) the entry "Complete bundle". This will show you how to embed scripts.<br />
Note however, that you do not edit the scripts from the Target(s) position. You edit the script inside the files section (see [[#XCode basic walk-through]]). In this project everything is already at it's correct position. </TD></TR></TABLE><br />
<br />
<br />
<br />
====Edit localised.sh====<br />
Move (back) in the navigation pane to the top of your project and open the top section (the "file" section), open the <tt>mac</tt> "directory" and locate <tt>localised.sh</tt>. Double-click <tt>localised.sh</tt> to open it.<br />
In the top of the script you will find the following lines:<br />
<pre>huginVer="$HUGIN_PACKAGE_VERSION"<br />
wxDir="./ExternalPrograms/wxMac-2.8.7"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
huginsrcdir="../src/hugin1/hugin"<br />
xrcsrcdir="$huginsrcdir/xrc"<br />
translationsdir="../src/translations"<br />
</pre><br />
Change the <tt>wxDir</tt> to the directory where your wxmac '''source code''' resides.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit Complete-bundle.sh====<br />
Locate the <tt>Complete-bundle.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>dylib_dir="../mac/ExternalPrograms/repository/lib"<br />
old_install_name_dirname="/Users/Shared/development/hugin_related/hugin/mac/ExternalPrograms/repository/lib"<br />
dylib_install_loc="Libraries"<br />
new_install_name_dirname="@executable_path/../$dylib_install_loc"<br />
</pre><br />
Change the <tt>dylib_dir</tt> to the correct relative path.<br /><br />
Change the <tt>old_install_name_dirname</tt> to the correct '''absolute''' path.<br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
====Edit copyExifTool.sh====<br />
If you have Exiftool on your system, you need to edit this script too. As mentioned in the early lines of [[#Prepare the scripts before building]] Xcode will generate a non-fatal error if Exiftool is not available (or if you configured the script incorrectly), but in this case Hugin will run without it as it is an "extra" tool and Hugin can run without it.<br /><br />
Locate the <tt>copyExifTool.sh</tt> script and double-click to open it. In the top of the script you will find the following lines:<br />
<pre>exiftoolDir="./ExternalPrograms/Image-ExifTool-7.25"<br />
resdir="$TARGET_BUILD_DIR/Hugin.app/Contents/Resources"<br />
</pre><br />
Change the <tt>exiftoolDir</tt> path to the path where your Exiftool resides.<br /><br />
Click (Menu) File->Save or <Command>-S to save the script. Close it.<br />
<br />
===Compile and build our Hugin.app===<br />
====Final check====<br />
We make one final check.<br /><br />
[[Image:Xcode configure build.png|512px]]<br />
<br />
<br />
Set the "Active Target" to "configure" and "Active Build Configuration" to "Release". Now click the "Build" icon. This will only take a few seconds or less. In the status bar you will see the message concerning this step. It should say "Build succeeded" on the left and "Succeeded" on the right.<br /><br />
[[Image:Xcode configure build success.png|800px]]<br />
<br />
If this is the status message, you can really start building your Hugin.app.<br />
<br />
====Building Hugin.app====<br />
Set the "Active Target" to "all" and click "Build". Now this will take a very long time.<br /><br />
[[Image:Xcode build all.png|512px]]<br />
<br />
<br />
If everything compiles and builds correctly, you will finally get a status message like:<br /><br />
[[Image:Xcode build all success.png|800px]]<br />
<br />
<br />
Note that the build has succeeded even though you see two error messages (in this screen dump). These are the non-fatal errors mentioned before. Double-click the "error" icon [[Image:Xcode error icon.png]] to display the errors.<br />
In this case it mostly means that some language files (*.po) could not be found. The available languages (= *.po files) differ between Hugin and wxmac, the scripts can not solve this entirely and will generate errors. These *.po errors are non-fatal errors for the Hugin.app. Hugin or wxmac will simply not be able to show messages/text in that language and will fall back to English.<br />
<br />
If you did stick to all the "default settings", you will find your Hugin.app inside <tt>../mac/build/Release</tt> among lots and lots of other files. All these other (intermediate build) files are not relevant. If built correctly, the Hugin.app is a completely portable application and everything is inside Hugin.app. <br /><br />
<br />
<br />
====Testing Hugin.app====<br />
Now you need to test run your bundle. The first test is to see whether your application runs at all. Double-click it and try to make a panorama. If this works, it's party time!!! So, go party and when you're finished come back for the next test.<br /><br />
<br />
Now that you managed to get a working Hugin.app via Xcode we need to check if it is really a portable application.<br />
If you were ''completely'' successful in building your Hugin.app, than all binaries, tools and libraries should be "inside" the bundle and should know "how to find each other". The best way to test this is to copy the Hugin.app to another Mac and run Hugin.app there. As this is not always possible, copy your Hugin.app to another location on your mac and rename<br /><br />
* your mac directory inside your hugin source directory to mac.org,<br />
* your /opt/local to /opt/local.org (in case you have Macports),<br />
* your /sw directory to /sw.org (in case you have Fink),<br />
* your usr/local directory to /usr/local.org <br />
(You can off course rename your directories to anything you like). <br />
Renaming your directories will prevent Hugin from trying to link to the libraries inside these directories. If Hugin does it will crash and show an error message that Hugin tried to link to <tt><path to>/ExternalPrograms/repository/lib/<some library></tt> instead of the bundle library (or even worse for example to <tt>/opt/local/lib/<some library></tt>, which means that you did not correctly [[#Get MacPorts and/or Fink out of the way]]).<br /> The <tt>Complete-bundle.sh</tt> script mentioned in [[#Edit Complete-bundle.sh]] will alter the "hard linked" paths inside Hugin and inside the libraries to "internal" paths, using the [http://www.hmug.org/man/1/INSTALL_NAME_TOOL.php install_name_tool], to make sure that they can find each other inside the bundle. If this did not work correctly (one of the non-fatal errors for Xcode), your Hugin.app will not run on another system as it will still try to use the libraries inside your build environment. This build environment is not available on another "Xcode and Hugin free" Mac.<br /><br />
<br />
''Note:'' To see errors directly you need to start Hugin.app from the command line, e.g. from a terminal. Issue the command <pre>$ open Hugin.app &</pre> to do that (in case you didn't know). If you double-click Hugin.app from Finder you won't see (error) messages.<br />Next to this you should check the logs (in case of crashes that is). You will find these in <tt>/Users/<user name>/Library/Logs/CrashReporter/</tt>. If "things" go wrong you can find there logs like <tt>Hugin.crash.log</tt>. These logs are not recreated but new error reports are just added to the log, making them bigger and bigger (But off course you won't run into errors). <br />
<br />
<br />
<br />
If everything worked fine you really made a portable application. Congratulations!<br />
<br />
=='''Notes'''==<br />
<br />
===32bit versus 64bit===<br />
Tiger (Xcode 2.4) enables you to build universal binaries and libraries for PPC and i386. Leopard (XCode 3.0) enables you to build universal binaries for PPC and i386, but also for PPC_64 (theoretically) and X86_64. If you want to do this you need to use SetEnv-leopard.txt. At this moment this is "''extremely and utterly experimental''" as:<br />
:# most "Linux derived" libraries and binaries will not compile for Apple 64bit.<br />
:# If they compile and build, they are not well optimized. <br />
:# only enblend can use the full potential of 64bit (currently).<br />
:# You build the 64bit part only for Leopard users on 64bit hardware. 32bit universal will run on ''every'' Mac.<br />
:# The current bundle is 85 MB. If you build for three architectures (ppc/i386/x86_64) it will be approx 120 MB.<br />
Use at your own risk. But for the time being: stay away from it.<br />
<br />
<br />
===Command line building with Xcode===<br />
Xcode has also a command line version named xcodebuild. If you prefer the command line than this tool is nice. You miss the nice integrated editor off course, so you need vi or pico (or some other editor) to change source code.<br />
(I use it for for remote ssh builds using vi as code editor).<br />
<br />
Say you want to use (or experiment) with the command line builder, you need to cd into the <tt>mac</tt> directory and issue the following commands:<br />
<blockquote><pre>$ cd <path_to>/hugin/mac<br />
$ xcodebuild -project Hugin.xcodeproj -alltargets -configuration Release</pre></blockquote><br />
''Note:'' Even if you run the build from the command line, the complete environment will be opened. When finished, it will close again.<br />
<br />
If you want more info just issue a <tt>xcodebuild --help</tt> for short help or a <tt>man xcodebuild</tt> for more extensive help. And you can read the docu/helpfiles from inside Xcode.<br />
<br />
If you want to make automated nightly builds of Hugin you can easily script that with the command line version (svn refresh, command line build, command line creation of the dmg, ftp to website). You could even issue the svn, dmg creation and ftp commands from the Xcode project which means that you only have to script the xcodebuild.<br />
<br />
=='''External Links'''==<br />
- What is [http://en.wikipedia.org/wiki/Endianness endianness].<br /><br />
- MacPorts set endianness [http://guide.macports.org/#reference.variables read-only] for the platform it's installed on.<br /><br />
- MacOSX online [http://www.hmug.org/man/ Darwin man pages] from the HMUG user group.<br /><br />
<br />
[[Category:Software:Hugin]] [[Category:Software:Platform:Mac OS X]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Historical:SoC_2008_application&diff=10107Historical:SoC 2008 application2008-03-13T01:37:06Z<p>Ippei: /* Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. */</p>
<hr />
<div>=== Describe your organization ===<br />
<br />
Our organization is a composite of several open source/free software projects: hugin, panotools and enblend/enfuse. We are used to collaborate across timezones and cultures.<br />
<br />
=== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating? ===<br />
<br />
http://www.flickr.com/search/groups/?q=hugin<br />
<br />
http://www.flickr.com/photos/sbprzd/2126554118/<br />
<br />
http://www.flickr.com/photos/sbprzd/2125768589/<br />
<br />
=== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. ===<br />
<br />
hugin/panotools participated in GSoC 2007. We consider this participation successful for both organization and students. Our projects were:<br />
<br />
* New extensible modular GUI framework for Panorama Photography. Ippei Ukai has refactored the hugin code, cleaning the interface and prepared for future Qt development while keeping wxWidgets compatibility. The upcoming hugin release will still use wxWidgets mainly because the development of specific Qt widgets is very time consuming. However, future plans are also to provide hooks for rapid GUI development with higher level languages such as Python, and it will benefit largely from his refactorization as well.<br />
* Anti-ghosting HDR panorama blending and merging algorithm. During GSoC Jing presented her results at the IVRPA conference in Berkeley. She successfully finished the project and the code is now merged into hugin source code tree which we expect to release as 0.7.4 soon.<br />
* Interactive Panoramic Viewer. This is a work on FreePV panoramic viewer. Since GSoC the work is still happening in the [http://freepv.svn.sourceforge.net/viewvc/freepv/freepv/branches/branch_leonox/ SoC branch of SVN]. There is no release featuring changes done by the student yet. It is quite possible to see FreePV coce being integrated into VLC which is a popular crossplatform media viewer.<br />
* Feature matching for panoramic images. Zoran Mesec successfully created Matchpoint - a new automatic control points generator that isn't affected by patents. Zoran also volunteered to be mentor for further Matchpoint development this year in GSoC2008 which shows his constant involvement into the project.<br />
* VIPS integration. This project was supposed to bring very large images support to hugin, but failed.<br />
<br />
=== Who will your organization administrator be? Please include Google Account information. ===<br />
<br />
Alexandre Prokoudine will be primary administrator. He currently resides in Moscow, Russia. He is involved into open source projects since early 2002 as technical writer, GUI translator (hugin, Inkscape, Scribus, Audacity, Rosegarden etc.) and functional specifications author.<br />
<br />
Being interested in design and photography since 2005 he quickly started enjoying his role of communicator between developers of various open source projects. In 2006 Jon Philips, a Creative Commons advocate, and he co-founded a CREATE project where developers of creative applications (mostly graphics related ones as of now) can meet and work out standards, unified approaches to solving real life user issues etc.<br />
<br />
In 2007 Alexandre served as backup administrator of hugin/panotools and Scribus organizations for Google Summer of Code.<br />
<br />
His Google account is alexandre.prokoudine@gmail.com<br />
<br />
=== What license(s) does your project use? ===<br />
<br />
Both hugin, enblend/enfuse, panotools and matchpoint use GPL v2 or above. <br />
<br />
=== What is the URL for your ideas page? ===<br />
<br />
http://wiki.panotools.org/SoC_2008_ideas<br />
<br />
=== What is the main development mailing list or forum for your organization? ===<br />
<br />
http://lists.sourceforge.net/lists/listinfo/panotools-devel<br />
<br />
=== What is the main IRC channel for your organization? ===<br />
<br />
We do not use IRC for communication. During GSoC 2007 we used Skype, but this is unlikely to happen again.<br />
<br />
=== Does your organization have an application template you would like to see students use? If so, please provide it now. ===<br />
<br />
* name / university / current enrollment<br />
* short bio / overview of your educational background<br />
* did you ever code in C or C++, yes/no? please provide examples of code.<br />
* do you photograph panoramas? please provide examples.<br />
* do you make other use of hugin/panotools than for stitching panoramas? please describe and show examples.<br />
* were you involved in hugin/panotools development in the past? what was your contribution?<br />
* were you involved in other OpenSource development projects in the past? which, when and in what role?<br />
* why have you chosen your development idea and what do you expect from your implementation?<br />
* how much time you plan to invest in the project? (we expected full time 40h/week but better make this explicit)<br />
* please provide a schedule of how this time will be spent on subtasks of the project. While this is only preliminary, be aware that at the beginning of the project you will be required to provide a detailed plan, and during the project you will issue weekly progress reports against that plan.<br />
<br />
=== Who will be your backup organization administrator? Please include Google Account information. ===<br />
Yuval Levy is chosen to be backup administrator. He did a perfect job as primary administrator during GSoC 2007. His Google associated email address is google at levy.ch.<br />
<br />
=== Who will your mentors be? Please include Google Account information. ===<br />
<br />
'''Pablo d'Angelo'''<br />
<br />
Pablo d'Angelo is the initiator and main developer of the hugin project. He has studied computer engineering at the University of applied sciences Ulm, and is currently working at the DaimlerChrysler Research Center in Ulm, where he does research on advanced 3D reconstruction techniques for industrial quality inspection. He also has a PhD in the field of computer vision from the University of Bielefeld, which was granted in Summer 2007.<br />
<br />
His Google associated account is pablo.dangelo at web.de.<br />
<br />
''' Andrew Mihal '''<br />
<br />
Andrew Mihal is the project lead and main developer of the Enblend/Enfuse project. He received his Ph.D. in Electrical Engineering and Computer Science from the University of California, Berkeley. His specialization is in software for electronic design automation. He is also an amateur photographer, and enjoys turning academic research papers into useful open source projects as a hobby.<br />
<br />
His Google associated account is andrewcmihal at gmail.com<br />
<br />
''' Jim Watters '''<br />
<br />
Jim Watters is a Software Engineer at JFL Peripheral Solution, in Ottawa, Ontario, Canada, where he designs software for scanners. An avid user of PanoTools since 2000. A growing contributer to the source code of PanoTools since Aug 2003 and a current maintainer of PanoTools (http://panotools.sourceforge.net). Before receiving his degree in Computer Software in 1999, he received a diploma of Fine Art in Photography in 1990. <br />
<br />
Most recently his attention has been directed to creating Immersive Panoramic Video. <br />
<br />
His google associated account is jwatters at photocreations.ca.<br />
<br />
''' Daniel M German '''<br />
<br />
He is assistant professor at the Department of Computer Science at the University of Victoria, in British Columbia, in Canada. He received his PhD in Computer Science from the University of Waterloo in Canada.<br />
<br />
One of his areas of research is open source software development. He is interested in understanding how globally distributed individuals are able to work together to create commercial strength software. He has also explored the use of historical artefacts (such as version control logs, emails, defect tracking) to understand how a system has evolved and how this information can be used to continue its development.<br />
<br />
More recently he has been interested in the field of computational photography. More specifically on how to project extreme wide-angle images and spherical panoramas into acceptable flat representations.<br />
<br />
During the last year he has been the maintainer of Panotools (http://panotools.sourceforge.net).<br />
<br />
As a university professor one of his jobs is the supervision of students. He has graduated 6 Master's students, and currently supervising 3 Master's, and 1 Ph.D. Student. He has supervised more than a dozen honours projects of undergraduate students in computer science.<br />
<br />
He is an avid photographer. His works have been exhibited in several galleries. <br />
<br />
His Google associated account is dmg at uvic.ca.<br />
<br />
''' Alexandre Jenny '''<br />
<br />
Alexandre Jenny is graduate from Ecole des mines de Nancy, in physics and computer sciences. He spent 5 years in the computer game industry before starting to interest in panoramic.<br />
<br />
He's casual photographer and he started interest in panorama when he moved near Alps mountains. After having climbed during 5 hours and reached the top, it's really frustrating not beeing able to capture the whole panorama. So he started studying this field at this time. It was during the very early stage of Panotools. The main problem was not being able to create automatically controls points, so he wrote the first SIFT control point generator which is always used a lot today as a Panotools plugin : autopano v1.03. <br />
<br />
After this first release and because he felt that some business could be build upon panoramic, he founded Kolor, a well know business which is the creator of [http://www.autopano.net Autopano Pro], a fully automatic stitcher. Autopano Pro uses an industrial strong implementation of the SIFT algorithm, but has also many other features in a single easy to use package.<br />
<br />
His Google associated account is alexandrejenny at kolor.com.<br />
<br />
'''Zoran Mesec'''<br />
<br />
He is a student in the final year of undergraduate study of Computer and Information Science at University of Ljubljana. He has been a part of hugin's participation at GSoC 07 as a student where he successfully completed the project [[SoC2007_projects#Automatic_feature_detection_for_panoramic_images]] under the mentorship of dr. Bay. He continued to develop his work during the year and created MatchPoint, automatic control point suite. This year he is taking GSoC at a higher level, based on his past experience and knowledge in computer science and photography.<br />
<br />
His Google associated account is zoran.mesec@gmail.com.<br />
<br />
=== What criteria did you use to select these individuals as mentors? Please be as specific as possible. ===<br />
<br />
* academic experience - most of them are or will very soon become PhD and have mentoring experience<br />
* hands on experience with our code<br />
* knowledge of the wider universe of code applied to produce stitched panoramas<br />
* most of them have practical experience of applying the code to panorama production<br />
<br />
=== Steering Committee ===<br />
<br />
This year we also have a steering committee - a group of professionals in panorama making that will help us support our students.<br />
<br />
'''G. Donald Bain'''<br />
<br />
G. Donald Bain manages the Geography Computing Facility at the University of California Berkeley, where he also teaches cartography and field studies. The rest of the time he devotes to VR.<br />
<br />
Hi is a board member of IVRPA.<br />
<br />
He travels and take panoramas for his web site: [http://virtualguidebooks.com/ Don Bain's Virtual Guidebooks]. This project (his wife refers to it as his obsession) has taken him from Tahiti to the Arctic, from the prehistoric ruins of the Southwest to the glaciers of the Canadian Rockies. As a compulsive educator it has been a real treat, documenting and sharing his landscapes with the world. He has taken over 4000 panoramas, with about 3500 currently on the site.<br />
<br />
He co-founded the World Wide Panorama, the largest international collaborative effort showcasing over 3000 panoramas from VR-artists all over the world taken over 11 editions.<br />
<br />
'''Yuval Levy'''<br />
<br />
Last year's GSoC admin for this team. [http://www.photopla.net/] [http://panospace.wordpress.com/]<br />
<br />
'''Bruno Postle'''<br />
<br />
Bruno Postle trained as an architect and now works designing and engineering lightweight/portable/temporary buildings, monumental sculptures and anything else that comes along. Bruno has been a long-time contributor to the [[hugin]] project, and maintains a number of CPAN modules including [http://search.cpan.org/dist/Panotools-Script/ Panotools::Script], a module for manipulating hugin project files. He also [http://www.flickr.com/photos/36383814@N00/ takes panoramic photographs].<br />
<br />
'''Thomas Rauscher'''<br />
<br />
Thomas Rauscher is graduate student at Vienna University of Technology in computer graphics, contributed to several parts of the PanoTools like [[PanoTools Anti Aliasing Filters]], started the [[Freepv]] sourceforge project, and he is a moderator and web admin for PanoTools mailing list. He is also working 3 years in this field with his company [http://gardengnomesoftware.com/ Garden Gnome Software]. In GSoc2007 he help mentoring the [[Interactive Panoramic Viewer]] project.<br />
<br />
'''Ken Turkowski'''<br />
<br />
He is project leader, director, technical contributor, and/or consultant in the areas of 3D graphics, 2D graphics, digital video, image processing, computer vision, image compression, signal processing, dynamics and numerical analysis. Years ago he led research group of QuickTimeVR - the first panoramic images viewer.<br />
<br />
=== What is your plan for dealing with disappearing students? ===<br />
<br />
The very first thing we'll do is making sure we pick the right students. Our estimations are going to be based on the following criteria:<br />
<br />
* students should be avid photographers;<br />
* students should be able to prove that their programmings skill match our request;<br />
* students should be able to prove that they have experience working with a mentor.<br />
<br />
We are going to do our best to have them understand that GSoC is a both (close to) full time job and fun, so that they treat it with responsibility, but do not consider it a total boredom.<br />
<br />
Next step is motivation. <br />
<br />
The point of participating at GSoC for us is getting new contributors who bring innovation and stick to affiliated projects.<br />
<br />
Last year we organized delivery to student of brand new panoramic heads sponsored by their manufacturer - Agno's Tech Engineering. We are investigating such possibility for this year's project again.<br />
<br />
Depending on the context it might also be possible to structure the work as academic credits to further incentivation.<br />
<br />
In case a student cannot deliver good enough results we are not going to drop all the work he managed to do and keep development at highest possible pace to make sure the community around affiliated project will not suffer in any way and any amount of money invested to the project by Google isn't completely lost.<br />
<br />
=== What is your plan for dealing with disappearing mentors? ===<br />
<br />
The selected mentors are well known and connected in the community. We estimate the risk of a disappearing mentor to be very low. To minimize the impact of such an unlikely event we strive to have several backup mentors who can replace others. In the event that one of the two mentors disappears, recruiting efforts for a backup mentor will start immediately. Our steering committee is well connected and will support the organizer in the efforts to recruit replacement mentors. Our community has already experienced the disappearing of key figures on important projects and survived the test when Helmut Dersch, founding father of the panotools library that is at the core of our community, disappeared.<br />
<br />
=== What steps will you take to encourage students to interact with your project's community before, during and after the program? ===<br />
<br />
First of all, we hope to recruit a student from the community. This is a growing and vibrant community. We will make sure that the student has the appropriate gear to shoot panoramas and we will do all we can to share with them our passion for panoramas. We have already organized a fund raiser to donate a fish-eye lens to one of the project maintainers [http://www.nabble.com/Fundraising-complete!-t2725697.html] in 2006, a pano head for each student in 2007, and we can do this again and again.<br />
<br />
=== What will you do to ensure that your accepted students stick with the project after GSoC concludes? ===<br />
<br />
We will make sure he or she enjoys the practical aspects of panorama photography. Part of the assignement will be of practical nature: *use* the software to learn it, not just *code*. We intend to ask them to participate in the [http://www.worldwidepanorama.com/ World Wide Panorama].<br />
<br />
[[Category:Community:Project]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Historical:SoC_2008_application&diff=10106Historical:SoC 2008 application2008-03-13T01:35:35Z<p>Ippei: /* ippei */</p>
<hr />
<div>=== Describe your organization ===<br />
<br />
Our organization is a composite of several open source/free software projects: hugin, panotools and enblend/enfuse. We are used to collaborate across timezones and cultures.<br />
<br />
=== Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating? ===<br />
<br />
http://www.flickr.com/search/groups/?q=hugin<br />
<br />
http://www.flickr.com/photos/sbprzd/2126554118/<br />
<br />
http://www.flickr.com/photos/sbprzd/2125768589/<br />
<br />
=== Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation. ===<br />
<br />
hugin/panotools participated in GSoC 2007. We consider this participation successful for both organization and students. Our projects were:<br />
<br />
* New extensible modular GUI framework for Panorama Photography. Ippei Ukai has refactored the hugin code, cleaning the interface and prepared for future Qt development while keeping wxWidgets compatibility. The upcoming hugin release will still use wxWidgets mainly because the development of specific Qt widgets is very time consuming. However, future plans are also to provide hooks for rapid GUI development with higher level languages such as Python, and it will also benefit largely from his refactorization.<br />
* Anti-ghosting HDR panorama blending and merging algorithm. During GSoC Jing presented her results at the IVRPA conference in Berkeley. She successfully finished the project and the code is now merged into hugin source code tree which we expect to release as 0.7.4 soon.<br />
* Interactive Panoramic Viewer. This is a work on FreePV panoramic viewer. Since GSoC the work is still happening in the [http://freepv.svn.sourceforge.net/viewvc/freepv/freepv/branches/branch_leonox/ SoC branch of SVN]. There is no release featuring changes done by the student yet. It is quite possible to see FreePV coce being integrated into VLC which is a popular crossplatform media viewer.<br />
* Feature matching for panoramic images. Zoran Mesec successfully created Matchpoint - a new automatic control points generator that isn't affected by patents. Zoran also volunteered to be mentor for further Matchpoint development this year in GSoC2008 which shows his constant involvement into the project.<br />
* VIPS integration. This project was supposed to bring very large images support to hugin, but failed.<br />
<br />
=== Who will your organization administrator be? Please include Google Account information. ===<br />
<br />
Alexandre Prokoudine will be primary administrator. He currently resides in Moscow, Russia. He is involved into open source projects since early 2002 as technical writer, GUI translator (hugin, Inkscape, Scribus, Audacity, Rosegarden etc.) and functional specifications author.<br />
<br />
Being interested in design and photography since 2005 he quickly started enjoying his role of communicator between developers of various open source projects. In 2006 Jon Philips, a Creative Commons advocate, and he co-founded a CREATE project where developers of creative applications (mostly graphics related ones as of now) can meet and work out standards, unified approaches to solving real life user issues etc.<br />
<br />
In 2007 Alexandre served as backup administrator of hugin/panotools and Scribus organizations for Google Summer of Code.<br />
<br />
His Google account is alexandre.prokoudine@gmail.com<br />
<br />
=== What license(s) does your project use? ===<br />
<br />
Both hugin, enblend/enfuse, panotools and matchpoint use GPL v2 or above. <br />
<br />
=== What is the URL for your ideas page? ===<br />
<br />
http://wiki.panotools.org/SoC_2008_ideas<br />
<br />
=== What is the main development mailing list or forum for your organization? ===<br />
<br />
http://lists.sourceforge.net/lists/listinfo/panotools-devel<br />
<br />
=== What is the main IRC channel for your organization? ===<br />
<br />
We do not use IRC for communication. During GSoC 2007 we used Skype, but this is unlikely to happen again.<br />
<br />
=== Does your organization have an application template you would like to see students use? If so, please provide it now. ===<br />
<br />
* name / university / current enrollment<br />
* short bio / overview of your educational background<br />
* did you ever code in C or C++, yes/no? please provide examples of code.<br />
* do you photograph panoramas? please provide examples.<br />
* do you make other use of hugin/panotools than for stitching panoramas? please describe and show examples.<br />
* were you involved in hugin/panotools development in the past? what was your contribution?<br />
* were you involved in other OpenSource development projects in the past? which, when and in what role?<br />
* why have you chosen your development idea and what do you expect from your implementation?<br />
* how much time you plan to invest in the project? (we expected full time 40h/week but better make this explicit)<br />
* please provide a schedule of how this time will be spent on subtasks of the project. While this is only preliminary, be aware that at the beginning of the project you will be required to provide a detailed plan, and during the project you will issue weekly progress reports against that plan.<br />
<br />
=== Who will be your backup organization administrator? Please include Google Account information. ===<br />
Yuval Levy is chosen to be backup administrator. He did a perfect job as primary administrator during GSoC 2007. His Google associated email address is google at levy.ch.<br />
<br />
=== Who will your mentors be? Please include Google Account information. ===<br />
<br />
'''Pablo d'Angelo'''<br />
<br />
Pablo d'Angelo is the initiator and main developer of the hugin project. He has studied computer engineering at the University of applied sciences Ulm, and is currently working at the DaimlerChrysler Research Center in Ulm, where he does research on advanced 3D reconstruction techniques for industrial quality inspection. He also has a PhD in the field of computer vision from the University of Bielefeld, which was granted in Summer 2007.<br />
<br />
His Google associated account is pablo.dangelo at web.de.<br />
<br />
''' Andrew Mihal '''<br />
<br />
Andrew Mihal is the project lead and main developer of the Enblend/Enfuse project. He received his Ph.D. in Electrical Engineering and Computer Science from the University of California, Berkeley. His specialization is in software for electronic design automation. He is also an amateur photographer, and enjoys turning academic research papers into useful open source projects as a hobby.<br />
<br />
His Google associated account is andrewcmihal at gmail.com<br />
<br />
''' Jim Watters '''<br />
<br />
Jim Watters is a Software Engineer at JFL Peripheral Solution, in Ottawa, Ontario, Canada, where he designs software for scanners. An avid user of PanoTools since 2000. A growing contributer to the source code of PanoTools since Aug 2003 and a current maintainer of PanoTools (http://panotools.sourceforge.net). Before receiving his degree in Computer Software in 1999, he received a diploma of Fine Art in Photography in 1990. <br />
<br />
Most recently his attention has been directed to creating Immersive Panoramic Video. <br />
<br />
His google associated account is jwatters at photocreations.ca.<br />
<br />
''' Daniel M German '''<br />
<br />
He is assistant professor at the Department of Computer Science at the University of Victoria, in British Columbia, in Canada. He received his PhD in Computer Science from the University of Waterloo in Canada.<br />
<br />
One of his areas of research is open source software development. He is interested in understanding how globally distributed individuals are able to work together to create commercial strength software. He has also explored the use of historical artefacts (such as version control logs, emails, defect tracking) to understand how a system has evolved and how this information can be used to continue its development.<br />
<br />
More recently he has been interested in the field of computational photography. More specifically on how to project extreme wide-angle images and spherical panoramas into acceptable flat representations.<br />
<br />
During the last year he has been the maintainer of Panotools (http://panotools.sourceforge.net).<br />
<br />
As a university professor one of his jobs is the supervision of students. He has graduated 6 Master's students, and currently supervising 3 Master's, and 1 Ph.D. Student. He has supervised more than a dozen honours projects of undergraduate students in computer science.<br />
<br />
He is an avid photographer. His works have been exhibited in several galleries. <br />
<br />
His Google associated account is dmg at uvic.ca.<br />
<br />
''' Alexandre Jenny '''<br />
<br />
Alexandre Jenny is graduate from Ecole des mines de Nancy, in physics and computer sciences. He spent 5 years in the computer game industry before starting to interest in panoramic.<br />
<br />
He's casual photographer and he started interest in panorama when he moved near Alps mountains. After having climbed during 5 hours and reached the top, it's really frustrating not beeing able to capture the whole panorama. So he started studying this field at this time. It was during the very early stage of Panotools. The main problem was not being able to create automatically controls points, so he wrote the first SIFT control point generator which is always used a lot today as a Panotools plugin : autopano v1.03. <br />
<br />
After this first release and because he felt that some business could be build upon panoramic, he founded Kolor, a well know business which is the creator of [http://www.autopano.net Autopano Pro], a fully automatic stitcher. Autopano Pro uses an industrial strong implementation of the SIFT algorithm, but has also many other features in a single easy to use package.<br />
<br />
His Google associated account is alexandrejenny at kolor.com.<br />
<br />
'''Zoran Mesec'''<br />
<br />
He is a student in the final year of undergraduate study of Computer and Information Science at University of Ljubljana. He has been a part of hugin's participation at GSoC 07 as a student where he successfully completed the project [[SoC2007_projects#Automatic_feature_detection_for_panoramic_images]] under the mentorship of dr. Bay. He continued to develop his work during the year and created MatchPoint, automatic control point suite. This year he is taking GSoC at a higher level, based on his past experience and knowledge in computer science and photography.<br />
<br />
His Google associated account is zoran.mesec@gmail.com.<br />
<br />
=== What criteria did you use to select these individuals as mentors? Please be as specific as possible. ===<br />
<br />
* academic experience - most of them are or will very soon become PhD and have mentoring experience<br />
* hands on experience with our code<br />
* knowledge of the wider universe of code applied to produce stitched panoramas<br />
* most of them have practical experience of applying the code to panorama production<br />
<br />
=== Steering Committee ===<br />
<br />
This year we also have a steering committee - a group of professionals in panorama making that will help us support our students.<br />
<br />
'''G. Donald Bain'''<br />
<br />
G. Donald Bain manages the Geography Computing Facility at the University of California Berkeley, where he also teaches cartography and field studies. The rest of the time he devotes to VR.<br />
<br />
Hi is a board member of IVRPA.<br />
<br />
He travels and take panoramas for his web site: [http://virtualguidebooks.com/ Don Bain's Virtual Guidebooks]. This project (his wife refers to it as his obsession) has taken him from Tahiti to the Arctic, from the prehistoric ruins of the Southwest to the glaciers of the Canadian Rockies. As a compulsive educator it has been a real treat, documenting and sharing his landscapes with the world. He has taken over 4000 panoramas, with about 3500 currently on the site.<br />
<br />
He co-founded the World Wide Panorama, the largest international collaborative effort showcasing over 3000 panoramas from VR-artists all over the world taken over 11 editions.<br />
<br />
'''Yuval Levy'''<br />
<br />
Last year's GSoC admin for this team. [http://www.photopla.net/] [http://panospace.wordpress.com/]<br />
<br />
'''Bruno Postle'''<br />
<br />
Bruno Postle trained as an architect and now works designing and engineering lightweight/portable/temporary buildings, monumental sculptures and anything else that comes along. Bruno has been a long-time contributor to the [[hugin]] project, and maintains a number of CPAN modules including [http://search.cpan.org/dist/Panotools-Script/ Panotools::Script], a module for manipulating hugin project files. He also [http://www.flickr.com/photos/36383814@N00/ takes panoramic photographs].<br />
<br />
'''Thomas Rauscher'''<br />
<br />
Thomas Rauscher is graduate student at Vienna University of Technology in computer graphics, contributed to several parts of the PanoTools like [[PanoTools Anti Aliasing Filters]], started the [[Freepv]] sourceforge project, and he is a moderator and web admin for PanoTools mailing list. He is also working 3 years in this field with his company [http://gardengnomesoftware.com/ Garden Gnome Software]. In GSoc2007 he help mentoring the [[Interactive Panoramic Viewer]] project.<br />
<br />
'''Ken Turkowski'''<br />
<br />
He is project leader, director, technical contributor, and/or consultant in the areas of 3D graphics, 2D graphics, digital video, image processing, computer vision, image compression, signal processing, dynamics and numerical analysis. Years ago he led research group of QuickTimeVR - the first panoramic images viewer.<br />
<br />
=== What is your plan for dealing with disappearing students? ===<br />
<br />
The very first thing we'll do is making sure we pick the right students. Our estimations are going to be based on the following criteria:<br />
<br />
* students should be avid photographers;<br />
* students should be able to prove that their programmings skill match our request;<br />
* students should be able to prove that they have experience working with a mentor.<br />
<br />
We are going to do our best to have them understand that GSoC is a both (close to) full time job and fun, so that they treat it with responsibility, but do not consider it a total boredom.<br />
<br />
Next step is motivation. <br />
<br />
The point of participating at GSoC for us is getting new contributors who bring innovation and stick to affiliated projects.<br />
<br />
Last year we organized delivery to student of brand new panoramic heads sponsored by their manufacturer - Agno's Tech Engineering. We are investigating such possibility for this year's project again.<br />
<br />
Depending on the context it might also be possible to structure the work as academic credits to further incentivation.<br />
<br />
In case a student cannot deliver good enough results we are not going to drop all the work he managed to do and keep development at highest possible pace to make sure the community around affiliated project will not suffer in any way and any amount of money invested to the project by Google isn't completely lost.<br />
<br />
=== What is your plan for dealing with disappearing mentors? ===<br />
<br />
The selected mentors are well known and connected in the community. We estimate the risk of a disappearing mentor to be very low. To minimize the impact of such an unlikely event we strive to have several backup mentors who can replace others. In the event that one of the two mentors disappears, recruiting efforts for a backup mentor will start immediately. Our steering committee is well connected and will support the organizer in the efforts to recruit replacement mentors. Our community has already experienced the disappearing of key figures on important projects and survived the test when Helmut Dersch, founding father of the panotools library that is at the core of our community, disappeared.<br />
<br />
=== What steps will you take to encourage students to interact with your project's community before, during and after the program? ===<br />
<br />
First of all, we hope to recruit a student from the community. This is a growing and vibrant community. We will make sure that the student has the appropriate gear to shoot panoramas and we will do all we can to share with them our passion for panoramas. We have already organized a fund raiser to donate a fish-eye lens to one of the project maintainers [http://www.nabble.com/Fundraising-complete!-t2725697.html] in 2006, a pano head for each student in 2007, and we can do this again and again.<br />
<br />
=== What will you do to ensure that your accepted students stick with the project after GSoC concludes? ===<br />
<br />
We will make sure he or she enjoys the practical aspects of panorama photography. Part of the assignement will be of practical nature: *use* the software to learn it, not just *code*. We intend to ask them to participate in the [http://www.worldwidepanorama.com/ World Wide Panorama].<br />
<br />
[[Category:Community:Project]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Historical:SoC_2007_project_New_GUI_Framework&diff=8782Historical:SoC 2007 project New GUI Framework2007-04-17T11:13:37Z<p>Ippei: steps of the project</p>
<hr />
<div>See [[SoC 2007 overview]] for usage hints and a page list.<br />
<br />
= Project Status =<br />
<br />
This project is now accepted for [[User:Ippei|Ippei UKAI]], with Yuval Levy assigned as his mentor. <br />
<br />
== Schedule ==<br />
<br />
I haven't planned much about this summer yet. No trips planned so far, nor any part time jobs to keep myself socialise still mainly working with this project on full-time basis. In fact, not even where to stay; most likely in Edinburgh or back home in Japan, but who knows. <br />
<br />
The major steps of this project are:<br />
# Design: of both the GUI and internal architecture<br />
#* This is the most important.<br />
# Implementation: of the main application and some sample modules<br />
#* This would take longest.<br />
# Specification: of the things left to be done after the summer as well as the module interface and templates<br />
#* This is necessary to make the outcome of the project meaningful<br />
<br />
The detailed but rough schedule is currently:<br />
* Before the official start<br />
** May 17: Last Exam; Kick-start on the project after some celebration. <br />
** - May 27: Decide the toolkit. Use-case survey; specification of the end product with illustration or mock-up. <br />
* First half<br />
** - Jun 03 (Week 1): Rough internal design of the system and interface between the components<br />
** - Jun 10 (Week 2): Setting up the environment; installation of the toolkit and build system setup<br />
** - Jul 08 (Week 3-6): Basic framework of the application; module handling, interface with lower level libraries etc.<br />
** Jul 09: Mid-term evaluations begin<br />
* Second half<br />
** - Jul 29 (Week 7-9): Most implementations to be done except the modules<br />
** - Aug 5 (Week 10): Some modules to be written. <br />
** - Aug 12 (Week 11): Finalise the module interface and template, and the list of module specifications for the future development.<br />
** - Aug 19 (Week 12): A week to spare if lucky; but more debugging and more modules would be waiting anyway<br />
* Aug 20: Final evaluations begin<br />
<br />
<br />
= New extensible modular GUI framework =<br />
<br />
The goal of this project is to build a highly extensible GUI framework for Panorama creation, with simple yet intuitive layouts that both beginners and advanced users would be comfortable to use. The application should stay cross-platform, and will reuse the existing back-end panorama creation functionality embodied by [[Hugin]]. This GUI framework would be intended to replace the existing [[Hugin]] GUI when mature.<br />
<br />
== Design Goal ==<br />
<br />
This project is committed to two groups of people:<br />
* All programmers interested in panorama photography and existing PanoTools-related developers<br />
* End-users of panorama photography with any level of experience from first timers to professionals<br />
<br />
For the programmers, the new program will be a modular framework for which they can write modules that extend any aspect of panorama creation. Think of it as the Eclipse for panorama photography. Extensible and flexible plug-in architecture with minimum dependancy. Of course, it will provide the basic functionalities like project handling, command history, and beyond (to what extent will be subject to debate especially as to the level of image handling).<br />
<br />
For the users, the details as to what's happening inside the framework means nothing. This is important. How we make the end-users, especially new users, believe what program does is up to the program design. Ask Dilbert; the engineers' job is to explain to idiots what we do. They don't need to know how we do it or even what it exactly does; only what they see on the screen is what the program does to them. If the program is too technical and complicated, then we have to rearrange it so that it makes more sense either by wrapping it around or making the change to the way it works. Reshaping the panorama creation to what users can understand, and presenting it with GUI is our commitment to the users.<br />
<br />
Those two goals may conflict with each other. As more features get available, the more complicated the program may look. Even the user commitment itself isn't simple as we have already enough features that most beginner users do not simply understand or care. How we satisfy both requirements and what to compromise when we can't make every one happy, is the decision we'd have to make. Of course I will try my best to set the architecture/framework design to accommodate the needs of as many people as possible especially the entry level users.<br />
<br />
== Deliverables ==<br />
<br />
# Cross-platform Application<br />
#* Acceptable look-and-feel with every platform's standard<br />
#* Minimum amount of platform specific code<br />
# Completely modular system for organising the functionalities<br />
#* Clear separation of the interface and implementations<br />
#* Intuitive GUI for displaying those modules suitable for different levels of users<br />
# Designs of the modules to be implemented<br />
#* Specifications of all the basic modules<br />
#** Implementing all the modules would be impossible during the summer<br />
#** The whole community including myself would continue working on those implementations after the summer<br />
#** Specifications can include mock-up or illustration to guide the implementation effort<br />
#* Organisation of the modules that show where those modules will fit into<br />
#** How they will be presented to the users<br />
#** Possibly several sets of the organisation for users from different background<br />
#* Implementation of some modules to demonstrate how the new application works<br />
#** Template for the modules to be written<br />
#** At least one sample module for basic tests<br />
<br />
<br />
The new framework shall be constructed such that users can interact with various aspects of a panorama project through modules (plug-ins), each of which provides a single, specific function. The application should provide an intuitive interface for the users to choose what to edit and display with what aspect.<br />
<br />
The modular system is crucial because panorama stitching workflows contain many steps (e.g. select or generate matching control points, optimize image placement, measure and/or correct for camera deficiencies such as vignetting, chromatic aberration, etc.). Moreover, the community comes up with new variations of each step every year, with new features and possibilities suggested every month.<br />
<br />
Also crucial is the way those modules should be organised and presented to the users. Advanced users want to have access to every available feature, while there are many beginners who need access only to the basic tasks and options in a simple and intuitive interface.<br />
<br />
Since it would be impossible to implement the entire application in one summer, this project should focus on laying the foundation upon which the community can continue work on further implementations and improvements. Once the modular framework is set and the specifications of the required tasks are presented, new interface functionality can be implemented independently and in parallel. This is also why a solid, flexible, and well-documented modular system is of such important.<br />
<br />
<br />
= Q&A =<br />
<br />
* Choice of GUI Toolkit: Qt4 is modern and has good support on most of major platforms. wxWidgets is okay, but best of all we have many lines of code that are written for wxWidgets. Scripting languages like Python may have advantages in debugging and module managements. Which one would you use?<br />
** Personally, I want to give Qt4 a try. Though its widgets look weird on Mac sometimes, it has more to offer outside the GUI itself. <small>--[[User:Ippei|Ippei]] 20:05, 17 March 2007 (CET)</small><br />
*** Qt 4.3 is getting the QtScript support as a default module; surely it's gonna be a powerful addition. <small>--[[User:Ippei|Ippei]] 00:59, 21 March 2007 (CET)</small><br />
<br />
<br />
* Possible division of the project: Dividing this project into two parallel tasks that would have little dependancy to each other would enable more work to be done this summer. Would it be possible?<br />
** The project could be divided up into two parts. However, the rough design of the entire application has to be drafted first so that the both work will be done towards the same objective. Based on that: 1. One of the tasks is to implement each module and the structure/interface of the 'Panorama project' data representation; 2. The other task is to implement the plug-in architecture and the main application that uses those plug-ins. Then the modules from task 1. can be wrapped into that plug-in architecture determined by task 2. Of course, collaboration is required. Interfaces needed by the modules created in task 1 has to be present in the plug-in architecture from task 2, and the modules from task 1 have to fit well into the main application created in task 2. <small>--[[User:Ippei|Ippei]] 00:26, 29 March 2007 (CEST)</small><br />
<br />
<br />
<br />
[[Category:Community:Project]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Historical:SoC_2007_project_New_GUI_Framework&diff=8780Historical:SoC 2007 project New GUI Framework2007-04-17T10:04:09Z<p>Ippei: revision after acceptance</p>
<hr />
<div>See [[SoC 2007 overview]] for usage hints and a page list.<br />
<br />
= Project Status =<br />
<br />
This project is now accepted for [[User:Ippei|Ippei UKAI]], with Yuval Levy assigned as his mentor. <br />
<br />
== Schedule ==<br />
<br />
I haven't planned much about this summer yet. No trips planned so far, nor any part time jobs to keep myself socialise still mainly working on GSoC full-time basis. In fact, not even where to stay; most likely in Edinburgh or back home in Japan, but who knows. <br />
<br />
* Before the official start<br />
** - May 17: Exams. Kick-start on the project after some celebration. <br />
** - May 27: Decide the toolkit. Use-case survey; specification of the end product with illustration or mock-up. <br />
* First half<br />
** - Jun 03 (Week 1): Rough internal design of the system and interface between the components<br />
** - Jun 10 (Week 2): Setting up the environment; installation of the toolkit and build system setup<br />
** - Jul 08 (Week 3-6): Basic framework of the application; module handling, interface with lower level libraries etc.<br />
** Jul 09: Mid-term evaluations begin<br />
* Second half<br />
** - Jul 29 (Week 7-9): Most implementations to be done except the modules<br />
** - Aug 5 (Week 10): Some modules to be written. <br />
** - Aug 12 (Week 11): Finalise the module interface and template, and the list of module specifications for the future development.<br />
** - Aug 19 (Week 12): A week to spare if lucky; but more debugging and more modules would be waiting anyway<br />
* Aug 20: Final evaluations begin<br />
<br />
<br />
= New extensible modular GUI framework =<br />
<br />
The goal of this project is to build a highly extensible GUI framework for Panorama creation, with simple yet intuitive layouts that both beginners and advanced users would be comfortable to use. The application should stay cross-platform, and will reuse the existing back-end panorama creation functionality embodied by [[Hugin]]. This GUI framework would be intended to replace the existing [[Hugin]] GUI when mature.<br />
<br />
== Design Goal ==<br />
<br />
This project is committed to two groups of people:<br />
* All programmers interested in panorama photography and existing PanoTools-related developers<br />
* End-users of panorama photography with any level of experience from first timers to professionals<br />
<br />
For the programmers, the new program will be a modular framework for which they can write modules that extend any aspect of panorama creation. Think of it as the Eclipse for panorama photography. Extensible and flexible plug-in architecture with minimum dependancy. Of course, it will provide the basic functionalities like project handling, command history, and beyond (to what extent will be subject to debate especially as to the level of image handling).<br />
<br />
For the users, the details as to what's happening inside the framework means nothing. This is important. How we make the end-users, especially new users, believe what program does is up to the program design. Ask Dilbert; the engineers' job is to explain to idiots what we do. They don't need to know how we do it or even what it exactly does; only what they see on the screen is what the program does to them. If the program is too technical and complicated, then we have to rearrange it so that it makes more sense either by wrapping it around or making the change to the way it works. Reshaping the panorama creation to what users can understand, and presenting it with GUI is our commitment to the users.<br />
<br />
Those two goals may conflict with each other. As more features get available, the more complicated the program may look. Even the user commitment itself isn't simple as we have already enough features that most beginner users do not simply understand or care. How we satisfy both requirements and what to compromise when we can't make every one happy, is the decision we'd have to make. Of course I will try my best to set the architecture/framework design to accommodate the needs of as many people as possible especially the entry level users.<br />
<br />
== Deliverables ==<br />
<br />
# Cross-platform Application<br />
#* Acceptable look-and-feel with every platform's standard<br />
#* Minimum amount of platform specific code<br />
# Completely modular system for organising the functionalities<br />
#* Clear separation of the interface and implementations<br />
#* Intuitive GUI for displaying those modules suitable for different levels of users<br />
# Designs of the modules to be implemented<br />
#* Specifications of all the basic modules<br />
#** Implementing all the modules would be impossible during the summer<br />
#** The whole community including myself would continue working on those implementations after the summer<br />
#** Specifications can include mock-up or illustration to guide the implementation effort<br />
#* Organisation of the modules that show where those modules will fit into<br />
#** How they will be presented to the users<br />
#** Possibly several sets of the organisation for users from different background<br />
#* Implementation of some modules to demonstrate how the new application works<br />
#** Template for the modules to be written<br />
#** At least one sample module for basic tests<br />
<br />
<br />
The new framework shall be constructed such that users can interact with various aspects of a panorama project through modules (plug-ins), each of which provides a single, specific function. The application should provide an intuitive interface for the users to choose what to edit and display with what aspect.<br />
<br />
The modular system is crucial because panorama stitching workflows contain many steps (e.g. select or generate matching control points, optimize image placement, measure and/or correct for camera deficiencies such as vignetting, chromatic aberration, etc.). Moreover, the community comes up with new variations of each step every year, with new features and possibilities suggested every month.<br />
<br />
Also crucial is the way those modules should be organised and presented to the users. Advanced users want to have access to every available feature, while there are many beginners who need access only to the basic tasks and options in a simple and intuitive interface.<br />
<br />
Since it would be impossible to implement the entire application in one summer, this project should focus on laying the foundation upon which the community can continue work on further implementations and improvements. Once the modular framework is set and the specifications of the required tasks are presented, new interface functionality can be implemented independently and in parallel. This is also why a solid, flexible, and well-documented modular system is of such important.<br />
<br />
<br />
= Q&A =<br />
<br />
* Choice of GUI Toolkit: Qt4 is modern and has good support on most of major platforms. wxWidgets is okay, but best of all we have many lines of code that are written for wxWidgets. Scripting languages like Python may have advantages in debugging and module managements. Which one would you use?<br />
** Personally, I want to give Qt4 a try. Though its widgets look weird on Mac sometimes, it has more to offer outside the GUI itself. <small>--[[User:Ippei|Ippei]] 20:05, 17 March 2007 (CET)</small><br />
*** Qt 4.3 is getting the QtScript support as a default module; surely it's gonna be a powerful addition. <small>--[[User:Ippei|Ippei]] 00:59, 21 March 2007 (CET)</small><br />
<br />
<br />
* Possible division of the project: Dividing this project into two parallel tasks that would have little dependancy to each other would enable more work to be done this summer. Would it be possible?<br />
** The project could be divided up into two parts. However, the rough design of the entire application has to be drafted first so that the both work will be done towards the same objective. Based on that: 1. One of the tasks is to implement each module and the structure/interface of the 'Panorama project' data representation; 2. The other task is to implement the plug-in architecture and the main application that uses those plug-ins. Then the modules from task 1. can be wrapped into that plug-in architecture determined by task 2. Of course, collaboration is required. Interfaces needed by the modules created in task 1 has to be present in the plug-in architecture from task 2, and the modules from task 1 have to fit well into the main application created in task 2. <small>--[[User:Ippei|Ippei]] 00:26, 29 March 2007 (CEST)</small><br />
<br />
<br />
<br />
[[Category:Community:Project]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Historical:SoC_2007_project_New_GUI_Framework&diff=8688Historical:SoC 2007 project New GUI Framework2007-03-28T22:30:18Z<p>Ippei: </p>
<hr />
<div>See [[SoC 2007 overview]] for usage hints and a page list.<br />
<br />
= New extensible modular GUI framework =<br />
<br />
The goal of this project is to build a highly extensible GUI framework for Panorama creation, with simple yet intuitive layouts that both beginners and advanced users would be comfortable to use. The application should stay cross-platform, and will interface with the existing back-end panorama creation functionality embodied by [[Hugin]]. This GUI framework would be intended to replace the existing [[Hugin]] GUI when mature.<br />
<br />
<br />
== Deliverables ==<br />
<br />
# Cross-platform Application<br />
#* Acceptable look-and-feel with every platform's standard<br />
#* Minimum amount of platform specific code<br />
# Completely modular system for organising the functionalities<br />
#* Clear separation of the interface and implementations<br />
#* Intuitive GUI for displaying those modules suitable for different levels of users<br />
# Designs of the modules to be implemented<br />
#* Specifications of all the basic modules<br />
#** Implementing all the modules would be impossible during the summer<br />
#** The whole community including myself would continue working on those implementations after the summer<br />
#** Specifications can include mock-up or illustration to guide the implementation effort<br />
#* Organisation of the modules that show where those modules will fit into<br />
#** How they will be presented to the users<br />
#** Possibly several sets of the organisation for users from different background<br />
#* Implementation of some modules to demonstrate how the new application works<br />
#** Template for the modules to be written<br />
#** At least one sample module for basic tests<br />
<br />
<br />
The new framework shall be constructed such that users can interact with various aspects of a panorama project through modules (plug-ins), each of which provides a single, specific function. The application should provide an intuitive interface for the users to choose what to edit and display with what aspect.<br />
<br />
The modular system is crucial because panorama stitching workflows contain many steps (e.g. select or generate matching control points, optimize image placement, measure and/or correct for camera deficiencies such as vignetting, chromatic aberration, etc.). Moreover, the community comes up with new variations of each step every year, with new features and possibilities suggested every month.<br />
<br />
Also crucial is the way those modules should be organised and presented to the users. Advanced users want to have access to every available feature, while there are many beginners who need access only to the basic tasks and options in a simple and intuitive interface.<br />
<br />
Since it would be impossible to implement the entire application in one summer, this project should focus on laying the foundation upon which the community can continue work on further implementations and improvements. Once the modular framework is set and the specifications of the required tasks are presented, new interface functionality can be implemented independently and in parallel. This is also why a solid, flexible, and well-documented modular system is of such important.<br />
<br />
== Rough schedule ==<br />
<br />
* - May 27: Decide the toolkit; specification of the end product with illustration or mock-up<br />
* First half<br />
** - Jun 03 (Week 1): Rough internal design of the system and interface between the components<br />
** - Jun 10 (Week 2): Setting up the environment; installation of the toolkit and build system setup<br />
** - Jul 08 (Week 3-6): Basic framework of the application; module handling, interface with lower level libraries etc.<br />
* Jul 09: Mid-term evaluations begin<br />
* Second half<br />
** - Jul 29 (Week 7-9): Most implementations to be done except the modules<br />
** - Aug 5 (Week 10): Some modules to be written. <br />
** - Aug 12 (Week 11): Finalise the module interface and template, and the list of module specifications for the future development.<br />
** - Aug 19 (Week 12): A week to spare if lucky; but more debugging and more modules would be waiting anyway<br />
* Aug 20: Final evaluations begin<br />
<br />
== Discussion ==<br />
<br />
* Choice of GUI Toolkit: Qt4 is modern and has good support on most of major platforms. wxWidgets is okay, but best of all we have many lines of code that are written for wxWidgets. Scripting languages like Python may have advantages in debugging and module managements.<br />
** Personally, I want to give Qt4 a try. Though its widgets look weird on Mac sometimes, it has more to offer outside the GUI itself. <small>--[[User:Ippei|Ippei]] 20:05, 17 March 2007 (CET)</small><br />
*** Qt 4.3 is getting the QtScript support as a default module; surely it's gonna be a powerful addition. <small>--[[User:Ippei|Ippei]] 00:59, 21 March 2007 (CET)</small><br />
<br />
<br />
* Possible division of the project: Dividing this project into two parallel tasks that would have little dependancy to each other would enable more work to be done this summer.<br />
** The project could be divided up into two parts. However, the rough design of the entire application has to be drafted first so that the both work will be done towards the same objective. Based on that: 1. One of the tasks is to implement each module and the structure/interface of the 'Panorama project' data representation; 2. The other task is to implement the plug-in architecture and the main application that uses those plug-ins. Then the modules from task 1. can be wrapped into that plug-in architecture determined by task 2. Of course, collaboration is required. Interfaces needed by the modules created in task 1 has to be present in the plug-in architecture from task 2, and the modules from task 1 have to fit well into the main application created in task 2. <small>--[[User:Ippei|Ippei]] 00:26, 29 March 2007 (CEST)</small><br />
<br />
== Students planning to apply ==<br />
<br />
* [[User:Ippei|Ippei UKAI]] (Also applying for [[SoC2007_project_Panotools_Architecture|PanoTools reorganisation project]]; happy to give up for other students with more experience with GUI programming.)<br />
* Come on!<br />
<br />
<br />
[[Category:Community:Project]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Historical:SoC_2007_project_New_GUI_Framework&diff=8687Historical:SoC 2007 project New GUI Framework2007-03-28T22:26:10Z<p>Ippei: /* Discussion */ Dividing this project into 2 parallel tasks</p>
<hr />
<div>See [[SoC 2007 overview]] for usage hints and a page list.<br />
<br />
= New extensible modular GUI framework =<br />
<br />
The goal of this project is to build a highly extensible GUI framework for Panorama creation, with simple yet intuitive layouts that both beginners and advanced users would be comfortable to use. The application should stay cross-platform, and will interface with the existing back-end panorama creation functionality embodied by [[Hugin]]. This GUI framework would be intended to replace the existing [[Hugin]] GUI when mature.<br />
<br />
<br />
== Deliverables ==<br />
<br />
# Cross-platform Application<br />
#* Acceptable look-and-feel with every platform's standard<br />
#* Minimum amount of platform specific code<br />
# Completely modular system for organising the functionalities<br />
#* Clear separation of the interface and implementations<br />
#* Intuitive GUI for displaying those modules suitable for different levels of users<br />
# Designs of the modules to be implemented<br />
#* Specifications of all the basic modules<br />
#** Implementing all the modules would be impossible during the summer<br />
#** The whole community including myself would continue working on those implementations after the summer<br />
#** Specifications can include mock-up or illustration to guide the implementation effort<br />
#* Organisation of the modules that show where those modules will fit into<br />
#** How they will be presented to the users<br />
#** Possibly several sets of the organisation for users from different background<br />
#* Implementation of some modules to demonstrate how the new application works<br />
#** Template for the modules to be written<br />
#** At least one sample module for basic tests<br />
<br />
<br />
The new framework shall be constructed such that users can interact with various aspects of a panorama project through modules (plug-ins), each of which provides a single, specific function. The application should provide an intuitive interface for the users to choose what to edit and display with what aspect.<br />
<br />
The modular system is crucial because panorama stitching workflows contain many steps (e.g. select or generate matching control points, optimize image placement, measure and/or correct for camera deficiencies such as vignetting, chromatic aberration, etc.). Moreover, the community comes up with new variations of each step every year, with new features and possibilities suggested every month.<br />
<br />
Also crucial is the way those modules should be organised and presented to the users. Advanced users want to have access to every available feature, while there are many beginners who need access only to the basic tasks and options in a simple and intuitive interface.<br />
<br />
Since it would be impossible to implement the entire application in one summer, this project should focus on laying the foundation upon which the community can continue work on further implementations and improvements. Once the modular framework is set and the specifications of the required tasks are presented, new interface functionality can be implemented independently and in parallel. This is also why a solid, flexible, and well-documented modular system is of such important.<br />
<br />
== Rough schedule ==<br />
<br />
* - May 27: Decide the toolkit; specification of the end product with illustration or mock-up<br />
* First half<br />
** - Jun 03 (Week 1): Rough internal design of the system and interface between the components<br />
** - Jun 10 (Week 2): Setting up the environment; installation of the toolkit and build system setup<br />
** - Jul 08 (Week 3-6): Basic framework of the application; module handling, interface with lower level libraries etc.<br />
* Jul 09: Mid-term evaluations begin<br />
* Second half<br />
** - Jul 29 (Week 7-9): Most implementations to be done except the modules<br />
** - Aug 5 (Week 10): Some modules to be written. <br />
** - Aug 12 (Week 11): Finalise the module interface and template, and the list of module specifications for the future development.<br />
** - Aug 19 (Week 12): A week to spare if lucky; but more debugging and more modules would be waiting anyway<br />
* Aug 20: Final evaluations begin<br />
<br />
== Discussion ==<br />
<br />
* Choice of GUI Toolkit: Qt4 is modern and has good support on most of major platforms. wxWidgets is okay, but best of all we have many lines of code that are written for wxWidgets. Scripting languages like Python may have advantages in debugging and module managements.<br />
** Personally, I want to give Qt4 a try. Though its widgets look weird on Mac sometimes, it has more to offer outside the GUI itself. <small>--[[User:Ippei|Ippei]] 20:05, 17 March 2007 (CET)</small><br />
*** Qt 4.3 is getting the QtScript support as a default module; surely it's gonna be a powerful addition. <small>--[[User:Ippei|Ippei]] 00:59, 21 March 2007 (CET)</small><br />
<br />
<br />
* Possible division of the project: Dividing this project into two parallel tasks that would have little dependancy to each other would enable more work to be done this summer.<br />
** The project could be divided up into two parts. However, the rough design of the entire application has to be drafted first so that the both work will be done towards the same objective. Based on that: 1. One of the tasks is to implement each module and the structure/interface of the 'Panorama project' data representation; 2. The other task is to implement the plug-in architecture and the main application that uses the plug-ins. Then the modules from task 1. can be wrapped in that plug-in architecture determined by task 2. Of course, collaboration is required. Interfaces needed by the modules created in task 1 has to be present in the plug-in architecture from task 2, and the modules from task 1 have to fit well into the main application created in task 2. <small>--[[User:Ippei|Ippei]] 00:26, 29 March 2007 (CEST)</small><br />
<br />
== Students planning to apply ==<br />
<br />
* [[User:Ippei|Ippei UKAI]] (Also applying for [[SoC2007_project_Panotools_Architecture|PanoTools reorganisation project]]; happy to give up for other students with more experience with GUI programming.)<br />
* Come on!<br />
<br />
<br />
[[Category:Community:Project]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Historical:SoC_2007_project_New_GUI_Framework&diff=8271Historical:SoC 2007 project New GUI Framework2007-03-21T00:54:08Z<p>Ippei: </p>
<hr />
<div>= New extensible modular GUI framework =<br />
<br />
The goal of this project is to build a highly extensible GUI framework for Panorama creation, with simple yet intuitive layouts that both beginners and advanced users would be comfortable to use. The application should stay cross-platform.<br />
<br />
<br />
== Deliverables ==<br />
<br />
# Cross-platform Application<br />
#* Acceptable look-and-feel with every platform's standard<br />
#* Minimum amount of platform specific code<br />
# Completely modular system for organising the functionalities<br />
#* Clear separation of the interface and implementations<br />
#* Intuitive GUI for displaying those modules suitable for different levels of users<br />
# Designs of the modules to be implemented<br />
#* Specifications of all the basic modules<br />
#** Implementing all the modules would be impossible during the summer<br />
#** The whole community including myself would continue working on those implementations after the summer<br />
#** Specifications can include mock-up or illustration to guide the implementation effort<br />
#* Organisation of the modules that show where those modules will fit into<br />
#** How they will be presented to the users<br />
#** Possibly several sets of the organisation for users from different background<br />
#* Implementation of some modules to demonstrate how the new application works<br />
#** Template for the modules to be written<br />
#** At least one sample module for basic tests<br />
<br />
<br />
The new framework shall be constructed as such that users can edit/use various aspect of panorama project through modules (plug-ins) each of them providing one specific functions. The application should provide intuitive interface for the users to choose what to edit and display with what aspect.<br />
<br />
The modular system is crucial because the panorama stitching is consist of several steps and the community comes up with new variations of each step every year, and each of them advances with new features every month.<br />
<br />
Also crucial is the way those modules should be organised and presented to the users. Advanced users want to have access to every available feature, while there are many beginners and those who need access to only the basic tasks and options in simple and intuitive interface.<br />
<br />
Since it would be impossible to implement the entire application in one summer, this project should focus on laying the foundation upon which the community can then work on further implementations and improvements. Once the modular framework is set and the specifications of the required tasks are presented, anyone can work on them independently in parallel. This is also why the good modular system is so important.<br />
<br />
<br />
== Rough schedule ==<br />
<br />
* - May 27: Decide the toolkit; specification of the end product with illustration or mock-up<br />
* First half<br />
** - Jun 03 (Week 1): Rough internal design of the system and interface between the components<br />
** - Jun 10 (Week 2): Setting up the environment; installation of the toolkit and build system setup<br />
** - Jul 08 (Week 3-6): Basic framework of the application; module handling, interface with lower level libraries etc.<br />
* Jul 09: Mid-term evaluations begin<br />
* Second half<br />
** - Jul 29 (Week 7-9): Most implementations to be done except the modules<br />
** - Aug 5 (Week 10): Some modules to be written. <br />
** - Aug 12 (Week 11): Finalise the module interface and template, and the list of module specifications for the future development.<br />
** - Aug 19 (Week 12): A week to spare if lucky; but more debugging and more modules would be waiting anyway<br />
* Aug 20: Final evaluations begin<br />
<br />
== Discussion ==<br />
<br />
* Choice of GUI Toolkit: Qt4 is modern and has good support on most of major platforms. wxWidgets is okay, but best of all we have many lines of code that are written for wxWidgets. Scripting languages like Python may have advantages in debugging and module managements.<br />
** Personally, I want to give Qt4 a try. Though its widgets look weird on Mac sometimes, it has more to offer outside the GUI itself. <small>--[[User:Ippei|Ippei]] 20:05, 17 March 2007 (CET)</small><br />
*** Qt 4.3 is getting the QtScript support as a default module; surely it's gonna be a powerful addition. <small>--[[User:Ippei|Ippei]] 00:59, 21 March 2007 (CET)</small><br />
<br />
== Students planning to apply ==<br />
<br />
* [[User:Ippei|Ippei UKAI]] (Also applying for [[SoC2007_project_Panotools_Architecture|PanoTools reorganisation project]]; happy to give up for other students with more experience with GUI programming.)<br />
* Come on!<br />
<br />
<br />
[[Category:Community:Project]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Historical:SoC_2007_project_New_GUI_Framework&diff=8270Historical:SoC 2007 project New GUI Framework2007-03-21T00:14:17Z<p>Ippei: </p>
<hr />
<div>= New extensible modular GUI framework =<br />
<br />
The goal of this project is to build a highly extensible GUI framework for Panorama creation, with simple yet intuitive layouts that both beginners and advanced users would be comfortable to use. The application should stay cross-platform.<br />
<br />
<br />
== Deliverables ==<br />
<br />
# Cross-platform Application<br />
#* Acceptable look-and-feel with every platform's standard<br />
#* Minimum amount of platform specific code<br />
# Completely modular system for organising the functionalities<br />
#* Clear separation of the interface and implementations<br />
#* Intuitive GUI for displaying those modules suitable for different levels of users<br />
# Designs of the modules to be implemented<br />
#* Specifications of all the basic modules<br />
#** Implementing all the modules would be impossible during the summer<br />
#** The whole community including myself would continue working on those implementations after the summer<br />
#** Specifications can include mock-up or illustration to guide the implementation effort<br />
#* Organisation of the modules that show where those modules will fit into<br />
#** How they will be presented to the users<br />
#** Possibly several sets of the organisation for users from different background<br />
#* Implementation of some modules to demonstrate how the new application works<br />
#** Template for the modules to be written<br />
#** At least one sample module for basic tests<br />
<br />
<br />
The new framework shall be constructed as such that users can edit/use various aspect of panorama project through modules (plug-ins) each of them providing one specific functions. The application should provide intuitive interface for the users to choose what to edit and display with what aspect.<br />
<br />
The modular system is crucial because the panorama stitching is consist of several steps and the community comes up with new variations of each step every year, and each of them advances with new features every month.<br />
<br />
Also crucial is the way those modules should be organised and presented to the users. Advanced users want to have access to every available feature, while there are many beginners and those who need access to only the basic tasks and options in simple and intuitive interface.<br />
<br />
Since it would be impossible to implement the entire application in one summer, this project should focus on laying the foundation upon which the community can then work on further implementations and improvements. Once the modular framework is set and the specifications of the required tasks are presented, anyone can work on them independently in parallel. This is also why the good modular system is so important.<br />
<br />
<br />
== Timeline ==<br />
<br />
* - May 27: Decide the toolkit; specification of the end product with illustration or mock-up<br />
* First half<br />
** - Jun 03 (Week 1): Rough internal design of the system and interface between the components<br />
** - Jun 10 (Week 2): Setting up the environment; installation of the toolkit and build system setup<br />
** - Jul 08 (Week 3-6): Basic framework of the application; module handling, interface with lower level libraries etc.<br />
* Jul 09: Mid-term evaluations begin<br />
* Second half<br />
** - Jul 29 (Week 7-9): Most implementations to be done except the modules<br />
** - Aug 5 (Week 10): Some modules to be written. <br />
** - Aug 12 (Week 11): Finalise the module interface and template, and the list of module specifications for the future development.<br />
** - Aug 19 (Week 12): A week to spare if lucky; but more debugging and more modules would be waiting anyway<br />
* Aug 20: Final evaluations begin<br />
<br />
== Discussion ==<br />
<br />
* Choice of GUI Toolkit: Qt4 is modern and has good support on most of major platforms. wxWidgets is okay, but best of all we have many lines of code that are written for wxWidgets. Scripting languages like Python may have advantages in debugging and module managements.<br />
** Personally, I want to give Qt4 a try. Though its widgets look weird on Mac sometimes, it has more to offer outside the GUI itself. <small>--[[User:Ippei|Ippei]] 20:05, 17 March 2007 (CET)</small><br />
*** Qt 4.3 is getting the QtScript support as a default module; surely it's gonna be a powerful addition. <small>--[[User:Ippei|Ippei]] 00:59, 21 March 2007 (CET)</small><br />
<br />
== Students planning to apply ==<br />
<br />
* [[User:Ippei|Ippei UKAI]] (Also applying for [[SoC2007_project_Panotools_Architecture|PanoTools reorganisation project]]; happy to give up for other students with more experience with GUI programming.)<br />
* Come on!<br />
<br />
<br />
[[Category:Community:Project]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Historical:SoC_2007_project_New_GUI_Framework&diff=8269Historical:SoC 2007 project New GUI Framework2007-03-21T00:00:47Z<p>Ippei: /* Timeline */</p>
<hr />
<div>= New extensible modular GUI framework =<br />
<br />
The goal of this project is to build a highly extensible GUI framework for Panorama creation, with simple yet intuitive layouts that both beginners and advanced users would be comfortable to use. The application should stay cross-platform.<br />
<br />
<br />
== Deliverables ==<br />
<br />
# Cross-platform Application<br />
#* Acceptable look-and-feel with every platform's standard<br />
#* Minimum amount of platform specific code<br />
# Completely modular system for organising the functionalities<br />
#* Clear separation of the interface and implementations<br />
#* Intuitive GUI for displaying those modules suitable for different levels of users<br />
# Designs of the modules to be implemented<br />
#* Specifications of all the basic modules<br />
#** Implementing all the modules would be impossible during the summer<br />
#** The whole community including myself would continue working on those implementations after the summer<br />
#** Specifications can include mock-up or illustration to guide the implementation effort<br />
#* Organisation of the modules that show where those modules will fit into<br />
#** How they will be presented to the users<br />
#** Possibly several sets of the organisation for users from different background<br />
#* Implementation of some modules to demonstrate how the new application works<br />
#** Template for the modules to be written<br />
#** At least one sample module for basic tests<br />
<br />
<br />
The new framework shall be constructed as such that users can edit/use various aspect of panorama project through modules (plug-ins) each of them providing one specific functions. The application should provide intuitive interface for the users to choose what to edit and display with what aspect.<br />
<br />
The modular system is crucial because the panorama stitching is consist of several steps and the community comes up with new variations of each step every year, and each of them advances with new features every month.<br />
<br />
Also crucial is the way those modules should be organised and presented to the users. Advanced users want to have access to every available feature, while there are many beginners and those who need access to only the basic tasks and options in simple and intuitive interface.<br />
<br />
Since it would be impossible to implement the entire application in one summer, this project should focus on laying the foundation upon which the community can then work on further implementations and improvements. Once the modular framework is set and the specifications of the required tasks are presented, anyone can work on them independently in parallel. This is also why the good modular system is so important.<br />
<br />
<br />
== Timeline ==<br />
<br />
* - May 27: Decide the toolkit; specification of the end product with illustration or mock-up<br />
* First half<br />
** - Jun 03 (Week 1): Rough internal design of the system and interface between the components<br />
** - Jun 10 (Week 2): Setting up the environment; installation of the toolkit and build system setup<br />
** - Jul 08 (Week 3-6): Basic framework of the application; module handling, interface with lower level libraries etc.<br />
* Jul 09: Mid-term evaluations begin<br />
* Second half<br />
** - Jul 29 (Week 7-9): Most implementations to be done except the modules<br />
** - Aug 5 (Week 10): Some modules to be written. <br />
** - Aug 12 (Week 11): Finalise the module interface and template, and the list of module specifications for the future development.<br />
** - Aug 19 (Week 12): A week to spare if lucky; report to write<br />
* Aug 20: Final evaluations begin<br />
<br />
== Discussion ==<br />
<br />
* Choice of GUI Toolkit: Qt4 is modern and has good support on most of major platforms. wxWidgets is okay, but best of all we have many lines of code that are written for wxWidgets. Scripting languages like Python may have advantages in debugging and module managements.<br />
** Personally, I want to give Qt4 a try. Though its widgets look weird on Mac sometimes, it has more to offer outside the GUI itself. <small>--[[User:Ippei|Ippei]] 20:05, 17 March 2007 (CET)</small><br />
*** Qt 4.3 is getting the QtScript support as a default module; surely it's gonna be a powerful addition. <small>--[[User:Ippei|Ippei]] 00:59, 21 March 2007 (CET)</small><br />
<br />
== Students planning to apply ==<br />
<br />
* [[User:Ippei|Ippei UKAI]] (Also applying for [[SoC2007_project_Panotools_Architecture|PanoTools reorganisation project]]; happy to give up for other students with more experience with GUI programming.)<br />
* Come on!<br />
<br />
<br />
[[Category:Community:Project]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Historical:SoC_2007_project_New_GUI_Framework&diff=8268Historical:SoC 2007 project New GUI Framework2007-03-20T23:59:42Z<p>Ippei: timeline</p>
<hr />
<div>= New extensible modular GUI framework =<br />
<br />
The goal of this project is to build a highly extensible GUI framework for Panorama creation, with simple yet intuitive layouts that both beginners and advanced users would be comfortable to use. The application should stay cross-platform.<br />
<br />
<br />
== Deliverables ==<br />
<br />
# Cross-platform Application<br />
#* Acceptable look-and-feel with every platform's standard<br />
#* Minimum amount of platform specific code<br />
# Completely modular system for organising the functionalities<br />
#* Clear separation of the interface and implementations<br />
#* Intuitive GUI for displaying those modules suitable for different levels of users<br />
# Designs of the modules to be implemented<br />
#* Specifications of all the basic modules<br />
#** Implementing all the modules would be impossible during the summer<br />
#** The whole community including myself would continue working on those implementations after the summer<br />
#** Specifications can include mock-up or illustration to guide the implementation effort<br />
#* Organisation of the modules that show where those modules will fit into<br />
#** How they will be presented to the users<br />
#** Possibly several sets of the organisation for users from different background<br />
#* Implementation of some modules to demonstrate how the new application works<br />
#** Template for the modules to be written<br />
#** At least one sample module for basic tests<br />
<br />
<br />
The new framework shall be constructed as such that users can edit/use various aspect of panorama project through modules (plug-ins) each of them providing one specific functions. The application should provide intuitive interface for the users to choose what to edit and display with what aspect.<br />
<br />
The modular system is crucial because the panorama stitching is consist of several steps and the community comes up with new variations of each step every year, and each of them advances with new features every month.<br />
<br />
Also crucial is the way those modules should be organised and presented to the users. Advanced users want to have access to every available feature, while there are many beginners and those who need access to only the basic tasks and options in simple and intuitive interface.<br />
<br />
Since it would be impossible to implement the entire application in one summer, this project should focus on laying the foundation upon which the community can then work on further implementations and improvements. Once the modular framework is set and the specifications of the required tasks are presented, anyone can work on them independently in parallel. This is also why the good modular system is so important.<br />
<br />
<br />
== Timeline ==<br />
<br />
* - May 27: Decide the toolkit; specification of the end product with illustration or mock-up<br />
* First half<br />
** - Jun 03 (Week 1): Rough internal design of the system and interface between the components<br />
** - Jun 10 (Week 2): Setting up the environment; installation of the toolkit and build system setup<br />
** - Jul 08 (Week 3-6): Basic framework of the application; module handling, interface with lower level libraries etc.<br />
* Jul 09: Mid-term evaluations begin<br />
* Second half<br />
** - Jul 29 (Week 7-9): Most implementations to be done except the modules<br />
** - Aug 5 (Week 10): Some modules to be written. <br />
** - Aug 12 (Week 11): Finalise the module interface and template, and list of module specifications for the future development.<br />
** - Aug 19 (Week 12): A week to spare if lucky; report to write<br />
* Aug 20: Final evaluations begin<br />
<br />
<br />
== Discussion ==<br />
<br />
* Choice of GUI Toolkit: Qt4 is modern and has good support on most of major platforms. wxWidgets is okay, but best of all we have many lines of code that are written for wxWidgets. Scripting languages like Python may have advantages in debugging and module managements.<br />
** Personally, I want to give Qt4 a try. Though its widgets look weird on Mac sometimes, it has more to offer outside the GUI itself. <small>--[[User:Ippei|Ippei]] 20:05, 17 March 2007 (CET)</small><br />
*** Qt 4.3 is getting the QtScript support as a default module; surely it's gonna be a powerful addition. <small>--[[User:Ippei|Ippei]] 00:59, 21 March 2007 (CET)</small><br />
<br />
== Students planning to apply ==<br />
<br />
* [[User:Ippei|Ippei UKAI]] (Also applying for [[SoC2007_project_Panotools_Architecture|PanoTools reorganisation project]]; happy to give up for other students with more experience with GUI programming.)<br />
* Come on!<br />
<br />
<br />
[[Category:Community:Project]]</div>Ippeihttps://wiki.panotools.org/index.php?title=User:Ippei&diff=8249User:Ippei2007-03-19T22:18:51Z<p>Ippei: </p>
<hr />
<div>My name is UKAI Ippei (鵜飼一平). I'm Japanese but currently studying in Scotland.<br />
<br />
<br />
== Academic ==<br />
<br />
* &nbsp;- 2002 Jul.<br />
** Tokai High School; Nagoya, Japan<br />
* 2002 Sep. - 2003 Jun.<br />
** Kwalikum Secondary School; BC, Canada<br />
** Graduated with completion of grade 12<br />
* 2004 Sep. -<br />
** The University of Edinburgh, Scotland<br />
** BSc (Honours) in Computational Linguistics (expected to complete in 2008)<br />
<br />
<br />
== Panorama ==<br />
<br />
I sometimes take Panorama photos. [http://homepage.mac.com/ippei_ukai/dotMac/Panorama/Panorama.html]<br />
<br />
I'm a Mac user, and before start stitching any photos, I had to port hugin to Mac. It took me long, but, hey, it's open source:)<br />
The Mac binary of [[hugin]] is still maintained by me, as well as the Japanese localisation for all platforms (though I use my computer in English).<br />
<br />
<br />
== Programming ==<br />
<br />
My programming probably started with BASIC at school and AppleScript at home while I was in Junior High. I've written a simple 3D engine in QuickBASIC at my school, but didn't run fast enough... AppleScript went as far as AppleScript could go then. My father bought me a Java book around the same time and at least got the concept of OOP, but lost interest quickly mainly because the old MacOS did not have great support for Java. I had fun with a basic JavaScript programming as well [http://homepage.mac.com/ippei_ukai/software/romaji/].<br />
<br />
Finally while I was in Canada, I've properly learnt computing for the first time, and passed the AP Computer Science AB, which was the last season they are using C++ for the course. At the same time, I was reading a lot about Objective-C on then new Mac OS X, and started to familiarise myself with Mac OS X and UNIX.<br />
<br />
Currently I'm most comfortable with Java (esp. 1.5) for writing programs, but C++, Objective-C, bash, and JavaScript are quite intelligible to me for modifying, extending and hacking purposes.<br />
<br />
=== WidgetTerm ===<br />
I have written the WidgetTerm, the terminal emulator Dashboard Widget. [http://widgetterm.sourceforge.net/]<br />
<br />
The idea was there ever since Apple revealed OS X 10.4 for developers. I just implemented it one summer, and it's still downloaded average about 35/day.<br />
<br />
=== HuginOSX ===<br />
The Mac port of hugin took me really long before I finally identified the crucial bug in wxMac 2.5.2 onwards (eventually I fixed it by myself...).<br />
<br />
Once having found flipping back to 2.5.1 solves the problem, I have added many platform specific modifications to make it acceptable for Mac users. Those include the bundle packaging, automatic locale selection (Mac OS X has priority locale selection system like those of web browsers), D&D behaviours, command-line execution window, and file opening AppleEvents (needed to let files opened from other application like Finder the file browser).<br />
<br />
Once OS X port got stable, I have continued to work on hugin time to time for the better GUI layout like the some of the tabs on the main window and preferences panel.<br />
<br />
I have also submitted a lot of bug reports to wxWidgets, and have fixed some of them by myself.<br/><br />
<small>I think their problem is more in the attitudes of releasing stable version while Mac version is still annoyingly buggy. The wxMac development is not so fast that new features are added before the previous bugs are squashed and it never gets completed. I sincerely hope some one takes their SoC project, and improve wxMac quality assurance a bit [http://www.wxwidgets.org/wiki/index.php/Development:_Student_Projects#wxMac_UI_Enhancements]. Me? I would've loved to, but that's only if PanoTools got enough students to fulfil their needs:) Besides, I know no other application than hugin that uses wxWidgets in this extent (20 XRCs and many of them have custom controls with DC painting), and I'm quite sure most other applications are happy with wxMac as it is.</small><br />
<br />
== Google Summer of Code 2007 ==<br />
<br />
I'm applying for:<br />
# [[SoC_2007_project_New_GUI_Framework]]<br />
# [[SoC2007_project_Panotools_Architecture]]<br />
I consider the former more important to the users to be done, but I'm happy to work on either projects. I would love to help you with the other one, in fact. I just want to see the major improvement in the entire tool chain 'cause PanoTools is such a cool opensource technology :)<br />
<br />
All the ideas, discussions and planned schedules are updated on the above pages.<br />
<br />
<br />
== Contact ==<br />
* Homepage: [http://homepage.mac.com/ippei_ukai/ http://homepage.mac.com/ippei_ukai/]<br />
* E-mail: ippei_ukai (at mac.com<br />
** I'm on the "panotools-devel" and "hugin-ptx" mailing list<br />
* SNS<br />
** Facebook: http://ed.facebook.com/profile.php?id=61010523<br />
** mixi.jp: http://mixi.jp/show_friend.pl?id=383839<br />
* IM/VoIP<br />
** MSN, AIM: same e-mail address as above<br />
** Skype: ippei_ukai<br />
** Other: ask me! I use Adium and have accounts for MSN, AIM, Google Talk, Yahoo!, and Yahoo! Japan.</div>Ippeihttps://wiki.panotools.org/index.php?title=Historical:SoC_2007_project_New_GUI_Framework&diff=8248Historical:SoC 2007 project New GUI Framework2007-03-19T21:55:06Z<p>Ippei: + Timeline (to be filled)</p>
<hr />
<div>= New extensible modular GUI framework =<br />
<br />
The goal of this project is to build a highly extensible GUI framework for Panorama creation, with simple yet intuitive layouts that both beginners and advanced users would be comfortable to use. The application should stay cross-platform.<br />
<br />
<br />
== Deliverables ==<br />
<br />
# Cross-platform Application<br />
#* Acceptable look-and-feel with every platform's standard<br />
#* Minimum amount of platform specific code<br />
# Completely modular system for organising the functionalities<br />
#* Clear separation of the interface and implementations<br />
#* Intuitive GUI for displaying those modules suitable for different levels of users<br />
# Designs of the modules to be implemented<br />
#* Specifications of all the basic modules<br />
#** Implementing all the modules would be impossible during the summer<br />
#** The whole community including myself would continue working on those implementations after the summer<br />
#** Specifications can include mock-up or illustration to guide the implementation effort<br />
#* Organisation of the modules that show where those modules will fit into<br />
#** How they will be presented to the users<br />
#** Possibly several sets of the organisation for users from different background<br />
#* Implementation of some modules to demonstrate how the new application works<br />
#** Template for the modules to be written<br />
#** At least one sample module for basic tests<br />
<br />
<br />
The new framework shall be constructed as such that users can edit/use various aspect of panorama project through modules (plug-ins) each of them providing one specific functions. The application should provide intuitive interface for the users to choose what to edit and display with what aspect.<br />
<br />
The modular system is crucial because the panorama stitching is consist of several steps and the community comes up with new variations of each step every year, and each of them advances with new features every month.<br />
<br />
Also crucial is the way those modules should be organised and presented to the users. Advanced users want to have access to every available feature, while there are many beginners and those who need access to only the basic tasks and options in simple and intuitive interface.<br />
<br />
Since it would be impossible to implement the entire application in one summer, this project should focus on laying the foundation upon which the community can then work on further implementations and improvements. Once the modular framework is set and the specifications of the required tasks are presented, anyone can work on them independently in parallel. This is also why the good modular system is so important.<br />
<br />
<br />
== Timeline ==<br />
<br />
* (to be planned)<br />
<br />
<br />
== Discussion ==<br />
<br />
* Choice of GUI Toolkit: QT4 is modern and has good support on most of major platforms. wxWidgets is okay, but best of all we have many lines of code that are written for wxWidgets. Scripting languages like Python may have advantages in debugging and module managements.<br />
** Personally, I want to give QT4 a try. Though its widgets look weird on Mac sometimes, it has more to offer outside the GUI itself. <small>--[[User:Ippei|Ippei]] 20:05, 17 March 2007 (CET)</small><br />
<br />
<br />
== Students planning to apply ==<br />
<br />
* [[User:Ippei|Ippei UKAI]] (Also applying for [[SoC2007_project_Panotools_Architecture|PanoTools reorganisation project]]; happy to give up for other students with more experience with GUI programming.)<br />
* Come on!<br />
<br />
<br />
[[Category:Community:Project]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Historical:SoC2007_project_Panotools_Architecture&diff=8247Historical:SoC2007 project Panotools Architecture2007-03-19T21:54:30Z<p>Ippei: + Timeline (to be filled)</p>
<hr />
<div>= Architectural Overhaul of Panotools =<br />
<br />
Currently PanoTools is rather like a collection of monolithic tools that you would use from the UNIX command-line, and those tools are communicated with input 'scripts' even when linked as a library.<br />
<br />
The goal of this project is to reorganise those processes of PanoTools into smaller chunks of codes with well defined interfaces so that easier employment, extension, and maintenance will be possible in the future.<br />
<br />
<br />
== Deliverables ==<br />
<br />
# PanoTools as a collection of functions that needs no parsing and writing of 'script' to access<br />
#* Common tasks should have well defined function interfaces<br />
#* Independent tasks should have accessible interfaces of their own so that they can be easily replaced independently<br />
# Possible encapsulation of data<br />
#* Well defined data representation with which the functions will be communicated<br />
#* Possibly a structure that can be easily converted to an XML representation<br />
# File I/O functionality<br />
#* Parsing/generating of the 'script' format currently in use<br />
#* Possibly new XML format to be added<br />
# Possible Object-oriented consideration for flexible extension<br />
#* Minimum (ideally no) modification when adding new variation of a task<br />
#* Polymorphismic solution would be beneficial<br />
#* Possibly by providing C++ wrapper<br />
<br />
The new architecture should allow flexible and easy access to the various steps of panorama creation process. Identifying the separate tasks in PanoTools and defining a good interface for each of them will be the most crucial task of this project.<br />
<br />
Also important is the data representation to be used in the interface for those functions instead of the scripts. Those representation may be designed so that new XML format can then be defined upon it to replace the conventional script files.<br />
<br />
In addition, the design decision as to how extensible the library should be has to be decided. Easy to extend/maintain modularity does not need to be as flexible as the polymorphism in the object-orientated programming. One possibility is for the PanoTools to become an implementation simply easier to modify; a new general C++ interfaces can then be written to allow compatible implementations of PanoTools' different steps.<br />
<br />
<br />
== Timeline ==<br />
<br />
* (to be planned)<br />
<br />
<br />
== Discussion ==<br />
<br />
* Choice of license could be asked when writing new portion of codes. The PanoTools' source that has already written will certainly stay under the GPL (well, unless the authors authorise otherwise, but practically they are all under the hood GPL now and forever). However the newly written portion of the code; like the interface definitions, the new file format handling, and the possible C++ wrappers; can stay out of GPL. That would allow more flexible choice for the authors who want to write a compatible library with more relaxed license like LGPL or BSD allowing commercial use of the new implementations.<br />
** I'd say all in LGPL. I want to make sure those interfaces will stay opened. <small>--[[User:Ippei|Ippei]] 03:37, 19 March 2007 (CET)</small><br />
<br />
<br />
== Students planning to apply ==<br />
<br />
* [[User:Ippei|Ippei UKAI]] (Also applying for [[SoC_2007_project_New_GUI_Framework|New GUI project]]; the GUI is in my top priority because I care more about the ordinary users, but I'd be happy if either of those would be taken by someone else so that both will be done this summer.)<br />
* Come on!<br />
<br />
<br />
[[Category:Community:Project]]</div>Ippeihttps://wiki.panotools.org/index.php?title=Historical:SoC_2007_project_New_GUI_Framework&diff=8246Historical:SoC 2007 project New GUI Framework2007-03-19T21:48:37Z<p>Ippei: Deliverables, made clear on the work to be done on modules during this summer</p>
<hr />
<div>= New extensible modular GUI framework =<br />
<br />
The goal of this project is to build a highly extensible GUI framework for Panorama creation, with simple yet intuitive layouts that both beginners and advanced users would be comfortable to use. The application should stay cross-platform.<br />
<br />
<br />
== Deliverables ==<br />
<br />
# Cross-platform Application<br />
#* Acceptable look-and-feel with every platform's standard<br />
#* Minimum amount of platform specific code<br />
# Completely modular system for organising the functionalities<br />
#* Clear separation of the interface and implementations<br />
#* Intuitive GUI for displaying those modules suitable for different levels of users<br />
# Designs of the modules to be implemented<br />
#* Specifications of all the basic modules<br />
#** Implementing all the modules would be impossible during the summer<br />
#** The whole community including myself would continue working on those implementations after the summer<br />
#** Specifications can include mock-up or illustration to guide the implementation effort<br />
#* Organisation of the modules that show where those modules will fit into<br />
#** How they will be presented to the users<br />
#** Possibly several sets of the organisation for users from different background<br />
#* Implementation of some modules to demonstrate how the new application works<br />
#** Template for the modules to be written<br />
#** At least one sample module for basic tests<br />
<br />
<br />
The new framework shall be constructed as such that users can edit/use various aspect of panorama project through modules (plug-ins) each of them providing one specific functions. The application should provide intuitive interface for the users to choose what to edit and display with what aspect.<br />
<br />
The modular system is crucial because the panorama stitching is consist of several steps and the community comes up with new variations of each step every year, and each of them advances with new features every month.<br />
<br />
Also crucial is the way those modules should be organised and presented to the users. Advanced users want to have access to every available feature, while there are many beginners and those who need access to only the basic tasks and options in simple and intuitive interface.<br />
<br />
Since it would be impossible to implement the entire application in one summer, this project should focus on laying the foundation upon which the community can then work on further implementations and improvements. Once the modular framework is set and the specifications of the required tasks are presented, anyone can work on them independently in parallel. This is also why the good modular system is so important.<br />
<br />
<br />
== Discussion ==<br />
<br />
* Choice of GUI Toolkit: QT4 is modern and has good support on most of major platforms. wxWidgets is okay, but best of all we have many lines of code that are written for wxWidgets. Scripting languages like Python may have advantages in debugging and module managements.<br />
** Personally, I want to give QT4 a try. Though its widgets look weird on Mac sometimes, it has more to offer outside the GUI itself. <small>--[[User:Ippei|Ippei]] 20:05, 17 March 2007 (CET)</small><br />
<br />
<br />
== Students planning to apply ==<br />
<br />
* [[User:Ippei|Ippei UKAI]] (Also applying for [[SoC2007_project_Panotools_Architecture|PanoTools reorganisation project]]; happy to give up for other students with more experience with GUI programming.)<br />
<br />
[[Category:Community:Project]]</div>Ippeihttps://wiki.panotools.org/index.php?title=User:Ippei&diff=8211User:Ippei2007-03-19T03:09:04Z<p>Ippei: /* HuginOSX */</p>
<hr />
<div>My name is UKAI Ippei (鵜飼一平). I'm Japanese but currently studying in Scotland.<br />
<br />
<br />
== Academic ==<br />
<br />
* &nbsp;- 2002 Jul.<br />
** Tokai High School; Nagoya, Japan<br />
* 2002 Sep. - 2003 Jun.<br />
** Kwalikum Secondary School; BC, Canada<br />
** Graduated with completion of grade 12<br />
* 2004 Sep. -<br />
** The University of Edinburgh, Scotland<br />
** BSc (Honours) in Computational Linguistics (expected to complete in 2008)<br />
<br />
<br />
== Panorama ==<br />
<br />
I sometimes take Panorama photos. [http://homepage.mac.com/ippei_ukai/dotMac/Panorama/Panorama.html]<br />
<br />
I'm a Mac user, and before start stitching any photos, I had to port hugin to Mac. It took me long, but, hey, it's open source:)<br />
The Mac binary of [[hugin]] is still maintained by me, as well as the Japanese localisation for all platforms (though I use my computer in English).<br />
<br />
<br />
== Programming ==<br />
<br />
My programming probably started with BASIC at school and AppleScript at home while I was in Junior High. I've written a simple 3D engine in QuickBASIC at my school, but didn't run fast enough... AppleScript went as far as AppleScript could go then. My father bought me a Java book around the same time and at least got the concept of OOP, but lost interest quickly mainly because the old MacOS did not have great support for Java. I had fun with a basic JavaScript programming as well [http://homepage.mac.com/ippei_ukai/software/romaji/].<br />
<br />
Finally while I was in Canada, I've properly learnt computing for the first time, and passed the AP Computer Science AB, which was the last season they are using C++ for the course. At the same time, I was reading a lot about Objective-C on then new Mac OS X, and started to familiarise myself with Mac OS X and UNIX.<br />
<br />
Currently I'm most comfortable with Java (esp. 1.5) for writing programs, but C++, Objective-C, bash, and JavaScript are quite intelligible to me for modifying, extending and hacking purposes.<br />
<br />
=== WidgetTerm ===<br />
I have written the WidgetTerm, the terminal emulator Dashboard Widget. [http://widgetterm.sourceforge.net/]<br />
<br />
The idea was there ever since Apple revealed OS X 10.4 for developers. I just implemented it one summer, and it's still downloaded average about 35/day.<br />
<br />
=== HuginOSX ===<br />
The Mac port of hugin took me really long before I finally identified the crucial bug in wxMac 2.5.2 onwards (eventually I fixed it by myself...).<br />
<br />
Once having found flipping back to 2.5.1 solves the problem, I have added many platform specific modifications to make it acceptable for Mac users. Those include the bundle packaging, automatic locale selection (Mac OS X has priority locale selection system like those of web browsers), D&D behaviours, command-line execution window, and file opening AppleEvents (needed to let files opened from other application like Finder the file browser).<br />
<br />
Once OS X port got stable, I have continued to work on hugin time to time for the better GUI layout like the some of the tabs on the main window and preferences panel.<br />
<br />
I have also submitted a lot of bug reports to wxWidgets, and have fixed some of them by myself.<br/><br />
<small>I think their problem is more in the attitudes of releasing stable version while Mac version is still annoyingly buggy. The wxMac development is not so fast that new features are added before the previous bugs are squashed and it never gets completed. I sincerely hope some one takes their SoC project, and improve wxMac quality assurance a bit [http://www.wxwidgets.org/wiki/index.php/Development:_Student_Projects#wxMac_UI_Enhancements]. Me? I would've loved to, but that's only if PanoTools got enough students to fulfil their needs:) Besides, I know no other application than hugin that uses wxWidgets in this extent (20 XRCs and many of them have custom controls with DC painting), and I'm quite sure most other applications are happy with wxMac as it is.</small><br />
<br />
== Google Summer of Code 2007 ==<br />
<br />
I'm applying for:<br />
# [[SoC_2007_project_New_GUI_Framework]]<br />
# [[SoC2007_project_Panotools_Architecture]]<br />
I consider the former more important to the users to be done, but I'm happy to work on either projects. I would love to help you with the other one, in fact. I just want to see the major improvement in the entire tool chain 'cause PanoTools is such a cool opensource technology :)<br />
<br />
<br />
== Contact ==<br />
* Homepage: [http://homepage.mac.com/ippei_ukai/ http://homepage.mac.com/ippei_ukai/]<br />
* E-mail: ippei_ukai (at mac.com<br />
** I'm on the "panotools-devel" and "hugin-ptx" mailing list<br />
* SNS<br />
** Facebook: http://ed.facebook.com/profile.php?id=61010523<br />
** mixi.jp: http://mixi.jp/show_friend.pl?id=383839<br />
* IM/VoIP<br />
** MSN, AIM: same e-mail address as above<br />
** Skype: ippei_ukai<br />
** Other: ask me! I use Adium and have accounts for MSN, AIM, Google Talk, Yahoo!, and Yahoo! Japan.</div>Ippeihttps://wiki.panotools.org/index.php?title=User:Ippei&diff=8210User:Ippei2007-03-19T03:07:13Z<p>Ippei: /* HuginOSX */</p>
<hr />
<div>My name is UKAI Ippei (鵜飼一平). I'm Japanese but currently studying in Scotland.<br />
<br />
<br />
== Academic ==<br />
<br />
* &nbsp;- 2002 Jul.<br />
** Tokai High School; Nagoya, Japan<br />
* 2002 Sep. - 2003 Jun.<br />
** Kwalikum Secondary School; BC, Canada<br />
** Graduated with completion of grade 12<br />
* 2004 Sep. -<br />
** The University of Edinburgh, Scotland<br />
** BSc (Honours) in Computational Linguistics (expected to complete in 2008)<br />
<br />
<br />
== Panorama ==<br />
<br />
I sometimes take Panorama photos. [http://homepage.mac.com/ippei_ukai/dotMac/Panorama/Panorama.html]<br />
<br />
I'm a Mac user, and before start stitching any photos, I had to port hugin to Mac. It took me long, but, hey, it's open source:)<br />
The Mac binary of [[hugin]] is still maintained by me, as well as the Japanese localisation for all platforms (though I use my computer in English).<br />
<br />
<br />
== Programming ==<br />
<br />
My programming probably started with BASIC at school and AppleScript at home while I was in Junior High. I've written a simple 3D engine in QuickBASIC at my school, but didn't run fast enough... AppleScript went as far as AppleScript could go then. My father bought me a Java book around the same time and at least got the concept of OOP, but lost interest quickly mainly because the old MacOS did not have great support for Java. I had fun with a basic JavaScript programming as well [http://homepage.mac.com/ippei_ukai/software/romaji/].<br />
<br />
Finally while I was in Canada, I've properly learnt computing for the first time, and passed the AP Computer Science AB, which was the last season they are using C++ for the course. At the same time, I was reading a lot about Objective-C on then new Mac OS X, and started to familiarise myself with Mac OS X and UNIX.<br />
<br />
Currently I'm most comfortable with Java (esp. 1.5) for writing programs, but C++, Objective-C, bash, and JavaScript are quite intelligible to me for modifying, extending and hacking purposes.<br />
<br />
=== WidgetTerm ===<br />
I have written the WidgetTerm, the terminal emulator Dashboard Widget. [http://widgetterm.sourceforge.net/]<br />
<br />
The idea was there ever since Apple revealed OS X 10.4 for developers. I just implemented it one summer, and it's still downloaded average about 35/day.<br />
<br />
=== HuginOSX ===<br />
The Mac port of hugin took me really long before I finally identified the crucial bug in wxMac 2.5.2 onwards (eventually I fixed it by myself...).<br />
<br />
Once having found flipping back to 2.5.1 solves the problem, I have added many platform specific modifications to make it acceptable for Mac users. Those include the bundle packaging, automatic locale selection (Mac OS X has priority locale selection system like those of web browsers), D&D behaviours, command-line execution window, and file opening AppleEvents (needed to let files opened from other application like Finder the file browser).<br />
<br />
Once OS X port got stable, I have continued to work on hugin time to time for the better GUI layout like the some of the tabs on the main window and preferences panel.<br />
<br />
I have also submitted a lot of bug reports to wxWidgets, and have fixed some of them by myself.<br/><br />
<small>I think their problem is more in the attitudes of releasing stable version while Mac version is still annoyingly buggy. The wxMac development is not so fast that new features are added before the previous bugs are squashed and it never gets completed. I sincerely hope some one takes their SoC project, and improve wxMac quality assurance a bit [http://www.wxwidgets.org/wiki/index.php/Development:_Student_Projects#wxMac_UI_Enhancements]. Me? I would've loved to, but I've got strong tie with hugin and panotools:) Besides, I know no other application than hugin that uses wxWidgets in this extent (20 XRCs and many of them have custom controls with DC painting), and I'm quite sure most other applications are happy with wxMac as it is.</small><br />
<br />
== Google Summer of Code 2007 ==<br />
<br />
I'm applying for:<br />
# [[SoC_2007_project_New_GUI_Framework]]<br />
# [[SoC2007_project_Panotools_Architecture]]<br />
I consider the former more important to the users to be done, but I'm happy to work on either projects. I would love to help you with the other one, in fact. I just want to see the major improvement in the entire tool chain 'cause PanoTools is such a cool opensource technology :)<br />
<br />
<br />
== Contact ==<br />
* Homepage: [http://homepage.mac.com/ippei_ukai/ http://homepage.mac.com/ippei_ukai/]<br />
* E-mail: ippei_ukai (at mac.com<br />
** I'm on the "panotools-devel" and "hugin-ptx" mailing list<br />
* SNS<br />
** Facebook: http://ed.facebook.com/profile.php?id=61010523<br />
** mixi.jp: http://mixi.jp/show_friend.pl?id=383839<br />
* IM/VoIP<br />
** MSN, AIM: same e-mail address as above<br />
** Skype: ippei_ukai<br />
** Other: ask me! I use Adium and have accounts for MSN, AIM, Google Talk, Yahoo!, and Yahoo! Japan.</div>Ippeihttps://wiki.panotools.org/index.php?title=User:Ippei&diff=8209User:Ippei2007-03-19T02:57:30Z<p>Ippei: /* Programming */</p>
<hr />
<div>My name is UKAI Ippei (鵜飼一平). I'm Japanese but currently studying in Scotland.<br />
<br />
<br />
== Academic ==<br />
<br />
* &nbsp;- 2002 Jul.<br />
** Tokai High School; Nagoya, Japan<br />
* 2002 Sep. - 2003 Jun.<br />
** Kwalikum Secondary School; BC, Canada<br />
** Graduated with completion of grade 12<br />
* 2004 Sep. -<br />
** The University of Edinburgh, Scotland<br />
** BSc (Honours) in Computational Linguistics (expected to complete in 2008)<br />
<br />
<br />
== Panorama ==<br />
<br />
I sometimes take Panorama photos. [http://homepage.mac.com/ippei_ukai/dotMac/Panorama/Panorama.html]<br />
<br />
I'm a Mac user, and before start stitching any photos, I had to port hugin to Mac. It took me long, but, hey, it's open source:)<br />
The Mac binary of [[hugin]] is still maintained by me, as well as the Japanese localisation for all platforms (though I use my computer in English).<br />
<br />
<br />
== Programming ==<br />
<br />
My programming probably started with BASIC at school and AppleScript at home while I was in Junior High. I've written a simple 3D engine in QuickBASIC at my school, but didn't run fast enough... AppleScript went as far as AppleScript could go then. My father bought me a Java book around the same time and at least got the concept of OOP, but lost interest quickly mainly because the old MacOS did not have great support for Java. I had fun with a basic JavaScript programming as well [http://homepage.mac.com/ippei_ukai/software/romaji/].<br />
<br />
Finally while I was in Canada, I've properly learnt computing for the first time, and passed the AP Computer Science AB, which was the last season they are using C++ for the course. At the same time, I was reading a lot about Objective-C on then new Mac OS X, and started to familiarise myself with Mac OS X and UNIX.<br />
<br />
Currently I'm most comfortable with Java (esp. 1.5) for writing programs, but C++, Objective-C, bash, and JavaScript are quite intelligible to me for modifying, extending and hacking purposes.<br />
<br />
=== WidgetTerm ===<br />
I have written the WidgetTerm, the terminal emulator Dashboard Widget. [http://widgetterm.sourceforge.net/]<br />
<br />
The idea was there ever since Apple revealed OS X 10.4 for developers. I just implemented it one summer, and it's still downloaded average about 35/day.<br />
<br />
=== HuginOSX ===<br />
The Mac port of hugin took me really long before I finally identified the crucial bug in wxMac 2.5.2 onwards (eventually I fixed it by myself...).<br />
<br />
Once having found flipping back to 2.5.1 solves the problem, I have added many platform specific modification to make it acceptable for Mac platform. Those include the bundle packaging, automatic locale selection (Mac OS X has priority locale selection like those of web browsers; unlike the model used by hugin and many others where only one preference can be selected), and file opening AppleEvents (needed to let files opened from other application like Finder the file browser).<br />
<br />
I have also submitted a lot of bug reports to wxWidgets, and have fixed some of them by myself. I think their problem is more in the attitudes of releasing stable version while Mac version is still annoyingly buggy. The wxMac development is not so fast that new features are added before the previous bugs are squashed and it never gets completed. I sincerely hope some one takes their SoC project, and improve wxMac quality assurance a bit [http://www.wxwidgets.org/wiki/index.php/Development:_Student_Projects#wxMac_UI_Enhancements]. Me? I would've loved to, but I've got strong tie with hugin and panotools:) Besides, I know no other application than hugin that uses wxWidgets in this extent (20 XRCs and many of them have custom controls with DC painting), and I'm quite sure most other applications are happy with wxMac as it is.<br />
<br />
== Google Summer of Code 2007 ==<br />
<br />
I'm applying for:<br />
# [[SoC_2007_project_New_GUI_Framework]]<br />
# [[SoC2007_project_Panotools_Architecture]]<br />
I consider the former more important to the users to be done, but I'm happy to work on either projects. I would love to help you with the other one, in fact. I just want to see the major improvement in the entire tool chain 'cause PanoTools is such a cool opensource technology :)<br />
<br />
<br />
== Contact ==<br />
* Homepage: [http://homepage.mac.com/ippei_ukai/ http://homepage.mac.com/ippei_ukai/]<br />
* E-mail: ippei_ukai (at mac.com<br />
** I'm on the "panotools-devel" and "hugin-ptx" mailing list<br />
* SNS<br />
** Facebook: http://ed.facebook.com/profile.php?id=61010523<br />
** mixi.jp: http://mixi.jp/show_friend.pl?id=383839<br />
* IM/VoIP<br />
** MSN, AIM: same e-mail address as above<br />
** Skype: ippei_ukai<br />
** Other: ask me! I use Adium and have accounts for MSN, AIM, Google Talk, Yahoo!, and Yahoo! Japan.</div>Ippeihttps://wiki.panotools.org/index.php?title=User:Ippei&diff=8208User:Ippei2007-03-19T02:55:53Z<p>Ippei: /* Programming */</p>
<hr />
<div>My name is UKAI Ippei (鵜飼一平). I'm Japanese but currently studying in Scotland.<br />
<br />
<br />
== Academic ==<br />
<br />
* &nbsp;- 2002 Jul.<br />
** Tokai High School; Nagoya, Japan<br />
* 2002 Sep. - 2003 Jun.<br />
** Kwalikum Secondary School; BC, Canada<br />
** Graduated with completion of grade 12<br />
* 2004 Sep. -<br />
** The University of Edinburgh, Scotland<br />
** BSc (Honours) in Computational Linguistics (expected to complete in 2008)<br />
<br />
<br />
== Panorama ==<br />
<br />
I sometimes take Panorama photos. [http://homepage.mac.com/ippei_ukai/dotMac/Panorama/Panorama.html]<br />
<br />
I'm a Mac user, and before start stitching any photos, I had to port hugin to Mac. It took me long, but, hey, it's open source:)<br />
The Mac binary of [[hugin]] is still maintained by me, as well as the Japanese localisation for all platforms (though I use my computer in English).<br />
<br />
<br />
== Programming ==<br />
<br />
My programming probably started with BASIC at school and AppleScript at home while I was in Junior High. I've written a simple 3D engine in QuickBASIC at my school, but didn't run fast enough... AppleScript went as far as AppleScript could go then. My father bought me a Java book around the same time and at least got the concept of OOP, but lost interest quickly mainly because the old MacOS did not have great support for Java. I had fun with a basic JavaScript programming as well [http://homepage.mac.com/ippei_ukai/software/romaji/].<br />
<br />
Finally while I was in Canada, I've properly learnt computing for the first time, and passed the AP Computer Science AB, which was the last season they are using C++ for the course. At the same time, I was reading a lot about Objective-C on then new Mac OS X, and started to familiarise myself with Mac OS X and UNIX.<br />
<br />
Currently I'm most comfortable with Java (esp. 1.5) for writing programs, but C++, Objective-C, bash, and JavaScript are more or less all intelligible. <br />
<br />
=== WidgetTerm ===<br />
I have written the WidgetTerm, the terminal emulator Dashboard Widget. [http://widgetterm.sourceforge.net/]<br />
<br />
The idea was there ever since Apple revealed OS X 10.4 for developers. I just implemented it one summer, and it's still downloaded average about 35/day.<br />
<br />
=== HuginOSX ===<br />
The Mac port of hugin took me really long before I finally identified the crucial bug in wxMac 2.5.2 onwards (eventually I fixed it by myself...).<br />
<br />
Once having found flipping back to 2.5.1 solves the problem, I have added many platform specific modification to make it acceptable for Mac platform. Those include the bundle packaging, automatic locale selection (Mac OS X has priority locale selection like those of web browsers; unlike the model used by hugin and many others where only one preference can be selected), and file opening AppleEvents (needed to let files opened from other application like Finder the file browser).<br />
<br />
I have also submitted a lot of bug reports to wxWidgets, and have fixed some of them by myself. I think their problem is more in the attitudes of releasing stable version while Mac version is still annoyingly buggy. The wxMac development is not so fast that new features are added before the previous bugs are squashed and it never gets completed. I sincerely hope some one takes their SoC project, and improve wxMac quality assurance a bit [http://www.wxwidgets.org/wiki/index.php/Development:_Student_Projects#wxMac_UI_Enhancements]. Me? I would've loved to, but I've got strong tie with hugin and panotools:) Besides, I know no other application than hugin that uses wxWidgets in this extent (20 XRCs and many of them have custom controls with DC painting), and I'm quite sure most other applications are happy with wxMac as it is.<br />
<br />
== Google Summer of Code 2007 ==<br />
<br />
I'm applying for:<br />
# [[SoC_2007_project_New_GUI_Framework]]<br />
# [[SoC2007_project_Panotools_Architecture]]<br />
I consider the former more important to the users to be done, but I'm happy to work on either projects. I would love to help you with the other one, in fact. I just want to see the major improvement in the entire tool chain 'cause PanoTools is such a cool opensource technology :)<br />
<br />
<br />
== Contact ==<br />
* Homepage: [http://homepage.mac.com/ippei_ukai/ http://homepage.mac.com/ippei_ukai/]<br />
* E-mail: ippei_ukai (at mac.com<br />
** I'm on the "panotools-devel" and "hugin-ptx" mailing list<br />
* SNS<br />
** Facebook: http://ed.facebook.com/profile.php?id=61010523<br />
** mixi.jp: http://mixi.jp/show_friend.pl?id=383839<br />
* IM/VoIP<br />
** MSN, AIM: same e-mail address as above<br />
** Skype: ippei_ukai<br />
** Other: ask me! I use Adium and have accounts for MSN, AIM, Google Talk, Yahoo!, and Yahoo! Japan.</div>Ippeihttps://wiki.panotools.org/index.php?title=User:Ippei&diff=8207User:Ippei2007-03-19T02:51:23Z<p>Ippei: /* Programming */</p>
<hr />
<div>My name is UKAI Ippei (鵜飼一平). I'm Japanese but currently studying in Scotland.<br />
<br />
<br />
== Academic ==<br />
<br />
* &nbsp;- 2002 Jul.<br />
** Tokai High School; Nagoya, Japan<br />
* 2002 Sep. - 2003 Jun.<br />
** Kwalikum Secondary School; BC, Canada<br />
** Graduated with completion of grade 12<br />
* 2004 Sep. -<br />
** The University of Edinburgh, Scotland<br />
** BSc (Honours) in Computational Linguistics (expected to complete in 2008)<br />
<br />
<br />
== Panorama ==<br />
<br />
I sometimes take Panorama photos. [http://homepage.mac.com/ippei_ukai/dotMac/Panorama/Panorama.html]<br />
<br />
I'm a Mac user, and before start stitching any photos, I had to port hugin to Mac. It took me long, but, hey, it's open source:)<br />
The Mac binary of [[hugin]] is still maintained by me, as well as the Japanese localisation for all platforms (though I use my computer in English).<br />
<br />
<br />
== Programming ==<br />
<br />
My programming probably started with BASIC at school and AppleScript at home while I was in Junior High. I've written a simple 3D engine in QuickBASIC at my school, but didn't run fast enough... AppleScript went as far as AppleScript could go then. My father bought me a Java book around the same time and at least got the concept of OOP, but lost interest quickly mainly because the old MacOS did not have great support for Java. I had fun with a basic JavaScript programming as well [http://homepage.mac.com/ippei_ukai/software/romaji/].<br />
<br />
Finally while I was in Canada, I've properly learnt computing for the first time, and passed the AP Computer Science AB, which was the last time they are using C++ for that course. At the same time, I was reading a lot about Objective-C on then new Mac OS X, and practise a bit more of Java and UNIX.<br />
<br />
Currently I'm most comfortable with Java for writing programs, but C++, Objective-C, bash, and JavaScript are more or less all intelligible to me. <br />
<br />
=== WidgetTerm ===<br />
I have written the WidgetTerm, the terminal emulator Dashboard Widget. [http://widgetterm.sourceforge.net/]<br />
<br />
The idea was there ever since Apple revealed OS X 10.4 for developers. I just implemented it one summer, and it's still downloaded average about 35/day.<br />
<br />
=== HuginOSX ===<br />
The Mac port of hugin took me really long before I finally identified the crucial bug in wxMac 2.5.2 onwards (eventually I fixed it by myself...).<br />
<br />
Once having found flipping back to 2.5.1 solves the problem, I have added many platform specific modification to make it acceptable for Mac platform. Those include the bundle packaging, automatic locale selection (Mac OS X has priority locale selection like those of web browsers; unlike the model used by hugin and many others where only one preference can be selected), and file opening AppleEvents (needed to let files opened from other application like Finder the file browser).<br />
<br />
I have also submitted a lot of bug reports to wxWidgets, and have fixed some of them by myself. I think their problem is more in the attitudes of releasing stable version while Mac version is still annoyingly buggy. The wxMac development is not so fast that new features are added before the previous bugs are squashed and it never gets completed. I sincerely hope some one takes their SoC project, and improve wxMac quality assurance a bit [http://www.wxwidgets.org/wiki/index.php/Development:_Student_Projects#wxMac_UI_Enhancements]. Me? I would've loved to, but I've got strong tie with hugin and panotools:) Besides, I know no other application than hugin that uses wxWidgets in this extent (20 XRCs and many of them have custom controls with DC painting), and I'm quite sure most other applications are happy with wxMac as it is.<br />
<br />
== Google Summer of Code 2007 ==<br />
<br />
I'm applying for:<br />
# [[SoC_2007_project_New_GUI_Framework]]<br />
# [[SoC2007_project_Panotools_Architecture]]<br />
I consider the former more important to the users to be done, but I'm happy to work on either projects. I would love to help you with the other one, in fact. I just want to see the major improvement in the entire tool chain 'cause PanoTools is such a cool opensource technology :)<br />
<br />
<br />
== Contact ==<br />
* Homepage: [http://homepage.mac.com/ippei_ukai/ http://homepage.mac.com/ippei_ukai/]<br />
* E-mail: ippei_ukai (at mac.com<br />
** I'm on the "panotools-devel" and "hugin-ptx" mailing list<br />
* SNS<br />
** Facebook: http://ed.facebook.com/profile.php?id=61010523<br />
** mixi.jp: http://mixi.jp/show_friend.pl?id=383839<br />
* IM/VoIP<br />
** MSN, AIM: same e-mail address as above<br />
** Skype: ippei_ukai<br />
** Other: ask me! I use Adium and have accounts for MSN, AIM, Google Talk, Yahoo!, and Yahoo! Japan.</div>Ippeihttps://wiki.panotools.org/index.php?title=User:Ippei&diff=8206User:Ippei2007-03-19T02:49:35Z<p>Ippei: + SoC2007</p>
<hr />
<div>My name is UKAI Ippei (鵜飼一平). I'm Japanese but currently studying in Scotland.<br />
<br />
<br />
== Academic ==<br />
<br />
* &nbsp;- 2002 Jul.<br />
** Tokai High School; Nagoya, Japan<br />
* 2002 Sep. - 2003 Jun.<br />
** Kwalikum Secondary School; BC, Canada<br />
** Graduated with completion of grade 12<br />
* 2004 Sep. -<br />
** The University of Edinburgh, Scotland<br />
** BSc (Honours) in Computational Linguistics (expected to complete in 2008)<br />
<br />
<br />
== Panorama ==<br />
<br />
I sometimes take Panorama photos. [http://homepage.mac.com/ippei_ukai/dotMac/Panorama/Panorama.html]<br />
<br />
I'm a Mac user, and before start stitching any photos, I had to port hugin to Mac. It took me long, but, hey, it's open source:)<br />
The Mac binary of [[hugin]] is still maintained by me, as well as the Japanese localisation for all platforms (though I use my computer in English).<br />
<br />
<br />
== Programming ==<br />
<br />
My programming probably started with BASIC at school and AppleScript at home while I was in Junior High. I've written a simple 3D engine in QuickBASIC at my school, but didn't run fast enough... AppleScript went as far as AppleScript could go then. My father bought me a Java book around the same time and at least got the concept of OOP, but lost interest quickly mainly because old Mac OS did not have great support for Java. I had fun with a basic JavaScript programming as well [http://homepage.mac.com/ippei_ukai/software/romaji/].<br />
<br />
Finally while I was in Canada, I've properly learnt computing for the first time, and passed the AP Computer Science AB, which was the last time they are using C++ for that course. At the same time, I was reading a lot about Objective-C on then new Mac OS X, and practise a bit more of Java and UNIX.<br />
<br />
Currently I'm most comfortable with Java for writing programs, but C++, Objective-C, bash, and JavaScript are more or less all intelligible to me. <br />
<br />
=== WidgetTerm ===<br />
I have written the WidgetTerm, the terminal emulator Dashboard Widget. [http://widgetterm.sourceforge.net/]<br />
<br />
The idea was there ever since Apple revealed OS X 10.4 for developers. I just implemented it one summer, and it's still downloaded average about 35/day.<br />
<br />
=== HuginOSX ===<br />
The Mac port of hugin took me really long before I finally identified the crucial bug in wxMac 2.5.2 onwards (eventually I fixed it by myself...).<br />
<br />
Once having found flipping back to 2.5.1 solves the problem, I have added many platform specific modification to make it acceptable for Mac platform. Those include the bundle packaging, automatic locale selection (Mac OS X has priority locale selection like those of web browsers; unlike the model used by hugin and many others where only one preference can be selected), and file opening AppleEvents (needed to let files opened from other application like Finder the file browser).<br />
<br />
I have also submitted a lot of bug reports to wxWidgets, and have fixed some of them by myself. I think their problem is more in the attitudes of releasing stable version while Mac version is still annoyingly buggy. The wxMac development is not so fast that new features are added before the previous bugs are squashed and it never gets completed. I sincerely hope some one takes their SoC project, and improve wxMac quality assurance a bit [http://www.wxwidgets.org/wiki/index.php/Development:_Student_Projects#wxMac_UI_Enhancements]. Me? I would've loved to, but I've got strong tie with hugin and panotools:) Besides, I know no other application than hugin that uses wxWidgets in this extent (20 XRCs and many of them have custom controls with DC painting), and I'm quite sure most other applications are happy with wxMac as it is.<br />
<br />
<br />
== Google Summer of Code 2007 ==<br />
<br />
I'm applying for:<br />
# [[SoC_2007_project_New_GUI_Framework]]<br />
# [[SoC2007_project_Panotools_Architecture]]<br />
I consider the former more important to the users to be done, but I'm happy to work on either projects. I would love to help you with the other one, in fact. I just want to see the major improvement in the entire tool chain 'cause PanoTools is such a cool opensource technology :)<br />
<br />
<br />
== Contact ==<br />
* Homepage: [http://homepage.mac.com/ippei_ukai/ http://homepage.mac.com/ippei_ukai/]<br />
* E-mail: ippei_ukai (at mac.com<br />
** I'm on the "panotools-devel" and "hugin-ptx" mailing list<br />
* SNS<br />
** Facebook: http://ed.facebook.com/profile.php?id=61010523<br />
** mixi.jp: http://mixi.jp/show_friend.pl?id=383839<br />
* IM/VoIP<br />
** MSN, AIM: same e-mail address as above<br />
** Skype: ippei_ukai<br />
** Other: ask me! I use Adium and have accounts for MSN, AIM, Google Talk, Yahoo!, and Yahoo! Japan.</div>Ippeihttps://wiki.panotools.org/index.php?title=Historical:SoC2007_projects&diff=8205Historical:SoC2007 projects2007-03-19T02:42:29Z<p>Ippei: + SoC2007_project_Panotools_Architecture</p>
<hr />
<div>= Introduction =<br />
<br />
This is the work in progress list of possible projects for the [[Google_SoC_2007]]<br />
<br />
Panoramic imaging is a very broad field and touches many different areas of expertise, such as photography, computer vision, art and programming.<br />
There is a thriving community with experience from arts to science that provides many interesting ideas and explores new territory in panoramic imaging. In addition to the mentors, this open community will provide good support and innovative ideas.<br />
<br />
Generally, all development should done with multiple platforms in mind (at least Windows, OSX and Linux/Unix). We have an open communication culture via mailing-lists and mostly develop using C and C++.<br />
<br />
The project below are just suggestions. If you are an interested student and have questions or new ideas, please let us know on the relevant [[Discussion_lists]], for example [https://lists.sourceforge.net/lists/listinfo/panotools-devel panotools-devel].<br />
<br />
= Development style =<br />
<br />
Most of the projects below are related to [[Hugin]], and some also relate to [[Panotools]] or [[tlalli]]. [[Hugin]] is mostly written in C++, and uses the [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA image processing library] to support different types of images (for example, 8bit, 16bit and float (HDR) images). The core functionality is implemented in a platform independent C++ library, which is used by the GUI based on wxWidgets toolkit, and the command line programs ([[nona]], [[fulla]]).<br />
<br />
The development of the projects should take place in a separate branch of the projects CVS (or SVN) repository. Communication with the mentors should usually happen through the appropriate development mailing list. All code should work on the major platforms supported (Linux, OSX, Windows).<br />
<br />
= Possible Projects =<br />
<br />
== Intuitive yet powerful GUI for panorama creation ==<br />
<br />
Goal: Redesign/Reimplement the graphical user interface of the premiere open source panoramic imaging suite, [[Hugin]], to increase ease of use, and provide better access to its unmatched capabilities. Currently the GUI is written using [http://www.wxwidgets.org wxWidgets], which has proven to have slightly different behaviours on different platforms, especially with a complex GUI such as the one of Hugin. This is very annoying and a lot of time has been spent on minor issues such as making the GUI look good on all platforms with different font sizes etc. Therefore two steps are possible:<br />
<br />
# Rewrite the whole GUI using QT (which is very consistent even across platforms, and has (IMHO) a much nicer API). This is a lot more work, and not all functionality of the current GUI can be recreated during the Summer of Code, but it will provide a better platform to build onto in the future. It is also possible to implement the GUI logic in a scripting language such as Ruby or Python. This project should only be tackled by a student who has experience in developing non-trivial GUI applications with QT. The GUI and core panorama code are already separated into different libraries.<br />
#* '''Details to be discussed on [[SoC_2007_project_New_GUI_Framework|the separate page]]'''.<br />
# Extend the existing wxWidgets based GUI.<br />
<br />
General goals for the improved GUI include:<br />
* Providing a simple, yet helpful user interface that suggests or highlights potentially useful next steps.<br />
* Enhancing and integrating manual and automated control point placement and management.<br />
* Improving lens parameter management.<br />
* Providing a batch processing interface.<br />
* Expert mode with access to all features and internals.<br />
<br />
Recommended knowledge or interest in:<br />
* Workflow analysis and UI design skills<br />
* Experience with building cross platform GUI programs (Windows/Linux/OSX), either using wxWidgets or QT<br />
* Creative use of panoramic imaging<br />
<br />
Mentor: Pablo d'Angelo, ?<br />
<br />
License: GPL<br />
<br />
== Automatic feature matching for panoramic images ==<br />
<br />
Goal: Robust matching of features between multiple images using a Hessian-based detector and a suitable descriptor.<br />
A detector and descriptor that takes into account the approximately known distortions will have a much higher matching rate, especially when fisheye or wide angle images are used. <br />
<br />
This project should be split into two projects, which could be done by separate students:<br />
* Implementation of the feature detector and descriptor, and a suitable test suite to verify the correctness of the implementation, further details are being discussed in the separate [[SoC2007_project_Feature_Descriptor]] page. <br />
* Implementation of the matching step, including geometry based outlier pruning (for example using RANSAC) and fast nearest neighbour matching, possibly using a fast algorithm such as cover trees.<br />
<br />
A desired result of the projects would be:<br />
* C or C++ library for the matching step.<br />
* Integration into [[hugin]] and a standalone executable similar to [[Autopano-sift]] or [[Autopano]]<br />
<br />
Required knowledge or interest in:<br />
* signal or image processing background<br />
* C or C++ development skills.<br />
* Matlab or octave<br />
<br />
Possibly useful resources and libraries:<br />
* [http://hunch.net/~jl/projects/cover_tree/cover_tree.html Fast nearest neighbour matching using cover trees]<br />
* [http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ VIGRA computer vision library]<br />
<br />
Mentor: Pablo d'Angelo, Herbert Bay, ?<br />
<br />
License: GPL<br />
<br />
== Interactive panoramic viewer ==<br />
<br />
Goal: The [[Freepv]] panoramic viewer aims to provide a superior viewing experience<br />
for panoramas on all major platforms (Windows, Mac and Linux/Unix), based on<br />
exploiting powerful graphics hardware using OpenGL. Currently it provides<br />
basic but solid viewing capabilities for Quicktime VR, cylindrical, cubic and equi-rectangular panoramas. Plugins for Mozilla/Firefox and a standalone viewer are available. Several important features are still missing from the viewer include:<br />
<br />
* Support for hotspots<br />
* Optimisation for panoramas larger than the Video RAM<br />
* Display of high dynamic range panoramas with adaptive exposure<br />
* Support for reading a SPi-V compatible .xml file, for platforms where SPi-V is not available (Linux/Unix).<br />
* Fallback software renderer<br />
<br />
Required knowledge or interest in:<br />
* OpenGL or other 3D programming experience.<br />
* Creating cool and nice looking interactive experiences.<br />
<br />
Mentor: Pablo d'Angelo, ?<br />
<br />
License: LGPL<br />
<br />
== Anti-ghosting HDR panorama blending and merging algorithm ==<br />
<br />
Goal: Most HDR creation algorithms are designed to work only with very small variations in camera viewing direction. Assume that registration and response curve estimation has already happened. An improved blending method for HDR images together that have not been shot using the traditional exposure stack method. It should avoid ghosting and be insensitive to small misregistrations. <br />
<br />
Interesting research papers:<br />
* [http://www.cs.berkeley.edu/~eden/737_eden_a.pdf Seamless Image Stitching of Scenes with Large Motions and Exposure Differences]<br />
* [http://graphics.cs.ucf.edu/ekhan/project_ghost.htm Ghost Removal in High Dynamic Range Images]<br />
<br />
Required knowledge or interest in:<br />
* Strong background signal/image processing<br />
* Creative mind with ideas beyond the state of the art in computer vision/graphics research.<br />
<br />
Mentor: Pablo d'Angelo, ?<br />
<br />
License: GPL<br />
<br />
== Processing of very large images ==<br />
<br />
Goal: Allow the creation of arbitrary large panoramas.<br />
[http://flickr.com/groups/83823859@N00/discuss/72157594574253488/]<br />
<br />
Currently panotools, as well as hugin/nona require memory to hold the complete input and the remapped output image in memory, which consumes a lot of RAM, especially for spherical panoramas. [http://www.vips.ecs.soton.ac.uk/ VIPS] is a powerful and modular image processing library that supports very large images and multiple processors natively. By porting the core remapping routines of panotools/hugin to VIPS, panoramas of almost arbitrary size can be computed.<br />
<br />
A desired result of the projects would be:<br />
* VIPS operations that support the geometric and photometric (vignetting correction) transformations.<br />
* Standalone command line program that remaps images using these routines.<br />
* Program/script to convert panotools scripts to nip2 projects.<br />
<br />
Required knowledge or interest in:<br />
* C/C++ programming<br />
* image processing<br />
<br />
Mentor: John Cupitt, Pablo d'Angelo<br />
<br />
License: GPL<br />
<br />
<br />
== Architectural Overhaul of Panotools ==<br />
<br />
Panotools is a very monolithic application. The goal of this project is to refactor the functionality of panotools into 4 main parts, as independent of each other as possible.<br />
These parts are (at least):<br />
<br />
* Calculation of position of images (optimization)<br />
* Mapping from input images to output images<br />
* Projection related computations<br />
* Parsing of input scripts/Generation of input scripts<br />
<br />
Were this project successful the functionality of panotools will be available as a collection of routines that be called directly (as opposed to the current model that requires<br />
the creation and parsing of a script). It will make it easier to replace one component of panotools with another one; and it will improve the future maintenance of panotools.<br />
<br />
'''Details to be discussed on [[SoC2007_project_Panotools_Architecture|the separate page]]'''.<br />
<br />
A desired result of the projects would be:<br />
* Set of functions/classes that are available to hugin to perform optimization and remapping of images<br />
* Test suite to verify that the functionality before and after is equivalent.<br />
<br />
Required knowledge or interest in:<br />
* C/C++ programming<br />
* Knowledge of Numerical methods<br />
* Basic knowledge of image processing<br />
<br />
Mentor: D.M. German<br />
<br />
License: GPL<br />
<br />
[[Category:Community:Project]]</div>Ippei