## Request to Merge: LuxRays cmake cleanup

Discussion and help for Compilation problems and platform portability.

Moderator: coordinators

### Re: Request to Merge: LuxRays cmake cleanup

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
foobarbarian

Posts: 36
Joined: Sat Mar 19, 2011 10:21 am

### Re: Request to Merge: LuxRays cmake cleanup

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

jensverwiebe

Posts: 2124
Joined: Wed Apr 02, 2008 4:34 pm

### Re: Request to Merge: LuxRays cmake cleanup

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.

Posts: 4798
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

### Re: Request to Merge: LuxRays cmake cleanup

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-lnx64export AMDAPPSDKSAMPLESROOT=/usr/local/AMD-APP-SDK-v2.4-lnx64export 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 ?
Ze_Blob

Posts: 100
Joined: Mon Feb 01, 2010 10:33 am

### Re: Request to Merge: LuxRays cmake cleanup

Ze_Blob wrote: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-lnx64export AMDAPPSDKSAMPLESROOT=/usr/local/AMD-APP-SDK-v2.4-lnx64export 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 ?

This was working for me.

homer

Posts: 89
Joined: Wed Mar 26, 2008 11:28 pm
Location: Germany

### Re: Request to Merge: LuxRays cmake cleanup

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

Posts: 100
Joined: Mon Feb 01, 2010 10:33 am

### Re: Request to Merge: LuxRays cmake cleanup

Ze_Blob wrote: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.

You have to set LuxMark building option to true with:

set(BUILD_LUXMARK TRUE)

Posts: 4798
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

### Re: Request to Merge: LuxRays cmake cleanup

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

Posts: 100
Joined: Mon Feb 01, 2010 10:33 am

### Re: Request to Merge: LuxRays cmake cleanup

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

Posts: 28
Joined: Wed Jan 20, 2010 6:54 pm
Location: Stockport, UK

### Re: Request to Merge: LuxRays cmake cleanup

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 + 1MAKEOPTS=7# your CPU optimizations goes hereCFLAGS="-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.
Linux builds packager

SATtva

Posts: 5496
Joined: Tue Apr 07, 2009 12:19 pm
Location: from Siberia with love

PreviousNext