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

[cyril_wobow]

Yuri V. Timenkov a écrit :
> On Monday 25 August 2008 16:28:52 cyril_wobow wrote:
>   
>> Thank you for your answer. Sorry not to have provided the patch as an
>> attached file.
>>     
> No, its just more convenient to track issue history and patches.
>
>   
>> 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.
>>     
> Yes, and I agreed with you that cmake should have such functionality. The only 
> question is how to do it in most transparent way without breaking others.
>
>   
>> Then, what about the same patch with a slightly different test? like
>> matching the this->Config string against the following regexp:
>> "^(DEBUG|(.+_DBG))$"
>>     
> I personally don't like extra logic and artificial intellects. The configuration 
> approach is better than customization (ex. if you will use custom cmake with 
> your patch). But having too many tuning dimensions may result in incompatible 
> configurations, like what now happens in CPack with USE_DESTDIR / install_prefix 
> options in different generators.
>
>   
>> 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
>>>>         
>
>   
Thanks again for you answer.
I agree with you telling my patch proposal adds and modifies some logic 
into the link dependency resolution.
However, where in cmake documentation is the current logic exposed? I 
had to look at the sources to figure out what the current behavior was, 
and it is definitely not consistent from my point of view.
On the other hand, I have no experience with CPack, so I can only 
suppose that my patch gets along well with it.
My question then is simple: how to use custom build configurations in my 
projects in a way that... works? :D
Best regards,
Cyril