Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Windows build: release overwrites debug files #45
I tried to find answer to this in the documantation, with no immediate success:
Im trying to build magnum library for use with VS2013 in release as well as in debug modes. It seems however that output files have same names, and overwrite each other on install. Additionaly, cmake modules don't care to differentiate between release/debug versions of binaries either.
This is however important, as release/debug modules are not compatible, for example, you can't link magnum's release binaries with corrade's debug ones(error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL', error LNK2038: mismatch detected for 'RuntimeLibrary' is a direct result of such an attempt).
Exactly the same issue happens in custom programs that link to magnum: one can only build either debug or release, depending on what corrade/magnum configuration was recently built
Done in 1e6e4c3 and 5101e3a and similarly also in Corrade and other projects. Debug libraries are installed with
These changes are now also merged into
referenced this issue
Apr 9, 2014
Thanks it now seems to work.
Although i still had a problem while doing "textured triangle" tutorial: configure.h was generated only once at the beginning, so MAGNUM_PLUGINS_DIR define always pointed to the same directory. I think it would be better to write both release and debug plugin directories to the configure.h file and choose one of them via C preprocessor.
Yeah, dynamic plugins are still an issue, I failed to find any acceptable solution. The easiest (but still annoying) one is to specify the plugin directory at runtime (e.g. via command-line parameter).
The problem is (as far as I know) that CMake by default doesn't provide any usable information which could be handled via preprocessor -- the
I'll try to look deeper into this, maybe it would be possible to create some CMake macro which would produce actually usable preprocessor information.
Oh, apparently there is
and then, as you suggested, in the configuration file decide about that using preprocessor:
But I still find this slightly annoying and not exactly intuitive and straightforward. Actually, it would be excellent if CMake provided something like
If I won't find anything better I'll probably settle for global preprocessor definition set by Corrade (similarly as it now sets global compiler flags), which could be then used in depending projects instead of setting the property manually every time: