Re: [CMake] Beginning to compiling CMake file

If you go to https://github.com/imageworks/OpenShadingLanguage i.e. the top level directory of the github project, you'll se an appveyor.yml file entry. That is the information for the continuous integration tool (CI, AppVeyor) they are using to build the project from scratch. If you look into

[CMake] setting FIXTURES_* and RESOURCE_LOCK caused permission denied for dependent test?

Hi all, I am facing the issue of FIXTURES for setting up dependent test. Using RESOURCE_LOCK. Currently, it looks something like this: === set_test_properties(run_simulation PROPERTIES FIXTURES_SETUP ${simulation_name}) set_test_properties(compare_r

Re: [CMake] Beginning to compiling CMake file

Sorry, what is this information for; and how can it be used within the `build_script` section in the appveyor.yml file ? On 8/2/2018 9:30 AM, Volker Enderlein wrote: Please have a look into the appveyor.yml file under section build_script: you see the typical invocation of cmake for this githu

Re: [CMake] VS 2017 + CUDA 9.0

When initially configuring a project you can specify which toolset you would like to use. Starting in CMake 3.12 this now also supports specifying which patch version. You can see what the syntax looks like at: https://cmake.org/cmake/help/v3.12/release/3.12.html#id3 On Thu, Aug 2, 2018 at 4:12 PM

Re: [CMake] Can't find boost libs on VS2017 CMake 3.12

One hint would be to SET(Boost_DEBUG ON) and to watch the output of the cmake call. There, you can check the names of the libraries that CMake is looking for. On Windows, the new boost versions add a suffix fo x64/x86 to their library name. Can you confirm that the library names that Boost_DEBU

Re: [CMake] Can't find boost libs on VS2017 CMake 3.12

did you build boost yourself or download a pre-built package? What subdirectory are the import libraries (.lib) located in? Do you set any boost-finder variables before calling find_package(Boost)? I have at times in the past had to set BOOST_LIBRARYDIR when the package I was using had an odd li

Re: [CMake] LD_LIBRARY_PATH not used by the linker

Thanks for your answer, The thing is that, since the Python dependency comes from VTK, I checked in the VTK install directory all the CMake configuration files (In particulare the UseVTK.cmake) file to see if they keep the Python path somewhere. And it happens that yes, they do. If I run: `grep -

[CMake] VS 2017 + CUDA 9.0

Hi list, it seems that Cuda 9.0 has problems with VS 2017 (5.5 upwards) and requires an old toolset to be installed for successful compilation (15.4, see https://blogs.msdn.microsoft.com/vcblog/2017/11/15/side-by-side-minor-version-msvc-toolsets-in-visual-studio-2017/). The new VS 2017 toolset

Re: [CMake] LD_LIBRARY_PATH not used by the linker

It's the quick and easy way to do it. However, I'd suggest looking at getting CMake to use the proper path without it. Can you use any module-specific variables like PYTHON_LIBRARY to override the search. Or even just add to CMAKE_PREFIX_PATH. (Does VTK support imported targets?) Regards,

Re: [CMake] LD_LIBRARY_PATH not used by the linker

Hi Roger, so I explicitly passing the LDFLAGS is the way to go? On Thu, Aug 2, 2018 at 9:41 PM Roger Leigh wrote: > On 02/08/18 20:03, Ruben Di Battista wrote: > > > I'm running cmake on a system where I have module-loaded software such > > that `LD_LIBRARY_PATH` gets populated by the module (ac

Re: [CMake] LD_LIBRARY_PATH not used by the linker

On 02/08/18 20:03, Ruben Di Battista wrote: I'm running cmake on a system where I have module-loaded software such that `LD_LIBRARY_PATH` gets populated by the module (actually I'm using Lmod) function. LD_LIBRARY_PATH is used by the *runtime* linker, ld.so. It is not used when linking at *

[CMake] LD_LIBRARY_PATH not used by the linker

Hello, I'm running cmake on a system where I have module-loaded software such that `LD_LIBRARY_PATH` gets populated by the module (actually I'm using Lmod) function. In my project, I have a dependency on VTK, and VTK could be compiled with Python wrapping. This is what I have in my main CMakeFile

[CMake] simple find_package example

Hi, I'd like to figure out how to modify the simple "hello" demo ( https://cmake.org/examples/) so that the Hello project is a library with an accompanying FindHello.cmake and then the Demo project uses that information and "find_package" to discover/use it. Hopefully that makes sense. Basically,

Re: [CMake] Beginning to compiling CMake file

Please have a look into the appveyor.yml file under section build_script: you see the typical invocation of cmake for this github project. Cheers Volker Am 02/08/2018 um 15:18 schrieb CrestChristopher: I hope this helps; https://github.com/imageworks/OpenShadingLanguage/pull/824 ? On 8/1/2

[CMake] Can't find boost libs on VS2017 CMake 3.12

Dear cmake community I can't make CMake find the built boost libraries on Windows. At this line:     find_package(Boost REQUIRED COMPONENTS thread) I get this error message: "Unable to find the requested Boost libraries.   Boost version: 1.67.0   Boost include path: C:/download/boost/boost_1_

Re: [CMake] Beginning to compiling CMake file

I hope this helps; https://github.com/imageworks/OpenShadingLanguage/pull/824 ? On 8/1/2018 5:20 PM, Volker Enderlein wrote: Am 31.07.2018 um 06:17 schrieb CrestChristopher: Hi, I'm a beginner to CMake and for weeks I've been trying to compile a CMake file which I found on a github repository

Re: [CMake] Beginning to compiling CMake file

How can I verify whether what I want to built claims support for Windows ? On 8/1/2018 11:15 AM, Michael Ellery wrote: So it sounds like you are on windows. First, be sure that the project that you are building claims support for windows. Windows is still the “odd man out” platform in many ca

Re: [CMake] order of includes seems wrong (or please help me understand)

While the find modules that CMake provide don't use include_directories some externally written find module you are using could. You really need to provide a standalone reproduction of the problem, as currently people can only speculate on what is occurring. On Thu, Aug 2, 2018 at 7:58 AM Mario Em

Re: [CMake] order of includes seems wrong (or please help me understand)

Dear Robert, On 31.07.2018 15:04, Robert Maynard wrote: > The BEFORE keyword places the includes before any other paths such as > ones from other target_include_directories statements or from > transitive propagation from targets you linked too. > > As to why `CMAKE_PREFIX_PATH` is being added,