[ptx] hugin on OSX

[Ippei UKAI]

On 24 Apr 2006, at 10:56, pablo.dangelo at informatik.uni-ulm.de wrote:

> Daniel M. German <dmgerman at uvic.ca> wrote:
>
>>  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

For the moment, I am compiling libvigra_ext.a from  
MultiThreadOperations.cpp and boost/thread/*.cpp
That works, but if a single patch solves the problem, I should try  
compiling boost again.

>>
>>  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.

Actually all OSX GUI applications are requires to be bundled somehow.  
Even with wxWiidgets, you cannot use the GUI displayed by the mach-o  
binary unless the binary is correctly bundled.

Still, it could be linked dynamically with libraries in /usr/local  
or /sw instead of static link for the distribution that requires no  
installation. One thing to note is that wxWidgets 2.5 is present by  
default on 10.4. I think many applications like Boinc actually  
statically link to newer wxwidgets. Please see http:// 
boinc.berkeley.edu/mac_build.html

As to the localisation, it is actually the strength rather than a  
problem that the multiple files with the same name can exist in  
different paths. OSX's bundle management searches the best file  
according to your language setting. For example, the current HuginOSX  
version puts files named "hugin.mo" and "help.html" and so on into  
each locale.lproj directory accordingly. If I had for example  
Japanese and English in the language list, OSX looks up ja.lproj  
folder first and then en.lproj folder next. As 0.5 has hugin.mo for  
Japanese but not help.html, the system picks hugin.mo in Japanese and  
help files in English.

Ippei

-- 
  ->> 鵜飼 一平  (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>>
   My general MSN, AIM, and E-Mail: ippei_ukai at mac.com
   Homepage:  http://homepage.mac.com/ippei_ukai/