[ptx] hugin on OSX

[pablo.dangelo at informatik.uni-ulm.de]

Daniel M. German <dmgerman at uvic.ca> wrote:

> I was finally able to compile all the sources under 10.3 and I want to
> add my comments to ippei's (I can't link it yet, but that seems to be
> a Makefile issue, I am looking at Audacity to update the autoconf
> process).
>
>  Ippei> 2. boost
>  Ippei> It doesn't compile. I've given up looong time ago. Until hugin 0.5
>  Ippei> we only used its header, and only you had to do was to copy the
>  Ippei> header files and comment out its gcc version check. Now with the CVS
>  Ippei> version, you need at least boost-thread to be compiled. I just got
>  Ippei> away with it compiling the relevant sources into vigra-impex.a itself
>  Ippei> (just added boost-thread files into the XCode project's source list
> ;).
>
> With the current CVS version of hugin, it still requires some boost
> sources. One problem with that there is one #ifndef that messes the
> compilation (related to boost threading). Boost will complain:
>
>
>          /sw/include/boost/config/requires_threads.hpp:47:5: #error
>          "Compiler threading support is not turned on. Please set the
>          correct command line options for threading: -pthread (Linux),
>          -pthreads (Solaris) or -mthreads (Mingw32)"
>
> I found a work-around:
>
>          http://lists.boost.org/boost-users/2004/09/7998.php
>
> It is just a matter of modifying: /sw/include/boost/config/platform/macos.hpp
>
>
>  Ippei> However, it might help the development process if commandline
>  Ippei> compilation can compile HuginOSX against the local system just like
>  Ippei> in the other platforms. (At least saves me from updating the XCode
>  Ippei> project file every time a new file is created on CVS.)
>
> This is my goal, although I seem to be very slow understanding the
> intricacies of OS X.

One small thing: I think the current OSX build requires to be installed in a
bundle? I'm not sure if the MacGetPathTOBundledResourceFile(), and
MacGetPathTOBundledExecutableFile() work on a unix-like install on OSX at all.
I'm not sure if I understand why this is required, and what would break if it is
removed.
Also, it seems that it might lead to problems if multiple files with the same
name (in different pathes that contain a similar locale code) are inside the
bundle?

Maybe there should be a define (eg. HUGIN_OSX_BUNDLE) for compilation of a
bundled hugin. Then the #ifdef __WXMAC__ around the above mentioned functions
should be replaced by #ifdef HUGIN_OSX_BUNDLE.

I might get access to a Intel Mac in the future. My preference would then be the
following workflow (for compiling)

1. install dependencies using darwin ports (as mentioned by JD, it even ships
boost (don't know if it works with xcode 1.5 tough) ).
2. make sure that panotools and hugin compile and install.
3. submit port files to darwin ports.

ciao
  Pablo

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.