Am Samstag, 31. Januar 2015 um 09:31:09, schrieb T. Modes <[email protected]> > Hi Hugin builder, > > the changes to Hugins code base of the last months results in changes to > the build process.
[snip]
>
> 2.) hugin_executor branch
> This branch contains a lot of changes. They are mainly behind the scene,
> so not directly visible to the end user.
[snip makefile related]
>
> This branch contains also work to unify the multi-threading code in
> different parts of Hugin source code. The dependency on (internal or
> external) zthread has been removed. Hugin is now using OpenMP or
> boost::thread (or c++11 thread). I hope that this unification simplifies
> the further development.
>
> But!! this requires an OpenMP capable compiler. This is currently only
> checked, but not forced. If the compiler is *not* OpenMP capable nona
> and cpfind will run only single-threaded, which will be slower.
> Should we force an OpenMP enabled compiler? Or leave this optional?
> (CMake will report some informations.)
I'd say let it be optional, with warning.
> This branch contains now also some C++11 code. I could therefore reduce
> the dependency on Boost by using C++11 code instead of boost features.
> CMake checks if the compiler is C++11 capable and activate this code
> (From boost then only filesystem, graph and spirit is used).
> If the compiler is not C++11 capable, the boost functions will be used
> instead (this will require filesystem, graph, spirit, thread, date_time,
> iostreams, random, shared_ptr from Boost). I tested with 3 different
> compiler on 2 operating systems and there it works fine. I could not do
> more testing because I don't want to install further systems.
> So this needs some testing on different system if all works.
> CMake should report which code parts are used: C++11 std code or boost code.
> I added also an override switch: Set USE_BOOST=true in CMake will
> override the auto-detection and will always use boost (as in older
> versions).
>
> I hope that I described all good enough. So the question is now: can we
> merge the hugin_executor branch or does it breaks something? Please test
> and report back. Comments are also welcomed.
There are also 67 new po-strings to be translated.
I tested with some of my projects, but have not seen any flaws in my hugin
usage.
I'm very much in favour to merge this branch to master.
> Thomas
Kornel
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/3181706.SUTs6DttDV%40amd64.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: This is a digitally signed message part.
