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

[Yuri V. Timenkov]

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