Request to Merge: LuxRays cmake cleanup

[foobarbarian]

Hi jens,

that is great news - that should make the new cmake configuration work on all supported platforms (Linux, OSX and Win).

Thanks for the effort you put into it. This will save us all a lot of time down the line when we're able to maintain a single
build system instead of the fragmented multitude of different project files maintained across platforms atm.

The differentiation between LuxRays and luxrays is that LuxRays is the whole project that includes all of the samples too
and luxrays is the library that we link against.

In Visual Studio Terms one would be the solution (LuxRays) while the other is the project (luxrays).
I'm not familiar with XCode but I'm sure there is a similiar concept there.

I'm not too happy with the naming convention there and I've expressed my wish to change some of that before but
I did not wish to barge in and change essential parts. I'd rather have the lib named libluxrays or something similar
making the whole thing much clearer. But this is something we can change later on.

LuxRays_BIN_DIR is as far as I know predefined by cmake - I'm only able find documentation for (PROJECT_NAME)_BINARY_DIR
but this is one of the things I've taken over from the old files that worked without understanding where it came from.
But cmake complains about undefined variables if you name it different from the project name (matching case is important).

Sets the name of the project. Additionally this sets the variables <projectName>_BINARY_DIR and <projectName>_SOURCE_DIR to the respective values.

From http://www.cmake.org/cmake/help/cmake-2-8-docs.html

So there is a reason for having different case versions of luxrays vs LuxRays and I hope I did not use them wrong
at the right places but at the same time they shouldn't be changed to all be the same case unless we rename the
library to make the distinction clearer.

cheers
amir

[jensverwiebe]

Right <projectname> determines the <projectname>_BIN_DIR
I was just muddled due we former had set it to bin ( not needed mandatory )
Therefor without a changelog it is always diving into the fog first ;P
Other stuff we can observe and clean in time.

Another thing just to clarify:
I want users build with "macos" repository !!!!
Before i made this, there where the same muddling builds with all kinda mixed libs, that caused trouble as in other OS.
Since we have the ( also user-requested ) way, there is practically no complain about OSX trouble anymore.
The repo assures exactly to have tested library versions. The structure is similar to a /usr/local/ apearance.


In the past cmake was never very smart in getting the right libs and headers if more than one version is present, on OSX it´s for example lib´s in X11 ( if the user installed it ), causing to get priority, thus
being dylibs break build for users without X11 installed.
If this is only to archieve with "NO:DEAULT_PATH, then we use it.
Again: i made all this for a good reason, observing over 3 years now where the possible hurdles are.
When going back to former way, causing again huge maintaining efford and user-support, i loose interest to maintain.
Just hoping the pathdefault work now as expected, had first dejavu todays morning.


Jens

[Dade]

I have merged the cmake_restructure branch with slg2_startup branch. Please, make any further modification to cmake files on slg2_startup branch (i.e. cmake_restructure branch should be considered closed).

The new building system will become mainstream as soon as the SLG2 branch is merged with the default one.

[Ze_Blob]

Hello, i tried to compile Luxrays. Good news it seems to find my boost-1.45 system wide install. However it doesn't find my OpenCL dirs, and i don't know anymore how and where to set the PATH.

I am under Linux and i use OpenCL from the AMD SDK, i have theses lines in /etc/profile, and it was working fine so far:

Code: Select all

export AMDAPPSDKROOT=/usr/local/AMD-APP-SDK-v2.4-lnx64
export AMDAPPSDKSAMPLESROOT=/usr/local/AMD-APP-SDK-v2.4-lnx64
export LD_LIBRARY_PATH=$AMDAPPSDKROOT/lib/x86_64:$LD_LIBRARY_PATH

What is the new policy, should we add some links in /usr/include and /usr/lib toward the AMD dirs ?

[homer]

Hello, i tried to compile Luxrays. Good news it seems to find my boost-1.45 system wide install. However it doesn't find my OpenCL dirs, and i don't know anymore how and where to set the PATH.

I am under Linux and i use OpenCL from the AMD SDK, i have theses lines in /etc/profile, and it was working fine so far:

Code: Select all

export AMDAPPSDKROOT=/usr/local/AMD-APP-SDK-v2.4-lnx64
export AMDAPPSDKSAMPLESROOT=/usr/local/AMD-APP-SDK-v2.4-lnx64
export LD_LIBRARY_PATH=$AMDAPPSDKROOT/lib/x86_64:$LD_LIBRARY_PATH

What is the new policy, should we add some links in /usr/include and /usr/lib toward the AMD dirs ?

Simply find the file "cmake/Packages/FindOpenCL.cmake" and adjust your paths to the OpenCL headers and libs.
This was working for me.

[Ze_Blob]

Thanks, it worked for me too

Curiously luxmark was not built, still not sure why as i don't remember any error message, if i run make again, no luxmark executable is build, only slg2 slg and few others proggies.

[Dade]

Thanks, it worked for me too

Curiously luxmark was not built, still not sure why as i don't remember any error message, if i run make again, no luxmark executable is build, only slg2 slg and few others proggies.

Check: http://src.luxrender.net/luxrays/file/4 ... Dade.cmake

You have to set LuxMark building option to true with:

set(BUILD_LUXMARK TRUE)

[Ze_Blob]

Thanks a lot it did the trick ! Well, i copied directly the line in the CMakeList.txt but next time i will create a user config file, it seems the proper way.

[gazzatav]

As a parallel issue to building could someone check the build instructions on http://www.luxrender.net/wiki/Building_on_Linux#Step_2:_Install_the_required_dependencies.

There are several lines relating to bjam similar to the one below:

./bjam python=3.1 stage

This doesn't work on my system, should the python part be something of the form "--python-buildid=ID"?

Apologies if this is a bit off topic and thanks.

[SATtva]

I think this tutorial is somewhat outdated. IIRC, python specification was moved to the bootstrap stage with later Boost versions, but i cannot recall after which one (1.47 is the canonical version for Lux now).

For official builds i compile Boost as follows (i've omitted static linking parts as you probably don't need it).

Code: Select all

# set the following to the number of CPU cores + 1
MAKEOPTS=7
# your CPU optimizations goes here
CFLAGS="-mtune=generic -mmmx -msse -msse2 -O2 -pipe -mfpmath=sse"

./bootstrap.sh --with-toolset=gcc --without-icu --with-python=/usr/bin/python3.2
./bjam $MAKEOPTS -aq --toolset=gcc cflags="$CFLAGS" cxxflags="$CFLAGS" --layout=system --with-thread --with-program_options --with-filesystem --with-serialization --with-iostreams --with-regex --with-system --with-python threading=multi release install


Note: you need Python 3.2, this is what Blender now uses.