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

[cyril_wobow]

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