I'll have a deeper look into this: I also noticed that add_debug_variants() in malfunctioning in general and the Debug-Release switching is broken. I'll dig into this in conjunction with VS 2017 support work.

@Stinkfist0 that would be great. Just fixed the PR to work on nix.

@Stinkfist0 did you manage to have a look?

Sorry, got derailed with this, I'll try to take a look tonight and report back.

No worries, not urgent

Unfortunately I didn't have still time to look into this properly, but I think the root of the Release/Debug switching problems is the point when usage of link_directories() and link_libraries() was removed. IIRC, after that change I needed to introduce add_debug_variants(). Prior to that I think all worked perfectly fine without any custom code, at least on Windows/MSVC. These two built-in CMake functions should also handle paths fine spaces fine.

OK, finally have the time to properly look into this. Should be done by tonight.

Unfortunately I didn't have still time to look into this properly, but I think the root of the Release/Debug switching problems is the point when usage of link_directories() and link_libraries() was removed.

Well, I agree the amount of custom code to do some simple library linking doesn't feel right. The commit you are referring to is e9bd18f based on this issue #111

The problem being solved there is that if you refer to libs as a pair of <path, name> rather than just path/name you run into issues if there are libraries installed into (default) library locations (possibly referred to by other deps). I.e. you no longer have full control over what the linker is going to pick when there are multiple versions of one dep installed (e.g. oce from package manager and manually compiled).

Also note the CMake docs recommending against link_directories() [1]

Note that this command is rarely necessary. Library locations returned by find_package() and find_library() are absolute paths. Pass these absolute library file paths directly to the target_link_libraries() command. CMake will ensure the linker finds them.

So, with #217 this can be closed?

[1] https://cmake.org/cmake/help/v3.2/command/link_directories.html

Yeah, upon more thought specifying the full filename of the library feels better than the path-filename pair. Maybe in the future we can cook up a bit nicer and cleaner unified approach for this as the current CMake script is becoming quite convoluted. If the new PR looks good enough (better than this PR), yeah, this can be closed.