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