Project Properties get reset (VS2013)

Hi. I’m developing in the CUDA SDK with VS2013 and have added some third party libraries. I’m running into the issue that every time I build the project, all Project Properties of my sample project get reset.
I’m curious as to the cause of this as I’ve never experienced this outside the OptiX SDK. Could it be the CMake scripts? (I’m very much a beginner at CMake.) And if so, what would be a pointer into the right direction for me to fix this?

Edit: issue not yet solved but…
I have found the source of the issue. Indeed it was CMake.
Because I am changing and adding files within a sample, I want to keep the project, including CMake, up to date by adding these files to the file CMakeList.txt. (I knew as much as that this would add the files to projects generated with CMake.)
However, when such a CMake file is changed, CMake detects the change and reruns itself at build time (Visual Studio).
Previously this had been no issue. I only started noticing the resetting of my project’s properties when I added dependency on external libraries. By then I had no idea that this was related to my own changing of CMakeList.txt files.

My workaround: after adding files to any CMakeList.txt, regenerate the whole build folder with CMake as described in INSTALL-WIN.txt in the SDK root folder.

It’s happening again: when I build my project CMake resets my project’s settings, forcing me to redo all of my customisations. Now it is also happening when I have not changed any of the CMake files.

I currently see two alternatives:

  1. to learn CMake to understand and hopefully fix the not so simple CMake scripts that come with the SDK,
  2. to learn to set up an OptiX sample project without any CMake involvement.

I would like to ask if anyone sees other alternatives and would be willing to give me some pointers to get started with either solution.

Hello,

Yes, if you are using CMake you do not want to perform any direct editing of the VS project (or Makefiles on *nix systems). CMake is the configuration system – for instance you can use the cmake command target_link_libraries to add link to any additional libs.

Your two proposed alternatives are mostly correct. You need to either use cmake for all config, or make your own VS project. However, you do not have to use the SDK CMake infrastructure. It is a little complicated since it needs to build the entire SDK and whatnot. You could write a much simpler CMake script which only does what you need.

If you want to setup your own VS solution the only slightly tricky part is setting up the build for cuda files so they are compiled to PTX. Take a look in the optix programming guide for discussion of this (tldr; use --ptx and --use-fast-math command line flags to nvcc).

I went for option 1: learning CMake. For anyone who would like to take the easy route and “just add” some external libraries to an OptiX SDK sample, this is what you do:

  1. Go to the folder of the sample project of your choice, within the OptiX SDK folder.
  2. Open the CMakeLists.txt file within that folder.
  3. You're going to edit that file by pasting in some lines. Read the lines of code below carefully, paste them in, and adjust them to your situation.
# Define paths to the library files to link and the header files to include.
# Put these lines anywhere above the code block below, for example at the top of the file.
set(<3rd party name>_LIBRARY_DIR "<3rd party path to .lib files>" CACHE PATH "Path to the libraries to link from <3rd party name>.")
set(<3rd party name>_INCLUDE_DIR "<3rd party path to .h files>"   CACHE PATH "Path to the headers to include from <3rd party name>.")
# The lines below must come AFTER the function OPTIX_add_sample_executable has been called.
# This is because OPTIX_add_sample_executable defines <name of your sample project> (for example "cook").

# Include <3rd party name> headers and link <3rd party name> libraries.
include_directories(${<3rd party name>_INCLUDE_DIR})

# Repeat the following lines for every library file you wish to link.
# <library file name>.lib
find_library(<3rd party name>_LIBRARY_PATH_<library file name> <library file name> ${<3rd party name>_LIBRARY_DIR})
target_link_libraries( <name of your sample project> ${<3rd party name>_LIBRARY_PATH_<library file name>} )

After these adjustments, you should be able to generate your project with CMake, including all dependencies, and best of all: the dependencies will not be removed by CMake.

Using VS2013, there are certain things that will cause the CMake scripts to re-run – adding a new #include, for instance.

I recommend that you implement all of your customizations within CMake. Ideally, you shouldn’t “customize” your project at all, because CMake will do that for you. This has the advantage of making your code more easily portable.

Hi kmorley. Thanks for your reply. You just ninja’d me before I posted my own solution. :)
It is nice to read that another person agrees with my analysis of the situation: that I had to either learn CMake or start a CMake-less project.

Also thanks to nljones for supporting my move to CMake.

The additional insight that adding a new #include causes CMake to rerun is also very valuable. I had not yet made that connection and the sporadic reruns of CMake had been a mystery to me until I read your comment. Thanks again!