Philip Lowman a écrit :
On Mon, Aug 25, 2008 at 6:04 AM, Yuri V. Timenkov
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
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.
Does LINK_INTERFACE_LIBRARIES_<CONFIG> do what you want to do?
See
http://www.cmake.org/HTML/cmake-2.6.html#prop_tgt:LINK_INTERFACE_LIBRARIES
in conjunction with SET_PROPERTY command.
If that works, CMake still could use a way to correlate the "debug" or
"optimized" target_link_libraries() directives with custom build
configurations. Perhaps something as simple as.
cmake default:
SET(CMAKE_DEBUG_CONFIGURATIONS Debug)
SET(CMAKE_OPTIMIZED_CONFIGURATIONS Release;MinSizeRel;RelWithDebInfo)
user code:
LIST(APPEND CMAKE_DEBUG_CONFIGURATIONS Profile Coverage Maintainer)
LIST(APPEND CMAKE_OPTIMIZED_CONFIGURATIONS SuperOptimized)
--
Philip Lowman
------------------------------------------------------------------------
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Thank you for your answer.
Unfortunately, I don't quite get how to implement your idea :(
Having cmake work on top of the two variables you suggested would be
just great; can you please get more into details?
Regards
Cyril
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
