OSX-renewing buildprocess -out-of-the-box-compile -

[jensverwiebe]

I put these instructions to the wiki now.

Jens

[jensverwiebe]

Hi
I just made some changes to the OSX build system for taking Xcode 4.1 capabilities into account.

- we don´t build liblux.a (staticlib) anymore ( shorter compilation time )
- we build liblux.dylib straight from all sources and dependencies ( not against static core sub-lib anymore )
- this let us do LTO across the whole object files thus better optimize at link time.
- all binaries are now dependent on liblux.dylib
- for pylux as a consequence you now copy both pylux.so and liblux.dylib to "luxrender" add-on ! They are both together still smaller than the static pylux before !

- i upped the minimum cake requirement to 2.8-3 for have important bug fixes and additional capabilities available ( per target settings )

New cmake OSX-options:

########## OSX_OPTIONS ###########
option(OSX_OPTION_PYLUX "Build a blender compatible pylux" ON)
option(OSX_OPTION_CLANG "Build with CLANG compiler ( XCODE4 )" ON) --> good with Xcode 4 or higher
option(OSX_OPTION_LTO "Build with LINK TIME OPTIMISATION ( MAY BREAK NON-SSE4 MACS COMPATIBILITY )" ON) --> performs LTO on all binaries except LuxRender ( due Qt )
option(OSX_OPTION_XCODE_4.1 "HAVE XCODE 4.1 ( LION )" OFF) --> performs all binaries with clang
option(OSX_OPTION_UNIVERSAL "Force compile universal" OFF)
option(OSX_OPTION_LION "BUILD for OSX 10.7, else 10.6 would be deployment-target" OFF)

Please test and tell me if we could do things even better. I may change the defaults later perhaps to guarantee flawless operation with default values ( must test on various Macs still )
Perhaps we could do a compile matrix which compiler and settings can be used for which binary.

Note for the situation now:

- With XCode 4.1 on Lion you can build all with CLANG, LuxRender must not have LTO and Pylux not STRIP, all other can have this. !!! the LuxRender no LTO and PYLUX no STRIP is adjusted automatically !!!
- you could also compile all with llvm-gcc + LTO
- both 10.6/7 sdk work

- With XCode4.0.x you can only compile the lib(s) with CLANG, other with llvm-gcc, but LuxRender must use gcc-4.2. Same STRIP conditions as above.

If something is still not adjusted right, you can always dis/enable options in Xcode, just lemme know then and i will take care of it.



Jens

[jensverwiebe]

Hi
Just a little update:

1.
I made parallel compiling more robust. Now everytime the corelib will be compiled first due made it an implicit dependency
for all other targets. Did not worked reliable before in all cases. Thus i could remove the dummy corelib in "macos" which
could lead to muddle at linktime when api-changes in core where happening.

2.
I removed the "option(OSX_OPTION_XCODE_4.1 "HAVE XCODE 4.1 ( LION )" OFF)" and introduced an automatic test
for XCODE version, so if XCODE >= 4.1 --> XCODE 4.1+ features are used.

Also some more hostinformation is provided, perhaps will use this later for more autoconfiguration.

Example how cmake configure looks at the bottom now:

Code: Select all

################ GENERATED XCODE PROJECT INFORMATION ################

BUILD_MASHINE_SYS : OSX_10.7(Lion)
OSX_DEPLOYMENT_TARGET : 10.6
CMAKE_XCODE_ATTRIBUTE_ARCHS ( cmake 2.8 or higher method ): i386 x86_64
OSX SDK SETTING : /Developer/SDKs/MacOSX10.6.sdk
OSX_DEPENDENCY_ROOT_PATH : /Volumes/Daten1TB/LuxRender_devel/lux_contribute_branch/../macos
BUILD_CONFIGURATION_TYPE : Release
OSX_BUILD_WITH_CLANG : ON
OSX_USE_LTO : ON
DETECTED_XCODE_VERSION : 4.2.1
USE_XCODE_4.1_FEATURES : ON
PYLUX CONFIGURED FOR BLENDER 2.6 USE
ALWAYS_BUILD_UNIVERSAL : OFF

#####################################################################

Lemme know if this is fine.

Jens

[pciccone]

Thank Jens.

[jensverwiebe]

Heh, i forgot a change in refactor

The referencing happened to corelib before the ID was changed, so all binaries
happened to reference to the absolute buildpath of corelib instead of "@loader_path/liblux.dylib".

Nobody noticed due it only takes effect when distributing these binaries

Fixed in hg now.

Jens

[jensverwiebe]

I´ve seen some builders have still probs to determine optimal buildoptions, so i added some options to get better control:

- a sse availability check that checks your available sse options higher than ssse3 (default SSSE3, note: these are set in cmake add_definitions )
- an option thats uses the highest available sse at compiletime ( note: these are set as XCODE_ATTRIBUTE )
- a check for MacModel shows your machine you are on
- added an compatibility verification if the settings are "safe"

Roundup:

- If you build with default options, you get an "all-intel-mac" compatible build. This is best for distributing builds !!!
( Note: -O3 -ftree-vectorize -msse -msse2 -msse3 -mssse3 -fvariable-expansion-in-unroller -Wall -DHAVE_PTHREAD_H, no need to set them in XCODE, always used in release builds )

- If you check OSX_OPTION_USE_MAX_SSE, you use fastest optimizations available on your buildmashine
- Additionally you can check OSX_OPTION_LTO to use linktime optimizations , kept seperately, cause it can give trouble on older XCode versions.( tested fine on XCode 4.1 and 4.2 )
- the last "COMPATIBILITY INFO : .."-line assures you to have an distribution-safe build or an build-machine-optimized build.

Example:

Code: Select all

################ GENERATED XCODE PROJECT INFORMATION ################

BUILD_MACHINE_SYS : OSX_10.7(Lion)
BUILD_MACHINE_MODEL : MacPro5,1
BUILD_MACHINE_MAX_SSE_AVAILABLE : SSE_4.2

OSX_DEPLOYMENT_TARGET : 10.7
OSX SDK SETTING : /Developer/SDKs/MacOSX10.7.sdk
OSX_DEPENDENCY_ROOT_PATH : /Volumes/Daten1TB/LuxRender_devel/lux_mainbranch_work/../macos
OSX_BUILD_WITH_CLANG : ON
OSX_USE_LTO : ON

DETECTED_XCODE_VERSION : 4.2.1
USE_XCODE_4.1_FEATURES : ON
VALID_BUILD_ARCHTECTURES : i386 x86_64

BUILD_CONFIGURATION_TYPE : Release
PYLUX CONFIGURED FOR BLENDER 2.6 USE
USE_BEST_SSE_OPTIMIZATION : ON
ALWAYS_BUILD_UNIVERSAL : OFF
COMPATIBILITY INFO : BUILD SETTINGS DO NOT SUPPORT ALL INTEL-MACS

#####################################################################

Cheers....Jens

[jensverwiebe]

Hi folks

I just migrated to XCode 4.3 which made some rework neccessary and while on it made builds again more failsafe.

- XCode 4.2 and lower:
Just configure in cmake_gui and generate, then just select build-type in XCode for"dynamic_build" target
and compile.( default is debug )


- XCode 4.3 and higher:
Just configure in cmake_gui and generate, then just select build-type in XCode for"dynamic_build" target
and compile.( default is debug )



If you deleted all old developer-stuff ( i did to avoid confusion and trouble ) you have to reinstall qt and eventually have to set your xcode-select path.
Check with xcode-select -print-path ( will show /developer ) and change with xcode-select -switch <xcode_path> to "/Applications/Xcode.app/Contents/Developer"
("/Applications/Xcode.app" would work too, but i prefered first choice due more descripting )
Don´t forget to again place cl.hpp in the new sdk´s.


Important: the last official cmake-2.8-7 does not know XCode 4.3 and will fail to configure.
I provide here a patched version of OSX Lion 64bit cmake-2.8-7 that works with XCode 4.3, until
cmake guy will do an update: http://www.jensverwiebe.de/LuxRender/Lu ... 02.8-7.zip
If you need another architecture, get cmake sources and patch cmGlobalXCodeGenerator.cxx with lines :

Code: Select all

> #include "sys/stat.h"
138,139c138,150
<   parser.ParseFile
<     ("/Developer/Applications/Xcode.app/Contents/version.plist");
---
>   struct stat st;
>   if(stat("Developer/Applications/Xcode.app/Contents/version.plist", &st) != 0)
>   {
>       parser.ParseFile
>       ("/Applications/Xcode.app/Contents/version.plist"); // XCODE 4.3 location
>   }
>   else
>   {
>       parser.ParseFile
>       ("Developer/Applications/Xcode.app/Contents/version.plist"); // XCODE < 4.3 location
>   }


and build with: ./bootstrap --prefix=<where-you-want-it> --qt-gui ; make -j8; make install

My first impression of XCode 4.3 is far better stability and slighly faster builds due newer clang-compiler version.

Cheerio...Jens

[Eros]

I ran into an issue with OpenCL, as I also removed the /Developer folder I believe the framework is now located

/System/Library/Frameworks/OpenCL.framework

So i downloaded the cl.hpp v1.1 header and put it in /System/Library/Frameworks/OpenCL.framework/Versions/Current/Headers

However xcode gives me an error saying it cannot find the header...? Has it changed versions to 1.2? or maybe something strange happening?

Also is it normal that LD memory usage jumps up to about 5.6GB when i try to build? (still building atm)

+Update+
My builds fail with a script running error which seems to show xcode having issues making liblux.dylib

[jensverwiebe]

Eros: indeed, forgot to mention that the sdk´s are a new install and you have again to copy cl.hpp
best in both openCL frameworks/headers.
The location is not where you put them ( would be valid for no-sdk builds only ), but:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk and
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk

Jens

[jensverwiebe]

Update

- reenabled proper compiling with cmake/unix-makefiles generator

- made the boost 1.47 transition for OSX now. Commit is in repo.

- was able to compile with -fvisibility=hidden -fvisibility-inlines-hidden and reuse windows visibility mechanism to export
needed symbols

- change is not very intrusive
- no more cycles conflicts
- 20% faster loadtimes due optimised lookup tables
- 10% faster rendering
- 20% smaller binaries
- btw: boost 1.47 compiles flawless, no more patch needed for python 3.x

Jens