Thank you for your answer. Sorry not to have provided the patch as an
attached file.
Indeed, it would be a nice functionality. In my situation, all of the
cmake custom build configuration feature is unusable since it does not
support link-level tuning. That's a shame considering it is the one and
only detail that smashes down my plan of having a nice collection of
build types that properly build and link against the right libs, without
having to resort to config.h.in files and a tedious out-of-source,
multiple-solution workspace that should not be when using Visual Studio
or XCode like I do.
Then, what about the same patch with a slightly different test? like
matching the this->Config string against the following regexp:
"^(DEBUG|(.+_DBG))$"
Regards
Cyril
Yuri V. Timenkov a écrit :
On Monday 25 August 2008 13:04:56 cyril_wobow wrote:
Hi again,
At the end of the present mail there is a dirty-but-simple patch for
cmComputeLinkDepends.cxx in the cmake sources.
It allows to have configuration types like "GuiDebug, GuiRelease,
ConsoleDebug, ConsoleRelease" and still have the two debug configs be
considered as debug (non-optimized) configs, thus link with the debug
version of 3rd-party libraries.
Wondering if this patch could go into cmake trunk, until a better
solution is found (like real build configuration semantics).
Usually, cmake developers suggest file issue into tracker and attach patch to
it.
I also thought about this simple solution. But, for example, we had stupid
configuration name "ReleaseDebug" (It was release one but with debugging
information and without any optimization).
Other examples may include "profile", "coverage" or "maintainer" and one users
may desire to use optimized libs for them, while others debug ones.
The patch will not be much longer if you take into account extra list which
contains names for optimized and debug configurations (You have Makefile
reference with whole set of variables).
Anyways, I think it is good functionality which CMake should have.
430c430
< if(this->Config && cmSystemTools::UpperCase(this->Config) == "DEBUG")
---
> if(this->Config &&
cmSystemTools::UpperCase(this->Config).find("DEBUG") != std::string::npos)
508c508
< if(this->Config && cmSystemTools::UpperCase(this->Config) == "DEBUG")
---
> if(this->Config &&
cmSystemTools::UpperCase(this->Config).find("DEBUG") != std::string::npos)
Regards,
Cyril
cyril_wobow a écrit :
Hi,
I set my project's CMAKE_CONFIGURATION_TYPES variable with some custom
configurations (e.g. GuiDebug, GuiRelease, ConsoleDebug, ConsoleRelease).
Each of them have their own compilation flags, which is great,
especially for visual studio users that don't want to bother with a
config.h.in file but prefer a nice, expressive configuration list.
This works just fine.
Unfortunately, there is a showstopper : when it comes to linking, tell
me if I am wrong, there is no way to express which configuration type
should link against which library. In particular, all my configuration
types end up linking against the release version of my 3rd party
libraries.
1st possible solution :
Is there a way to specify libraries to link with, using a
XX_<CONFIG>-style variable ?
2nd possible solution :
Is there a way to specify, for each configuration type I declare in
CMAKE_CONFIGURATION_TYPES, if it is a "debug" or "optimized"
configuration ? A quick look at cmake sources makes me think that the
relation between a configuration type and its debug/optimized flavour
is hardcoded so that only config types named Debug (or deBUg or DEbuG)
are considered to be debug-flavoured configs. Which is embarrassing
because GuiDebug and ConsoleDebug would love to link against Qt debug
libraries for instance.
I would prefer to achieve the 2nd solution because it would be
compatible with existing cmake modules.
Kind regards
Cyril
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
