[CMake] custom configuration types and linking with 3rd-party libs

Yuri V. Timenkov ytimenkov at parallels.com
Mon Aug 25 06:04:58 EDT 2008


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 at cmake.org
> > http://www.cmake.org/mailman/listinfo/cmake
>
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake



More information about the CMake mailing list