LuxCoreRender Forums

Posted: **Fri Jan 12, 2018 12:27 am**

acasta69 wrote: Thu Jan 11, 2018 11:06 am I think i remember that also all dependencies must be built with the same compiler version...
Once I tried to use VS2015 for the old 1.7dev, but it did not work with existing deps...

Oh well that could be a pain. I've got a bit of a mess right now as I was just trying to get it to compile in the first place, so let me play around with it tonight / tomorrow and let you know what runs and what doesn't. I was just excited that it compiled without errors.

Related question, I feel like I need to have 10 different versions of lux (or 10 different copies of Blender) installed on my computer to test things. Production version, confirmed working alpha version, test version a, test version b, etc. How do you guys manage all these? Surely you don't overwrite your working copy of your addon every time you need to test something, do you?

Posted: **Fri Jan 12, 2018 8:15 am**

I have a symlink in scripts/addons/ that points to the git clone of BlendLuxCore, so when I do a git pull and restart Blender, the addon is updated.
When I tested the alpha1 release, I renamed the folder to avoid a collision.
And yes, I have a bunch of Blender versions (taken from the zip download, not the installer).

Posted: **Fri Jan 12, 2018 11:16 pm**

B.Y.O.B. wrote: Fri Jan 12, 2018 8:15 am I have a symlink in scripts/addons/ that points to the git clone of BlendLuxCore, so when I do a git pull and restart Blender, the addon is updated.

For updates that makes sense, but still doesn't give the ability to switch back and forth between versions short of clone to revision... ah, hmm. Maybe I actually want to make a local repository of my compiled binaries and then just sync to whatever revision I want to work with at the moment...

B.Y.O.B. wrote: Fri Jan 12, 2018 8:15 am When I tested the alpha1 release, I renamed the folder to avoid a collision.

That's what I've been doing, just seems so inefficient to switch back and forth copying files and renaming the folders all the time.

-------------------

Ok, on to the actual subject of compiling, I've run in to another issue. While VS2015 and VS2017 both compile without any errors or warnings, and both create quite a few files in the WindowsCompile/Build_CMake/ directory (~694 of them, including important ones that I recognize like pyluxcore.pyd, luxcoreconsole.exe, and luxcoreui.exe... hopefully that's what it's supposed to look like after compiling?)... there are a few really important ones that are missing from both builds. Namely embree.dll, tbb.dll, and OpenImageIO.dll.

Any ideas why these three dll's wouldn't have been created in spite of no errors in the compile?

Posted: **Fri Jan 12, 2018 11:35 pm**

gecko wrote: Fri Jan 12, 2018 11:16 pm Ok, on to the actual subject of compiling, I've run in to another issue. While VS2015 and VS2017 both compile without any errors or warnings, and both create quite a few files in the WindowsCompile/Build_CMake/ directory (~694 of them, including important ones that I recognize like pyluxcore.pyd, luxcoreconsole.exe, and luxcoreui.exe... hopefully that's what it's supposed to look like after compiling?)... there are a few really important ones that are missing from both builds. Namely embree.dll, tbb.dll, and OpenImageIO.dll.

Any ideas why these three dll's wouldn't have been created in spite of no errors in the compile?

They are not created, they are part of the pre-compiled libraries available at: https://github.com/LuxCoreRender/WindowsCompileDeps

They are here https://github.com/LuxCoreRender/Window ... elease/lib and you can just copy them around. They are required to run the compiled .exe or use pyluxcore.pyd

Posted: **Fri Jan 12, 2018 11:36 pm**

As Dade said.
You can also see where they are in collect_compiled_binaries.bat: https://github.com/LuxCoreRender/Window ... naries.bat

Posted: **Sat Jan 13, 2018 1:33 am**

Got it, thanks. I used get_binaries and thought I was supposed to point it to the CMake_Build directory (so didn't point it to a high enough root to find the dependencies). Assumed dependencies were already in the BlendLuxCore repository. Anyway. I'm learning. Slowly

Ok, with that out of the way I've confirmed that compiling LuxCore in VS2017 and using the existing dependencies from the repository (compiled in VS2013) works just fine. I got a brand new clean copy up and running in Blender. And I've got to say, viewport rendering with Lux is kind of cool!

Posted: **Sat Jan 13, 2018 12:10 pm**

gecko wrote: Sat Jan 13, 2018 1:33 am Ok, with that out of the way I've confirmed that compiling LuxCore in VS2017 and using the existing dependencies from the repository (compiled in VS2013) works just fine.

I have done some tests with VS2015 and it is not working. I think it is the same with VS2017.
Gecko, you have installed also VS2013, right? Have you updated VS version also in cmake-build-x64.bat script? Otherwise, even using the VS2017 command tools command prompt, cmake will find the existing VS2013 installation.
At least, that's what happening here:

Code: Select all

F:\Ale\Devel\LuxCoreRender\WindowsCompile>cmake-build-x64.bat
Finding if CMake is installed...
CMake found at "c:\Program Files (x86)\cmake-3.2.2-win32-x86\bin\cmake.exe  "
We are using CMake version: 3
LIB_DIR: F:\Ale\Devel\LuxCoreRender\WindowsCompileDeps\x64\Release\lib
Sottodirectory o file Build_CMake già esistente.
Sottodirectory o file F:\Ale\Devel\LuxCoreRender\WindowsCompile\Build_CMake\LuxCore già esistente.
-- CMAKE VERSION DETECTED 3.2.2
-- The C compiler identification is MSVC 18.0.40629.0
-- The CXX compiler identification is MSVC 18.0.40629.0
-- Check for working C compiler using: Visual Studio 12 2013
-- Check for working C compiler using: Visual Studio 12 2013 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 12 2013
-- Check for working CXX compiler using: Visual Studio 12 2013 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Building mode: Release
-- MSVC
-- Version 12 (2013)
-- Using default WIN32 Configuration settings
-- Building for target x86
...

Look at the lines after "CMAKE VERSION DETECTED": the identified compiler is the one from VS2013, even if I'm using a VS2015 command prompt. Then the build process completes successfully.
When I update things in cmake script, this is the result:

Code: Select all

F:\Ale\Devel\LuxCoreRender\WindowsCompile>cmake-build-x64.bat
Finding if CMake is installed...
CMake found at "c:\Program Files (x86)\cmake-3.2.2-win32-x86\bin\cmake.exe  "
We are using CMake version: 3
LIB_DIR: F:\Ale\Devel\LuxCoreRender\WindowsCompileDeps\x64\Release\lib
-- CMAKE VERSION DETECTED 3.2.2
-- The C compiler identification is MSVC 19.0.24215.1
-- The CXX compiler identification is MSVC 19.0.24215.1
-- Check for working C compiler using: Visual Studio 14 2015
-- Check for working C compiler using: Visual Studio 14 2015 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 14 2015
-- Check for working CXX compiler using: Visual Studio 14 2015 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Building mode: Release
-- MSVC
-- Using default WIN32 Configuration settings
-- Building for target x86
-- Lux build environment variables found
--   LUX_WINDOWS_BUILD_ROOT = F:\Ale\Devel\LuxCoreRender\WindowsCompile
--   INCLUDE_DIR = F:\Ale\Devel\LuxCoreRender\WindowsCompileDeps\include
--   LIB_DIR = F:\Ale\Devel\LuxCoreRender\WindowsCompileDeps\x64\Release\lib
-- Looking for include file pthread.h
-- Looking for include file pthread.h - not found
-- Found Threads: TRUE
-- Found OpenImageIO: F:/Ale/Devel/LuxCoreRender/WindowsCompileDeps/x64/Release/lib/OpenImageIO.lib
-- Found OPENEXR: F:/Ale/Devel/LuxCoreRender/WindowsCompileDeps/x64/Release/lib/Iex.lib;F:/Ale/Devel/LuxCoreRender/WindowsCompileDeps/x64/Release/lib/IlmImf.lib;F:/Ale/Devel/LuxCoreRender/WindowsCompileDeps/x64/Release/lib/Half.lib;F:/Ale/Devel/LuxCoreRender/WindowsCompileDeps/x64/Release/lib/Imath.lib;F:/Ale/Devel/LuxCoreRender/WindowsCompileDeps/x64/Release/lib/IlmThread.lib
-- Found TIFF: F:/Ale/Devel/LuxCoreRender/WindowsCompileDeps/x64/Release/lib/libtiff.lib (found version "4.0.3")
-- Found JPEG: F:/Ale/Devel/LuxCoreRender/WindowsCompileDeps/x64/Release/lib/jpeg.lib
-- Found ZLIB: F:/Ale/Devel/LuxCoreRender/WindowsCompileDeps/x64/Release/lib/zlib1.lib (found version "1.2.8")
-- Found PNG: F:/Ale/Devel/LuxCoreRender/WindowsCompileDeps/x64/Release/lib/libpng.lib (found version "1.6.12")
-- Found PythonLibs: F:/Ale/Devel/LuxCoreRender/WindowsCompileDeps/x64/Release/lib (found version "3.5.1")
-- Could NOT find Boost
-- Could NOT find Boost
-- Found OpenGL: opengl32
-- Found OPENCL: C:/Program Files (x86)/AMD APP SDK/2.9-1/lib/x86_64/OpenCL.lib 
-- Try OpenMP C flag = [/openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Success
-- Try OpenMP CXX flag = [/openmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Success
-- Found OpenMP: /openmp
-- OpenMP found - compiling with
-- Found BISON: F:\Ale\Devel\LuxCoreRender\WindowsCompile/support/bin/win_bison.exe (found version "2.7")
-- Found FLEX: F:\Ale\Devel\LuxCoreRender\WindowsCompile/support/bin/win_flex.exe (found version "2.5.37")
CMake Error at CMakeLists.txt:79 (MESSAGE):
  --> Could not locate required Boost files - Please check
  F:\Ale\Devel\LuxCoreRender\WindowsCompileDeps\include/Boost


-- Configuring incomplete, errors occurred!
See also "F:/Ale/Devel/LuxCoreRender/WindowsCompile/Build_CMake/LuxCore/CMakeFiles/CMakeOutput.log".
See also "F:/Ale/Devel/LuxCoreRender/WindowsCompile/Build_CMake/LuxCore/CMakeFiles/CMakeError.log".
--- FATAL ERROR RUNNING CMAKE ---

The identified compiler is now from VS2015, but then Boost libraries are not found because of wrong compiler version (they report compiler version in their filenames).
Finding them can be forced by changing their filenames, then the building process goes on, but a lot of "unresolved external symbol" errors are generated at link time.

So I think we really need to build deps with the compiler we want to use.

Posted: **Sat Jan 13, 2018 12:18 pm**

acasta69 wrote: Sat Jan 13, 2018 12:10 pm So I think we really need to build deps with the compiler we want to use.

Thanks for the investigation, I guess we go back to the original plan of releasing the v2.0 with VS2013 and than update the dependencies (newer boost, newer openimageio, etc.) and the compiler (I guess to VS2017). So we take two birds with one stone. OK

Posted: **Sat Jan 13, 2018 3:32 pm**

Dade wrote: Sat Jan 13, 2018 12:18 pm Thanks for the investigation, I guess we go back to the original plan of releasing the v2.0 with VS2013 and than update the dependencies (newer boost, newer openimageio, etc.) and the compiler (I guess to VS2017). So we take two birds with one stone. OK

Sure. Indeed my next question would have been about updating libraries. We are using some very old versions...

Posted: **Sat Jan 13, 2018 3:45 pm**

acasta69 wrote: Sat Jan 13, 2018 3:32 pm
Dade wrote: Sat Jan 13, 2018 12:18 pm Thanks for the investigation, I guess we go back to the original plan of releasing the v2.0 with VS2013 and than update the dependencies (newer boost, newer openimageio, etc.) and the compiler (I guess to VS2017). So we take two birds with one stone. OK
Sure. Indeed my next question would have been about updating libraries. We are using some very old versions...

Yup and it is a problem but upgrading all of them is probably going to take some time (we had even to patch some bug in them in the past) so I would prefer to take all required time. First we have to pick the version to upgrade too. We can probably aim for the same versions used by Blender as we have few libraries in common (OpenImageIO, etc.).

LuxCoreRender Forums

Compiling on Windows

Re: Compiling on Windows

Re: Compiling on Windows

Re: Compiling on Windows

Re: Compiling on Windows

Re: Compiling on Windows

Re: Compiling on Windows

Re: Compiling on Windows

Re: Compiling on Windows

Re: Compiling on Windows

Re: Compiling on Windows