[CMake] Solution groups and sub projects.
Hello all, This has been asked for quite a few times with no answer and I'm putting the same question again. Do we have the support for solution groups and sub projects with VS generators. I'm using CMake-2.8.0 (I could see there's a bughttp://www.itk.org/Bug/bug_view_page.php?bug_id=6577history=1reported already, but no progress on that) If the feature is not available off the shelf, can we resort to some hacks with CMakeLists.txt file ? Thanks, Surya ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] link static lib to dll
A DLL-library is linked to static library.
The structure of the project is this:
main-project
+- Project STATIC
|
+- Project DLL
This works very well.
But if I include the following export part to the project of the DLL...
INSTALL(TARGETS T-DLL EXPORT T-DLLExport
RUNTIME DESTINATION dll
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib)
INSTALL(EXPORT T-DLLExport DESTINATION lib/${T-DLL})
... CMake generates the message: CMake Error: INSTALL(EXPORT
TLIBExport ...) includes target T-DLL which requires target
T-Static that is not in the export set.
This is unexpected. I don't want export the static library because it is
already linked to the DLL and it is used only by the DLL.
Micha
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link static lib to dll
On 9. Feb, 2010, at 11:05 , Micha Renner wrote:
A DLL-library is linked to static library.
The structure of the project is this:
main-project
+- Project STATIC
|
+- Project DLL
This works very well.
But if I include the following export part to the project of the DLL...
INSTALL(TARGETS T-DLL EXPORT T-DLLExport
RUNTIME DESTINATION dll
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib)
INSTALL(EXPORT T-DLLExport DESTINATION lib/${T-DLL})
... CMake generates the message: CMake Error: INSTALL(EXPORT
TLIBExport ...) includes target T-DLL which requires target
T-Static that is not in the export set.
This is unexpected. I don't want export the static library because it is
already linked to the DLL and it is used only by the DLL.
Micha
But CMake can't know that somebody linking against the DLL won't need the
static library. This is because the static library might contain additional
symbols which are not used directly by any of the code in the DLL, and thus are
not present in there. That's one of the most surprising facts of static
linking...
The solution is to tell CMake explicitly which of the libraries are in the
link interface and thus must be also exported using the
LINK_INTERFACE_LIBRARIES target property of your DLL. Set it to the list of
libraries which appear in the link interface of your library (i.e. NOT the
static library you're talking about). But be careful, if you miss any of the
real dependencies, all hell might break loose at any time, even far in the
future...
HTH
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to findXXX libraries with debug suffix
Is there a way to instruct FindXXX modules to produce variables that have different linking in debug and release? I am producind a lib with suffix D (zlib) in an ExternalProjetAdd, target.It gets installed correctly in debug (which is the default for VS cmake--build) This zlibD.lib does not get found when other projects subsequently issues a find_package(ZLIB ) Are there Find modules that supports debug/release? Any example of this usage pattern? Thanks Luigi ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to use DEFINE_SYMBOL properly?
Hello,
From what I read and understood this DEFINE_SYMBOL property should be
defined like this (or something like this):
On Windows, as shared library: target_EXPORTS=__declspec(dllexport)
On Linux, as shared library:
target_EXPORTS=__attribute__((visibility(default)))
So that I can use this symbol like this:
class target_EXPORTS ExampleClass {...};
But on my machine (Linux, gcc) while building a shared library, with
CMake 2.8.0, I'm getting the error below because CMake is defining this
property with -Dtarget_EXPORTS=0:
error: expected identifier before numeric constant
What am I missing?
Kind regards,
Hilton
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to findXXX libraries with debug suffix
Here is one I wrote for Expat:
--8
# - Find expat
# Find the native EXPAT headers and libraries.
#
# EXPAT_INCLUDE_DIRS - where to find expat.h, etc.
# EXPAT_LIBRARIES- List of libraries when using expat.
# EXPAT_LIBRARY_DEBUG - Debug version of Library
# EXPAT_LIBRARY_RELEASE - Release Version of Library
# EXPAT_FOUND- True if expat found.
#
# Check the existence of the libraries.
#
# This macro was taken directly from the FindQt4.cmake file that is included
# with the CMake distribution. This is NOT my work. All work was done by the
# original authors of the FindQt4.cmake file. Only minor modifications were
# made to remove references to Qt and make this file more generally applicable
#
MACRO (ADJUST_LIB_VARS basename)
IF (${basename}_INCLUDE_DIR)
# if only the release version was found, set the debug variable also
to the release version
IF (${basename}_LIBRARY_RELEASE AND NOT ${basename}_LIBRARY_DEBUG)
SET(${basename}_LIBRARY_DEBUG ${${basename}_LIBRARY_RELEASE})
SET(${basename}_LIBRARY ${${basename}_LIBRARY_RELEASE})
SET(${basename}_LIBRARIES ${${basename}_LIBRARY_RELEASE})
ENDIF (${basename}_LIBRARY_RELEASE AND NOT ${basename}_LIBRARY_DEBUG)
# if only the debug version was found, set the release variable also
to the debug version
IF (${basename}_LIBRARY_DEBUG AND NOT ${basename}_LIBRARY_RELEASE)
SET(${basename}_LIBRARY_RELEASE ${${basename}_LIBRARY_DEBUG})
SET(${basename}_LIBRARY ${${basename}_LIBRARY_DEBUG})
SET(${basename}_LIBRARIES ${${basename}_LIBRARY_DEBUG})
ENDIF (${basename}_LIBRARY_DEBUG AND NOT ${basename}_LIBRARY_RELEASE)
IF (${basename}_LIBRARY_DEBUG AND ${basename}_LIBRARY_RELEASE)
# if the generator supports configuration types then set
# optimized and debug libraries, or if the CMAKE_BUILD_TYPE has a value
IF (CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
SET(${basename}_LIBRARY optimized
${${basename}_LIBRARY_RELEASE} debug ${${basename}_LIBRARY_DEBUG})
ELSE(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
# if there are no configuration types and CMAKE_BUILD_TYPE has no value
# then just use the release libraries
SET(${basename}_LIBRARY ${${basename}_LIBRARY_RELEASE} )
ENDIF(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
SET(${basename}_LIBRARIES optimized
${${basename}_LIBRARY_RELEASE} debug ${${basename}_LIBRARY_DEBUG})
ENDIF (${basename}_LIBRARY_DEBUG AND ${basename}_LIBRARY_RELEASE)
SET(${basename}_LIBRARY ${${basename}_LIBRARY} CACHE FILEPATH The
${basename} library)
IF (${basename}_LIBRARY)
SET(${basename}_FOUND 1)
ENDIF (${basename}_LIBRARY)
ENDIF (${basename}_INCLUDE_DIR )
# Make variables changeble to the advanced user
MARK_AS_ADVANCED(${basename}_LIBRARY ${basename}_LIBRARY_RELEASE
${basename}_LIBRARY_DEBUG ${basename}_INCLUDE_DIR )
ENDMACRO (ADJUST_LIB_VARS)
# Look for the header file.
# MESSAGE (STATUS Finding expat library and headers... )
SET (EXPAT_DEBUG 0)
SET(EXPAT_INCLUDE_SEARCH_DIRS
$ENV{EXPAT_INSTALL}/include
)
SET (EXPAT_LIB_SEARCH_DIRS
$ENV{EXPAT_INSTALL}/lib
)
SET (EXPAT_BIN_SEARCH_DIRS
$ENV{EXPAT_INSTALL}/bin
)
FIND_PATH(EXPAT_INCLUDE_DIR
NAMES expat.h
PATHS ${EXPAT_INCLUDE_SEARCH_DIRS}
NO_DEFAULT_PATH
)
IF (WIN32 AND NOT MINGW)
SET (EXPAT_SEARCH_DEBUG_NAMES expatdll_D;libexpat_D)
SET (EXPAT_SEARCH_RELEASE_NAMES expatdll;libexpat)
ELSE (WIN32 AND NOT MINGW)
SET (EXPAT_SEARCH_DEBUG_NAMES expat_debug)
SET (EXPAT_SEARCH_RELEASE_NAMES expat)
ENDIF(WIN32 AND NOT MINGW)
IF (EXPAT_DEBUG)
message (STATUS EXPAT_INCLUDE_SEARCH_DIRS: ${EXPAT_INCLUDE_SEARCH_DIRS})
message (STATUS EXPAT_LIB_SEARCH_DIRS: ${EXPAT_LIB_SEARCH_DIRS})
message (STATUS EXPAT_BIN_SEARCH_DIRS: ${EXPAT_BIN_SEARCH_DIRS})
message (STATUS EXPAT_SEARCH_RELEASE_NAMES: ${EXPAT_SEARCH_RELEASE_NAMES})
message (STATUS EXPAT_SEARCH_DEBUG_NAMES: ${EXPAT_SEARCH_DEBUG_NAMES})
ENDIF (EXPAT_DEBUG)
# Look for the library.
FIND_LIBRARY(EXPAT_LIBRARY_DEBUG
NAMES ${EXPAT_SEARCH_DEBUG_NAMES}
PATHS ${EXPAT_LIB_SEARCH_DIRS}
NO_DEFAULT_PATH
)
FIND_LIBRARY(EXPAT_LIBRARY_RELEASE
NAMES ${EXPAT_SEARCH_RELEASE_NAMES}
PATHS ${EXPAT_LIB_SEARCH_DIRS}
NO_DEFAULT_PATH
)
SET (EXPAT_XMLWF_PROG_NAME xmlwf)
IF (WIN32)
SET (EXPAT_XMLWF_PROG_NAME xmlwf.exe)
ENDIF(WIN32)
FIND_PROGRAM(EXPAT_XMLWF_PROG
NAMES ${EXPAT_XMLWF_PROG_NAME}
PATHS ${EXPAT_BIN_SEARCH_DIRS}
NO_DEFAULT_PATH
)
MARK_AS_ADVANCED(EXPAT_XMLWF_PROG)
IF (EXPAT_DEBUG)
MESSAGE(STATUS EXPAT_INCLUDE_DIR: ${EXPAT_INCLUDE_DIR})
MESSAGE(STATUS EXPAT_LIBRARY_DEBUG: ${EXPAT_LIBRARY_DEBUG})
MESSAGE(STATUS EXPAT_LIBRARY_RELEASE: ${EXPAT_LIBRARY_RELEASE})
MESSAGE(STATUS CMAKE_BUILD_TYPE: ${CMAKE_BUILD_TYPE})
endif(EXPAT_DEBUG)
Re: [CMake] How to use DEFINE_SYMBOL properly?
Hello,
You are doing it wrong. You need to create a header file
(myproject_exports.h, for instance) following
http://gcc.gnu.org/wiki/Visibility . If you call your visibility macro
target_EXPORTS, you do not need to modify the value of DEFINE_SYMBOL
at all, CMake will automagically make use of it. You only need to do
set_target_properties( target PROPERTIES DEFINE_SYMBOL
my_visibility_macro ) if you want to use a different name for the
macro (usually because it is an already-existing project which you are
converting to CMake).
On Tue, Feb 9, 2010 at 1:25 PM, Hilton Medeiros
medeiros.hil...@gmail.com wrote:
Hello,
From what I read and understood this DEFINE_SYMBOL property should be
defined like this (or something like this):
On Windows, as shared library: target_EXPORTS=__declspec(dllexport)
On Linux, as shared library:
target_EXPORTS=__attribute__((visibility(default)))
So that I can use this symbol like this:
class target_EXPORTS ExampleClass {...};
But on my machine (Linux, gcc) while building a shared library, with
CMake 2.8.0, I'm getting the error below because CMake is defining this
property with -Dtarget_EXPORTS=0:
error: expected identifier before numeric constant
What am I missing?
Kind regards,
Hilton
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to use DEFINE_SYMBOL properly?
http://www.cmake.org/Wiki/BuildingWinDLL
_
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer Dayton, Ohio
On Tue, Feb 9, 2010 at 8:25 AM, Pau Garcia i Quiles
pgqui...@elpauer.org wrote:
Hello,
You are doing it wrong. You need to create a header file
(myproject_exports.h, for instance) following
http://gcc.gnu.org/wiki/Visibility . If you call your visibility macro
target_EXPORTS, you do not need to modify the value of DEFINE_SYMBOL
at all, CMake will automagically make use of it. You only need to do
set_target_properties( target PROPERTIES DEFINE_SYMBOL
my_visibility_macro ) if you want to use a different name for the
macro (usually because it is an already-existing project which you are
converting to CMake).
On Tue, Feb 9, 2010 at 1:25 PM, Hilton Medeiros
medeiros.hil...@gmail.com wrote:
Hello,
From what I read and understood this DEFINE_SYMBOL property should be
defined like this (or something like this):
On Windows, as shared library: target_EXPORTS=__declspec(dllexport)
On Linux, as shared library:
target_EXPORTS=__attribute__((visibility(default)))
So that I can use this symbol like this:
class target_EXPORTS ExampleClass {...};
But on my machine (Linux, gcc) while building a shared library, with
CMake 2.8.0, I'm getting the error below because CMake is defining this
property with -Dtarget_EXPORTS=0:
error: expected identifier before numeric constant
What am I missing?
Kind regards,
Hilton
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to findXXX libraries with debug suffix
Hi Mike, thanks for the code, I' ll try to understand it and to apply to
my need...
I see is quite more complex than the statndard FindExpat bundled with
CMake:
Is it customized to your need or just better?
In the latter case, why not ship cmake with it?
Is testing for debugging libs a very uncommon task?
Are there other ways to accomplish the same thing?
Thanks a lot
Luigi
Mike Jackson wrote:
Here is one I wrote for Expat:
--8
# - Find expat
# Find the native EXPAT headers and libraries.
#
# EXPAT_INCLUDE_DIRS - where to find expat.h, etc.
# EXPAT_LIBRARIES- List of libraries when using expat.
# EXPAT_LIBRARY_DEBUG - Debug version of Library
# EXPAT_LIBRARY_RELEASE - Release Version of Library
# EXPAT_FOUND- True if expat found.
#
# Check the existence of the libraries.
#
# This macro was taken directly from the FindQt4.cmake file that is included
# with the CMake distribution. This is NOT my work. All work was done by the
# original authors of the FindQt4.cmake file. Only minor modifications were
# made to remove references to Qt and make this file more generally applicable
#
MACRO (ADJUST_LIB_VARS basename)
IF (${basename}_INCLUDE_DIR)
# if only the release version was found, set the debug variable also
to the release version
IF (${basename}_LIBRARY_RELEASE AND NOT ${basename}_LIBRARY_DEBUG)
SET(${basename}_LIBRARY_DEBUG ${${basename}_LIBRARY_RELEASE})
SET(${basename}_LIBRARY ${${basename}_LIBRARY_RELEASE})
SET(${basename}_LIBRARIES ${${basename}_LIBRARY_RELEASE})
ENDIF (${basename}_LIBRARY_RELEASE AND NOT ${basename}_LIBRARY_DEBUG)
# if only the debug version was found, set the release variable also
to the debug version
IF (${basename}_LIBRARY_DEBUG AND NOT ${basename}_LIBRARY_RELEASE)
SET(${basename}_LIBRARY_RELEASE ${${basename}_LIBRARY_DEBUG})
SET(${basename}_LIBRARY ${${basename}_LIBRARY_DEBUG})
SET(${basename}_LIBRARIES ${${basename}_LIBRARY_DEBUG})
ENDIF (${basename}_LIBRARY_DEBUG AND NOT ${basename}_LIBRARY_RELEASE)
IF (${basename}_LIBRARY_DEBUG AND ${basename}_LIBRARY_RELEASE)
# if the generator supports configuration types then set
# optimized and debug libraries, or if the CMAKE_BUILD_TYPE has a value
IF (CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
SET(${basename}_LIBRARY optimized
${${basename}_LIBRARY_RELEASE} debug ${${basename}_LIBRARY_DEBUG})
ELSE(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
# if there are no configuration types and CMAKE_BUILD_TYPE has no value
# then just use the release libraries
SET(${basename}_LIBRARY ${${basename}_LIBRARY_RELEASE} )
ENDIF(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
SET(${basename}_LIBRARIES optimized
${${basename}_LIBRARY_RELEASE} debug ${${basename}_LIBRARY_DEBUG})
ENDIF (${basename}_LIBRARY_DEBUG AND ${basename}_LIBRARY_RELEASE)
SET(${basename}_LIBRARY ${${basename}_LIBRARY} CACHE FILEPATH The
${basename} library)
IF (${basename}_LIBRARY)
SET(${basename}_FOUND 1)
ENDIF (${basename}_LIBRARY)
ENDIF (${basename}_INCLUDE_DIR )
# Make variables changeble to the advanced user
MARK_AS_ADVANCED(${basename}_LIBRARY ${basename}_LIBRARY_RELEASE
${basename}_LIBRARY_DEBUG ${basename}_INCLUDE_DIR )
ENDMACRO (ADJUST_LIB_VARS)
# Look for the header file.
# MESSAGE (STATUS Finding expat library and headers... )
SET (EXPAT_DEBUG 0)
SET(EXPAT_INCLUDE_SEARCH_DIRS
$ENV{EXPAT_INSTALL}/include
)
SET (EXPAT_LIB_SEARCH_DIRS
$ENV{EXPAT_INSTALL}/lib
)
SET (EXPAT_BIN_SEARCH_DIRS
$ENV{EXPAT_INSTALL}/bin
)
FIND_PATH(EXPAT_INCLUDE_DIR
NAMES expat.h
PATHS ${EXPAT_INCLUDE_SEARCH_DIRS}
NO_DEFAULT_PATH
)
IF (WIN32 AND NOT MINGW)
SET (EXPAT_SEARCH_DEBUG_NAMES expatdll_D;libexpat_D)
SET (EXPAT_SEARCH_RELEASE_NAMES expatdll;libexpat)
ELSE (WIN32 AND NOT MINGW)
SET (EXPAT_SEARCH_DEBUG_NAMES expat_debug)
SET (EXPAT_SEARCH_RELEASE_NAMES expat)
ENDIF(WIN32 AND NOT MINGW)
IF (EXPAT_DEBUG)
message (STATUS EXPAT_INCLUDE_SEARCH_DIRS: ${EXPAT_INCLUDE_SEARCH_DIRS})
message (STATUS EXPAT_LIB_SEARCH_DIRS: ${EXPAT_LIB_SEARCH_DIRS})
message (STATUS EXPAT_BIN_SEARCH_DIRS: ${EXPAT_BIN_SEARCH_DIRS})
message (STATUS EXPAT_SEARCH_RELEASE_NAMES: ${EXPAT_SEARCH_RELEASE_NAMES})
message (STATUS EXPAT_SEARCH_DEBUG_NAMES: ${EXPAT_SEARCH_DEBUG_NAMES})
ENDIF (EXPAT_DEBUG)
# Look for the library.
FIND_LIBRARY(EXPAT_LIBRARY_DEBUG
NAMES ${EXPAT_SEARCH_DEBUG_NAMES}
PATHS ${EXPAT_LIB_SEARCH_DIRS}
NO_DEFAULT_PATH
)
FIND_LIBRARY(EXPAT_LIBRARY_RELEASE
NAMES ${EXPAT_SEARCH_RELEASE_NAMES}
PATHS ${EXPAT_LIB_SEARCH_DIRS}
NO_DEFAULT_PATH
)
SET (EXPAT_XMLWF_PROG_NAME xmlwf)
IF (WIN32)
SET (EXPAT_XMLWF_PROG_NAME xmlwf.exe)
ENDIF(WIN32)
Re: [CMake] How to findXXX libraries with debug suffix
From my own experience there are very few projects that can be
configured to have an installation of both debug and release libraries
in the same installation tree. Qt was the first one that I have seen
but there are a few others. After going through pain on windows where
ALL libraries MUST be linked against the same type of libraries (Debug
or Release), creating my support libraries with debug-and-release
variants in the same installation directory proved much more useful so
I created my own sets of Find for each of the libraries that I
depend on: Tiff, Expat, HDF5. Boost and Qt both have debug-and-release
in the same installation so those didn't need help.
I have my own CMake build systems for each of those libraries so
the FindXXX.cmake modules are customized for my own use although they
are _suppose_ to work with the standard distributions of those
libraries.
There does not seem to be any consensus on what the debug suffix
should be: d _debug Debug so it is hard to come up with
something consistent.
I have not asked the CMake devs to use this FindExpat because of
all the specializations I have made. Most of the code is taken
directly from the FindQt4.cmake file.
_
Mike Jackson mike.jack...@bluequartz.net
On Tue, Feb 9, 2010 at 8:40 AM, Luigi Calori l.cal...@cineca.it wrote:
Hi Mike, thanks for the code, I' ll try to understand it and to apply to my
need...
I see is quite more complex than the statndard FindExpat bundled with CMake:
Is it customized to your need or just better?
In the latter case, why not ship cmake with it?
Is testing for debugging libs a very uncommon task?
Are there other ways to accomplish the same thing?
Thanks a lot
Luigi
Mike Jackson wrote:
Here is one I wrote for Expat:
--8
# - Find expat
# Find the native EXPAT headers and libraries.
#
# EXPAT_INCLUDE_DIRS - where to find expat.h, etc.
# EXPAT_LIBRARIES - List of libraries when using expat.
# EXPAT_LIBRARY_DEBUG - Debug version of Library
# EXPAT_LIBRARY_RELEASE - Release Version of Library
# EXPAT_FOUND - True if expat found.
#
# Check the existence of the libraries.
#
# This macro was taken directly from the FindQt4.cmake file that is
included
# with the CMake distribution. This is NOT my work. All work was done by
the
# original authors of the FindQt4.cmake file. Only minor modifications
were
# made to remove references to Qt and make this file more generally
applicable
#
MACRO (ADJUST_LIB_VARS basename)
IF (${basename}_INCLUDE_DIR)
# if only the release version was found, set the debug variable also
to the release version
IF (${basename}_LIBRARY_RELEASE AND NOT ${basename}_LIBRARY_DEBUG)
SET(${basename}_LIBRARY_DEBUG ${${basename}_LIBRARY_RELEASE})
SET(${basename}_LIBRARY ${${basename}_LIBRARY_RELEASE})
SET(${basename}_LIBRARIES ${${basename}_LIBRARY_RELEASE})
ENDIF (${basename}_LIBRARY_RELEASE AND NOT ${basename}_LIBRARY_DEBUG)
# if only the debug version was found, set the release variable also
to the debug version
IF (${basename}_LIBRARY_DEBUG AND NOT ${basename}_LIBRARY_RELEASE)
SET(${basename}_LIBRARY_RELEASE ${${basename}_LIBRARY_DEBUG})
SET(${basename}_LIBRARY ${${basename}_LIBRARY_DEBUG})
SET(${basename}_LIBRARIES ${${basename}_LIBRARY_DEBUG})
ENDIF (${basename}_LIBRARY_DEBUG AND NOT ${basename}_LIBRARY_RELEASE)
IF (${basename}_LIBRARY_DEBUG AND ${basename}_LIBRARY_RELEASE)
# if the generator supports configuration types then set
# optimized and debug libraries, or if the CMAKE_BUILD_TYPE has a value
IF (CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
SET(${basename}_LIBRARY optimized
${${basename}_LIBRARY_RELEASE} debug ${${basename}_LIBRARY_DEBUG})
ELSE(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
# if there are no configuration types and CMAKE_BUILD_TYPE has no
value
# then just use the release libraries
SET(${basename}_LIBRARY ${${basename}_LIBRARY_RELEASE} )
ENDIF(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
SET(${basename}_LIBRARIES optimized
${${basename}_LIBRARY_RELEASE} debug ${${basename}_LIBRARY_DEBUG})
ENDIF (${basename}_LIBRARY_DEBUG AND ${basename}_LIBRARY_RELEASE)
SET(${basename}_LIBRARY ${${basename}_LIBRARY} CACHE FILEPATH The
${basename} library)
IF (${basename}_LIBRARY)
SET(${basename}_FOUND 1)
ENDIF (${basename}_LIBRARY)
ENDIF (${basename}_INCLUDE_DIR )
# Make variables changeble to the advanced user
MARK_AS_ADVANCED(${basename}_LIBRARY ${basename}_LIBRARY_RELEASE
${basename}_LIBRARY_DEBUG ${basename}_INCLUDE_DIR )
ENDMACRO (ADJUST_LIB_VARS)
# Look for the header file.
#
Re: [CMake] Solution groups and sub projects.
Am Dienstag, den 09.02.2010, 14:34 +0530 schrieb Surya Kiran Gullapalli: Hello all, This has been asked for quite a few times with no answer and I'm putting the same question again. Do we have the support for solution groups and sub projects with VS generators. I'm using CMake-2.8.0 (I could see there's a bug reported already, but no progress on that) If the feature is not available off the shelf, can we resort to some hacks with CMakeLists.txt file ? Did you look here: http://www.itk.org/Bug/view.php?id=3796 May be you can use the patch, I am not sure. Micha Thanks, Surya ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to use DEFINE_SYMBOL properly?
Just to get some more clarification, what exactly do you mean by ...this
visibility macro turns out to be always the same thing in every
project...,
The only thing you can say for certain is that for the versions of
Visual Studio and GCC _currently_ released the macros seem to stay the
same. There is absolutely NO guarantee that Microsoft, Apple, GNU or
someone else will NOT change that in the future.
So right now the code that needs to be included in your project via a
header file is pretty much boilerplate code and is simple and
straight forward to insert into your project.
Also, if you are converting another non-cmake project to CMake then
how that projects goes about implementing their visibility macros may
be different than how CMake chose to do it.
_
Mike Jackson mike.jack...@bluequartz.net
On Tue, Feb 9, 2010 at 8:59 AM, Hilton Medeiros
medeiros.hil...@gmail.com wrote:
Thanks a lot for the answers.
Indeed, I already knew this macro, but I thought that since this
visibility macro turns out to be always the same thing in every
project, CMake would have it built in. I can't see why this is not the
case yet.
Well, back to #defines...
Thanks again,
Hilton
On Tue, 9 Feb 2010 08:29:36 -0500
Mike Jackson mike.jack...@bluequartz.net wrote:
http://www.cmake.org/Wiki/BuildingWinDLL
_
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Software www.bluequartz.net
Principal Software Engineer Dayton, Ohio
On Tue, Feb 9, 2010 at 8:25 AM, Pau Garcia i Quiles
pgqui...@elpauer.org wrote:
Hello,
You are doing it wrong. You need to create a header file
(myproject_exports.h, for instance) following
http://gcc.gnu.org/wiki/Visibility . If you call your visibility
macro target_EXPORTS, you do not need to modify the value of
DEFINE_SYMBOL at all, CMake will automagically make use of it. You
only need to do set_target_properties( target PROPERTIES
DEFINE_SYMBOL my_visibility_macro ) if you want to use a different
name for the macro (usually because it is an already-existing
project which you are converting to CMake).
On Tue, Feb 9, 2010 at 1:25 PM, Hilton Medeiros
medeiros.hil...@gmail.com wrote:
Hello,
From what I read and understood this DEFINE_SYMBOL property should
be defined like this (or something like this):
On Windows, as shared library: target_EXPORTS=__declspec(dllexport)
On Linux, as shared library:
target_EXPORTS=__attribute__((visibility(default)))
So that I can use this symbol like this:
class target_EXPORTS ExampleClass {...};
But on my machine (Linux, gcc) while building a shared library,
with CMake 2.8.0, I'm getting the error below because CMake is
defining this property with -Dtarget_EXPORTS=0:
error: expected identifier before numeric constant
What am I missing?
Kind regards,
Hilton
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to use DEFINE_SYMBOL properly?
Thanks a lot for the answers.
Indeed, I already knew this macro, but I thought that since this
visibility macro turns out to be always the same thing in every
project, CMake would have it built in. I can't see why this is not the
case yet.
Well, back to #defines...
Thanks again,
Hilton
On Tue, 9 Feb 2010 08:29:36 -0500
Mike Jackson mike.jack...@bluequartz.net wrote:
http://www.cmake.org/Wiki/BuildingWinDLL
_
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer Dayton, Ohio
On Tue, Feb 9, 2010 at 8:25 AM, Pau Garcia i Quiles
pgqui...@elpauer.org wrote:
Hello,
You are doing it wrong. You need to create a header file
(myproject_exports.h, for instance) following
http://gcc.gnu.org/wiki/Visibility . If you call your visibility
macro target_EXPORTS, you do not need to modify the value of
DEFINE_SYMBOL at all, CMake will automagically make use of it. You
only need to do set_target_properties( target PROPERTIES
DEFINE_SYMBOL my_visibility_macro ) if you want to use a different
name for the macro (usually because it is an already-existing
project which you are converting to CMake).
On Tue, Feb 9, 2010 at 1:25 PM, Hilton Medeiros
medeiros.hil...@gmail.com wrote:
Hello,
From what I read and understood this DEFINE_SYMBOL property should
be defined like this (or something like this):
On Windows, as shared library: target_EXPORTS=__declspec(dllexport)
On Linux, as shared library:
target_EXPORTS=__attribute__((visibility(default)))
So that I can use this symbol like this:
class target_EXPORTS ExampleClass {...};
But on my machine (Linux, gcc) while building a shared library,
with CMake 2.8.0, I'm getting the error below because CMake is
defining this property with -Dtarget_EXPORTS=0:
error: expected identifier before numeric constant
What am I missing?
Kind regards,
Hilton
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to findXXX libraries with debug suffix
My version of Tiff is at:
http://www.bluequartz.net/cgi-bin/gitweb/gitweb.cgi
There are zlib and tiff entries there. There is also a project called
CxImage (which I kind of hijacked from the original author) that
includes zlib, tiff, jpeg and png as support files in the project
and builds all of them first before the mail CxImage is built. You can
pull any of these projects to take a look at how I chose to implement
the CMake specifics.
_
Mike Jackson mike.jack...@bluequartz.net
On Tue, Feb 9, 2010 at 9:41 AM, Luigi Calori l.cal...@cineca.it wrote:
Hi Mike, I'm in a similar boat: I would like to build, via CMake and
ExternalProjectAdd, some of the deps needed by
OpenSceneGraph pluging (runtime loaded dlls). I currently have almost
managed to build zlib,png,jpeg,freetype,curl
under windows MSVC9 and had tried also linux, with partial success.
Even with this so simple setup, happens that png depends on zlib, so zlib
builds first, then the png cmake can find it if you
specify the CMAKE_PREFIX_PATH and CMAKE_INSTALL_PREFIX as a common install
prefix.
If building first on debug, the findZLIB fail.
It seem to me not so uncommon setup, as, at least for OSG, all the dep libs
are provided in debug and release version by appending D
(or d)
Are you using ExternalProject ? are you building tiff with cmake?
If your project is open, would be really helpful to get pointers.
Anyway, I' ll try to apply your suggestion and see how it goes. It seem to
me anyway a worth improvement over standard Find.
Thanks again
Luigi
Mike Jackson wrote:
From my own experience there are very few projects that can be
configured to have an installation of both debug and release libraries
in the same installation tree. Qt was the first one that I have seen
but there are a few others. After going through pain on windows where
ALL libraries MUST be linked against the same type of libraries (Debug
or Release), creating my support libraries with debug-and-release
variants in the same installation directory proved much more useful so
I created my own sets of Find for each of the libraries that I
depend on: Tiff, Expat, HDF5. Boost and Qt both have debug-and-release
in the same installation so those didn't need help.
I have my own CMake build systems for each of those libraries so
the FindXXX.cmake modules are customized for my own use although they
are _suppose_ to work with the standard distributions of those
libraries.
There does not seem to be any consensus on what the debug suffix
should be: d _debug Debug so it is hard to come up with
something consistent.
I have not asked the CMake devs to use this FindExpat because of
all the specializations I have made. Most of the code is taken
directly from the FindQt4.cmake file.
_
Mike Jackson mike.jack...@bluequartz.net
On Tue, Feb 9, 2010 at 8:40 AM, Luigi Calori l.cal...@cineca.it wrote:
Hi Mike, thanks for the code, I' ll try to understand it and to apply to
my
need...
I see is quite more complex than the statndard FindExpat bundled with
CMake:
Is it customized to your need or just better?
In the latter case, why not ship cmake with it?
Is testing for debugging libs a very uncommon task?
Are there other ways to accomplish the same thing?
Thanks a lot
Luigi
Mike Jackson wrote:
Here is one I wrote for Expat:
--8
# - Find expat
# Find the native EXPAT headers and libraries.
#
# EXPAT_INCLUDE_DIRS - where to find expat.h, etc.
# EXPAT_LIBRARIES - List of libraries when using expat.
# EXPAT_LIBRARY_DEBUG - Debug version of Library
# EXPAT_LIBRARY_RELEASE - Release Version of Library
# EXPAT_FOUND - True if expat found.
#
# Check the existence of the libraries.
#
# This macro was taken directly from the FindQt4.cmake file that is
included
# with the CMake distribution. This is NOT my work. All work was done by
the
# original authors of the FindQt4.cmake file. Only minor modifications
were
# made to remove references to Qt and make this file more generally
applicable
#
MACRO (ADJUST_LIB_VARS basename)
IF (${basename}_INCLUDE_DIR)
# if only the release version was found, set the debug variable also
to the release version
IF (${basename}_LIBRARY_RELEASE AND NOT ${basename}_LIBRARY_DEBUG)
SET(${basename}_LIBRARY_DEBUG ${${basename}_LIBRARY_RELEASE})
SET(${basename}_LIBRARY ${${basename}_LIBRARY_RELEASE})
SET(${basename}_LIBRARIES ${${basename}_LIBRARY_RELEASE})
ENDIF (${basename}_LIBRARY_RELEASE AND NOT ${basename}_LIBRARY_DEBUG)
# if only the debug version was found, set the release variable
[CMake] build package of subproject with cpack
Hello everybody, is there a way to build a package of sub project with CPACK. I have a Project which consists off different subprojects most shared library projects. The problem is that only the generated top level project include a CPackConfig.cmake file. The CMakeLists.txt files from avery subproject also includes the required CPack-Syntax to build a package. Some Subprojects depends on another subproject. Here is a little example of project structure: TopLevel - ExecutableProject - SubProject1 SharedLibrary - SubProject2 SharedLibrary - ... Thanks Norman -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to use DEFINE_SYMBOL properly?
Well, that is exactly what I expect from CMake, it has
done much more than this until now, this should be easy.
As an example the library Ogre for 3D graphics rendering is
known to support a lot of platforms and as you can see it is the same
thing always:
#if OGRE_PLATFORM == OGRE_PLATFORM_WIN32
# if defined( OGRE_STATIC_LIB )
#define _OgreExport
#define _OgrePrivate
# else
#if defined( OGRE_NONCLIENT_BUILD )
# define _OgreExport __declspec( dllexport )
#else
# if defined( __MINGW32__ )
#define _OgreExport
# else
#define _OgreExport __declspec( dllimport )
# endif
# endif
# define _OgrePrivate
#endif
#if OGRE_PLATFORM == OGRE_PLATFORM_LINUX || \
OGRE_PLATFORM == OGRE_PLATFORM_APPLE || \
OGRE_PLATFORM == OGRE_PLATFORM_IPHONE
# if defined( OGRE_GCC_VISIBILITY )
#define _OgreExport __attribute__ ((visibility(default)))
#define _OgrePrivate __attribute__ ((visibility(hidden)))
# else
#define _OgreExport
#define _OgrePrivate
# endif
#endif
They support every 'big' system like Windows, Linux, MacOS and mobiles
like Symbian and Iphone, and even MinGW.
Your example that they can change this in the future would mean a
massive rebuild of thousands of projects. If CMake supported this, it
would mean a fix in CMake and all the projects based on its build system
would have no problems whatsoever.
Kind regards,
Hilton
On Tue, 9 Feb 2010 09:23:19 -0500
Mike Jackson mike.jack...@bluequartz.net wrote:
Just to get some more clarification, what exactly do you mean by
...this visibility macro turns out to be always the same thing in
every project...,
The only thing you can say for certain is that for the versions of
Visual Studio and GCC _currently_ released the macros seem to stay the
same. There is absolutely NO guarantee that Microsoft, Apple, GNU or
someone else will NOT change that in the future.
So right now the code that needs to be included in your project via a
header file is pretty much boilerplate code and is simple and
straight forward to insert into your project.
Also, if you are converting another non-cmake project to CMake then
how that projects goes about implementing their visibility macros may
be different than how CMake chose to do it.
_
Mike Jackson mike.jack...@bluequartz.net
On Tue, Feb 9, 2010 at 8:59 AM, Hilton Medeiros
medeiros.hil...@gmail.com wrote:
Thanks a lot for the answers.
Indeed, I already knew this macro, but I thought that since this
visibility macro turns out to be always the same thing in every
project, CMake would have it built in. I can't see why this is not
the case yet.
Well, back to #defines...
Thanks again,
Hilton
On Tue, 9 Feb 2010 08:29:36 -0500
Mike Jackson mike.jack...@bluequartz.net wrote:
http://www.cmake.org/Wiki/BuildingWinDLL
_
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Software www.bluequartz.net
Principal Software Engineer Dayton, Ohio
On Tue, Feb 9, 2010 at 8:25 AM, Pau Garcia i Quiles
pgqui...@elpauer.org wrote:
Hello,
You are doing it wrong. You need to create a header file
(myproject_exports.h, for instance) following
http://gcc.gnu.org/wiki/Visibility . If you call your visibility
macro target_EXPORTS, you do not need to modify the value of
DEFINE_SYMBOL at all, CMake will automagically make use of it.
You only need to do set_target_properties( target PROPERTIES
DEFINE_SYMBOL my_visibility_macro ) if you want to use a
different name for the macro (usually because it is an
already-existing project which you are converting to CMake).
On Tue, Feb 9, 2010 at 1:25 PM, Hilton Medeiros
medeiros.hil...@gmail.com wrote:
Hello,
From what I read and understood this DEFINE_SYMBOL property
should be defined like this (or something like this):
On Windows, as shared library:
target_EXPORTS=__declspec(dllexport) On Linux, as shared
library: target_EXPORTS=__attribute__((visibility(default)))
So that I can use this symbol like this:
class target_EXPORTS ExampleClass {...};
But on my machine (Linux, gcc) while building a shared library,
with CMake 2.8.0, I'm getting the error below because CMake is
defining this property with -Dtarget_EXPORTS=0:
error: expected identifier before numeric constant
What am I missing?
Kind regards,
Hilton
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Solution groups and sub projects.
Hello, Isn't SOURCE_GROUP what you are looking for? http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:source_group Hope that helps, Adil On Tue, Feb 9, 2010 at 11:04 AM, Surya Kiran Gullapalli suryakiran.gullapa...@gmail.com wrote: Hello all, This has been asked for quite a few times with no answer and I'm putting the same question again. Do we have the support for solution groups and sub projects with VS generators. I'm using CMake-2.8.0 (I could see there's a bughttp://www.itk.org/Bug/bug_view_page.php?bug_id=6577history=1reported already, but no progress on that) If the feature is not available off the shelf, can we resort to some hacks with CMakeLists.txt file ? Thanks, Surya ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- M. Adil Yalcin Bilkent University - Computer Engineering http://www.cs.bilkent.edu.tr/~yalcin ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to use DEFINE_SYMBOL properly?
CMake can't possibly do this in a good and general way. I'd hate it if it tried!
1. Many projects put much more stuff in the XXX_EXPORTS (or
whatever-it's-called) macros. There's a huge variability, no two projects have
the exact same requirements and conventions.
2. How would the __declspec(import)/__attribute__(visibility(hidden)) come in
if the user-project doesn't use CMake but something else?
There are probably many more issues of which I didn't think of...
Michael
On 9. Feb, 2010, at 16:05 , Hilton Medeiros wrote:
Well, that is exactly what I expect from CMake, it has
done much more than this until now, this should be easy.
As an example the library Ogre for 3D graphics rendering is
known to support a lot of platforms and as you can see it is the same
thing always:
#if OGRE_PLATFORM == OGRE_PLATFORM_WIN32
# if defined( OGRE_STATIC_LIB )
#define _OgreExport
#define _OgrePrivate
# else
#if defined( OGRE_NONCLIENT_BUILD )
# define _OgreExport __declspec( dllexport )
#else
# if defined( __MINGW32__ )
#define _OgreExport
# else
#define _OgreExport __declspec( dllimport )
# endif
# endif
# define _OgrePrivate
#endif
#if OGRE_PLATFORM == OGRE_PLATFORM_LINUX || \
OGRE_PLATFORM == OGRE_PLATFORM_APPLE || \
OGRE_PLATFORM == OGRE_PLATFORM_IPHONE
# if defined( OGRE_GCC_VISIBILITY )
#define _OgreExport __attribute__ ((visibility(default)))
#define _OgrePrivate __attribute__ ((visibility(hidden)))
# else
#define _OgreExport
#define _OgrePrivate
# endif
#endif
They support every 'big' system like Windows, Linux, MacOS and mobiles
like Symbian and Iphone, and even MinGW.
Your example that they can change this in the future would mean a
massive rebuild of thousands of projects. If CMake supported this, it
would mean a fix in CMake and all the projects based on its build system
would have no problems whatsoever.
Kind regards,
Hilton
On Tue, 9 Feb 2010 09:23:19 -0500
Mike Jackson mike.jack...@bluequartz.net wrote:
Just to get some more clarification, what exactly do you mean by
...this visibility macro turns out to be always the same thing in
every project...,
The only thing you can say for certain is that for the versions of
Visual Studio and GCC _currently_ released the macros seem to stay the
same. There is absolutely NO guarantee that Microsoft, Apple, GNU or
someone else will NOT change that in the future.
So right now the code that needs to be included in your project via a
header file is pretty much boilerplate code and is simple and
straight forward to insert into your project.
Also, if you are converting another non-cmake project to CMake then
how that projects goes about implementing their visibility macros may
be different than how CMake chose to do it.
_
Mike Jackson mike.jack...@bluequartz.net
On Tue, Feb 9, 2010 at 8:59 AM, Hilton Medeiros
medeiros.hil...@gmail.com wrote:
Thanks a lot for the answers.
Indeed, I already knew this macro, but I thought that since this
visibility macro turns out to be always the same thing in every
project, CMake would have it built in. I can't see why this is not
the case yet.
Well, back to #defines...
Thanks again,
Hilton
On Tue, 9 Feb 2010 08:29:36 -0500
Mike Jackson mike.jack...@bluequartz.net wrote:
http://www.cmake.org/Wiki/BuildingWinDLL
_
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer Dayton, Ohio
On Tue, Feb 9, 2010 at 8:25 AM, Pau Garcia i Quiles
pgqui...@elpauer.org wrote:
Hello,
You are doing it wrong. You need to create a header file
(myproject_exports.h, for instance) following
http://gcc.gnu.org/wiki/Visibility . If you call your visibility
macro target_EXPORTS, you do not need to modify the value of
DEFINE_SYMBOL at all, CMake will automagically make use of it.
You only need to do set_target_properties( target PROPERTIES
DEFINE_SYMBOL my_visibility_macro ) if you want to use a
different name for the macro (usually because it is an
already-existing project which you are converting to CMake).
On Tue, Feb 9, 2010 at 1:25 PM, Hilton Medeiros
medeiros.hil...@gmail.com wrote:
Hello,
From what I read and understood this DEFINE_SYMBOL property
should be defined like this (or something like this):
On Windows, as shared library:
target_EXPORTS=__declspec(dllexport) On Linux, as shared
library: target_EXPORTS=__attribute__((visibility(default)))
So that I can use this symbol like this:
class target_EXPORTS ExampleClass {...};
But on my machine (Linux, gcc) while building a shared library,
with CMake 2.8.0, I'm getting the error below because CMake is
defining this property with
Re: [CMake] How to use DEFINE_SYMBOL properly?
Everything can be made as an option, nobody would be forced to use this. In fact, this could be a macro with one 'target' argument. It would be your choice to use it: add_visibility_definitions(target) It would choose the 'standard of visibility' to target_EXPORTS and target_IMPORTS, taking into account shared|static linking and the OS, the compiler, the compiler version... I can't remember any project that adds anything more but even in this case you can always concatenate the definitions, the basic is always the same. Kind regards, Hilton On Tue, 9 Feb 2010 16:24:20 +0100 Michael Wild them...@gmail.com wrote: CMake can't possibly do this in a good and general way. I'd hate it if it tried! 1. Many projects put much more stuff in the XXX_EXPORTS (or whatever-it's-called) macros. There's a huge variability, no two projects have the exact same requirements and conventions. 2. How would the __declspec(import)/__attribute__(visibility(hidden)) come in if the user-project doesn't use CMake but something else? There are probably many more issues of which I didn't think of... Michael On 9. Feb, 2010, at 16:05 , Hilton Medeiros wrote: Well, that is exactly what I expect from CMake, it has done much more than this until now, this should be easy. As an example the library Ogre for 3D graphics rendering is known to support a lot of platforms and as you can see it is the same thing always: #if OGRE_PLATFORM == OGRE_PLATFORM_WIN32 # if defined( OGRE_STATIC_LIB ) #define _OgreExport #define _OgrePrivate # else #if defined( OGRE_NONCLIENT_BUILD ) # define _OgreExport __declspec( dllexport ) #else # if defined( __MINGW32__ ) #define _OgreExport # else #define _OgreExport __declspec( dllimport ) # endif # endif # define _OgrePrivate #endif #if OGRE_PLATFORM == OGRE_PLATFORM_LINUX || \ OGRE_PLATFORM == OGRE_PLATFORM_APPLE || \ OGRE_PLATFORM == OGRE_PLATFORM_IPHONE # if defined( OGRE_GCC_VISIBILITY ) #define _OgreExport __attribute__ ((visibility(default))) #define _OgrePrivate __attribute__ ((visibility(hidden))) # else #define _OgreExport #define _OgrePrivate # endif #endif They support every 'big' system like Windows, Linux, MacOS and mobiles like Symbian and Iphone, and even MinGW. Your example that they can change this in the future would mean a massive rebuild of thousands of projects. If CMake supported this, it would mean a fix in CMake and all the projects based on its build system would have no problems whatsoever. Kind regards, Hilton On Tue, 9 Feb 2010 09:23:19 -0500 Mike Jackson mike.jack...@bluequartz.net wrote: Just to get some more clarification, what exactly do you mean by ...this visibility macro turns out to be always the same thing in every project..., The only thing you can say for certain is that for the versions of Visual Studio and GCC _currently_ released the macros seem to stay the same. There is absolutely NO guarantee that Microsoft, Apple, GNU or someone else will NOT change that in the future. So right now the code that needs to be included in your project via a header file is pretty much boilerplate code and is simple and straight forward to insert into your project. Also, if you are converting another non-cmake project to CMake then how that projects goes about implementing their visibility macros may be different than how CMake chose to do it. _ Mike Jackson mike.jack...@bluequartz.net On Tue, Feb 9, 2010 at 8:59 AM, Hilton Medeiros medeiros.hil...@gmail.com wrote: Thanks a lot for the answers. Indeed, I already knew this macro, but I thought that since this visibility macro turns out to be always the same thing in every project, CMake would have it built in. I can't see why this is not the case yet. Well, back to #defines... Thanks again, Hilton On Tue, 9 Feb 2010 08:29:36 -0500 Mike Jackson mike.jack...@bluequartz.net wrote: http://www.cmake.org/Wiki/BuildingWinDLL _ Mike Jackson mike.jack...@bluequartz.net BlueQuartz Softwarewww.bluequartz.net Principal Software Engineer Dayton, Ohio On Tue, Feb 9, 2010 at 8:25 AM, Pau Garcia i Quiles pgqui...@elpauer.org wrote: Hello, You are doing it wrong. You need to create a header file (myproject_exports.h, for instance) following http://gcc.gnu.org/wiki/Visibility . If you call your visibility macro target_EXPORTS, you do not need to modify the value of DEFINE_SYMBOL at all, CMake will automagically make use of it. You only need to do set_target_properties( target PROPERTIES DEFINE_SYMBOL my_visibility_macro ) if you want to use a
[CMake] Building shared library from collection?
Hi folks, first post here as just delving into the world of cmake. My first question is about the structure of my project. It is like so: Project Folder '- Module A '- Module B '- Module C From reading the CMake book it appears I've got 3 options for building. 1) Single makefile at top that lists all the sources with their subdirectories. 2) Have each subdirectory build a library that can then be linked at then end. 3) Mixture of 1 and 2. I choose 3 as I wish to have each module as a library and then link the 3 libraries together to make up the project. Firstly, does this seem feasible i.e. is my understanding of the book correct? Secondly, I managed to build each of the libraries separately but I am unsure of the syntax of how to link them together to create the 'super' library. Any help or pointers in the right direction would be great. Cheers, John. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Sourceless targets
Hello Lists, I have lots of small libraries and sometime it is needed to unify them to a main program library e.g. libtest.so for my test program… I tried ADD_LIBRARY(test-mainlib SHARED ) SET_TARGET_PROPERTIES( test-mainlib PROPERTIES OUPUT_NAME libtest ) But this does not work due to Cannot determine link language for target Thanks for your help! Best Regards C.M. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to findXXX libraries with debug suffix
Mike Jackson wrote:
Here is one I wrote for Expat:
--8
# - Find expat
# Find the native EXPAT headers and libraries.
#
# EXPAT_INCLUDE_DIRS - where to find expat.h, etc.
# EXPAT_LIBRARIES- List of libraries when using expat.
# EXPAT_LIBRARY_DEBUG - Debug version of Library
# EXPAT_LIBRARY_RELEASE - Release Version of Library
# EXPAT_FOUND- True if expat found.
The macro below has been generalized and placed in the standard set of
CMake modules with the 2.8 release. I saw it duplicated in enough places
that I added it for general use in the Modules directory. It's called
SelectLibraryConfigurations, you can get information about it by typing
cmake --help-module SelectLibraryConfigurations. You don't have to use
the standard one, but it's there if you need it. Let me know if you run
into any trouble with it.
-- Will
#
# Check the existence of the libraries.
#
# This macro was taken directly from the FindQt4.cmake file that is included
# with the CMake distribution. This is NOT my work. All work was done by the
# original authors of the FindQt4.cmake file. Only minor modifications were
# made to remove references to Qt and make this file more generally applicable
#
MACRO (ADJUST_LIB_VARS basename)
IF (${basename}_INCLUDE_DIR)
# if only the release version was found, set the debug variable also
to the release version
IF (${basename}_LIBRARY_RELEASE AND NOT ${basename}_LIBRARY_DEBUG)
SET(${basename}_LIBRARY_DEBUG ${${basename}_LIBRARY_RELEASE})
SET(${basename}_LIBRARY ${${basename}_LIBRARY_RELEASE})
SET(${basename}_LIBRARIES ${${basename}_LIBRARY_RELEASE})
ENDIF (${basename}_LIBRARY_RELEASE AND NOT ${basename}_LIBRARY_DEBUG)
# if only the debug version was found, set the release variable also
to the debug version
IF (${basename}_LIBRARY_DEBUG AND NOT ${basename}_LIBRARY_RELEASE)
SET(${basename}_LIBRARY_RELEASE ${${basename}_LIBRARY_DEBUG})
SET(${basename}_LIBRARY ${${basename}_LIBRARY_DEBUG})
SET(${basename}_LIBRARIES ${${basename}_LIBRARY_DEBUG})
ENDIF (${basename}_LIBRARY_DEBUG AND NOT ${basename}_LIBRARY_RELEASE)
IF (${basename}_LIBRARY_DEBUG AND ${basename}_LIBRARY_RELEASE)
# if the generator supports configuration types then set
# optimized and debug libraries, or if the CMAKE_BUILD_TYPE has a value
IF (CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
SET(${basename}_LIBRARY optimized
${${basename}_LIBRARY_RELEASE} debug ${${basename}_LIBRARY_DEBUG})
ELSE(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
# if there are no configuration types and CMAKE_BUILD_TYPE has no value
# then just use the release libraries
SET(${basename}_LIBRARY ${${basename}_LIBRARY_RELEASE} )
ENDIF(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE)
SET(${basename}_LIBRARIES optimized
${${basename}_LIBRARY_RELEASE} debug ${${basename}_LIBRARY_DEBUG})
ENDIF (${basename}_LIBRARY_DEBUG AND ${basename}_LIBRARY_RELEASE)
SET(${basename}_LIBRARY ${${basename}_LIBRARY} CACHE FILEPATH The
${basename} library)
IF (${basename}_LIBRARY)
SET(${basename}_FOUND 1)
ENDIF (${basename}_LIBRARY)
ENDIF (${basename}_INCLUDE_DIR )
# Make variables changeble to the advanced user
MARK_AS_ADVANCED(${basename}_LIBRARY ${basename}_LIBRARY_RELEASE
${basename}_LIBRARY_DEBUG ${basename}_INCLUDE_DIR )
ENDMACRO (ADJUST_LIB_VARS)
# Look for the header file.
# MESSAGE (STATUS Finding expat library and headers... )
SET (EXPAT_DEBUG 0)
SET(EXPAT_INCLUDE_SEARCH_DIRS
$ENV{EXPAT_INSTALL}/include
)
SET (EXPAT_LIB_SEARCH_DIRS
$ENV{EXPAT_INSTALL}/lib
)
SET (EXPAT_BIN_SEARCH_DIRS
$ENV{EXPAT_INSTALL}/bin
)
FIND_PATH(EXPAT_INCLUDE_DIR
NAMES expat.h
PATHS ${EXPAT_INCLUDE_SEARCH_DIRS}
NO_DEFAULT_PATH
)
IF (WIN32 AND NOT MINGW)
SET (EXPAT_SEARCH_DEBUG_NAMES expatdll_D;libexpat_D)
SET (EXPAT_SEARCH_RELEASE_NAMES expatdll;libexpat)
ELSE (WIN32 AND NOT MINGW)
SET (EXPAT_SEARCH_DEBUG_NAMES expat_debug)
SET (EXPAT_SEARCH_RELEASE_NAMES expat)
ENDIF(WIN32 AND NOT MINGW)
IF (EXPAT_DEBUG)
message (STATUS EXPAT_INCLUDE_SEARCH_DIRS: ${EXPAT_INCLUDE_SEARCH_DIRS})
message (STATUS EXPAT_LIB_SEARCH_DIRS: ${EXPAT_LIB_SEARCH_DIRS})
message (STATUS EXPAT_BIN_SEARCH_DIRS: ${EXPAT_BIN_SEARCH_DIRS})
message (STATUS EXPAT_SEARCH_RELEASE_NAMES: ${EXPAT_SEARCH_RELEASE_NAMES})
message (STATUS EXPAT_SEARCH_DEBUG_NAMES: ${EXPAT_SEARCH_DEBUG_NAMES})
ENDIF (EXPAT_DEBUG)
# Look for the library.
FIND_LIBRARY(EXPAT_LIBRARY_DEBUG
NAMES ${EXPAT_SEARCH_DEBUG_NAMES}
PATHS ${EXPAT_LIB_SEARCH_DIRS}
NO_DEFAULT_PATH
)
FIND_LIBRARY(EXPAT_LIBRARY_RELEASE
NAMES ${EXPAT_SEARCH_RELEASE_NAMES}
PATHS ${EXPAT_LIB_SEARCH_DIRS}
NO_DEFAULT_PATH
)
SET (EXPAT_XMLWF_PROG_NAME xmlwf)
Re: [CMake] Sourceless targets
On 9. Feb, 2010, at 17:13 , C. Meissa wrote: Hello Lists, I have lots of small libraries and sometime it is needed to unify them to a main program library e.g. libtest.so for my test program… I tried ADD_LIBRARY(test-mainlib SHARED ) SET_TARGET_PROPERTIES( test-mainlib PROPERTIES OUPUT_NAME libtest ) But this does not work due to Cannot determine link language for target Thanks for your help! Best Regards C.M. IMHO this can't possibly work. I assume that you want to create a shared library from a set of static libraries, right? Well, due to the nature of static linking, you'll need a source file that pulls in all the symbols that you want in your final library, otherwise nothing will happen. What is it exactly you are trying to achieve? Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Sourceless targets
Hello, thx for your reply… Am Dienstag, 9. Februar 2010 schrieb Michael Wild: What is it exactly you are trying to achieve? Well, you got me perfectly right… I like to have all symbols in my static libraries included as is… :-) IMHO this can't possibly work. I assume that you want to create a shared library from a set of static libraries, right? Well, due to the nature of static linking, you'll need a source file that pulls in all the symbols that you want in your final library, otherwise nothing will happen. Ok, so I might have to generate a right sourcefile, right? thx again C.M. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building shared library from collection?
Personally, I prefer a sole CMakeLists.txt for small/medium size
projects. You should not have problems linking your project, this
would be my approach:
list(APPEND LINK_MODULES PATHLIB/libA.a PATHLIB/libB.a PATHLIB/libC.a)
target_link_libraries(super_lib ${LINK_MODULES})
Note that you should use CMake defined paths in 'PATHLIB', e.g.,
${PROJECT_BINARY_DIR}/libA.a
I'm assuming they are static libraries since you said 'modules'.
Also, consider generating the html documentation from your cmake for use
as reference: 'cmake --help-html cmake.html' on the command line.
Cheers,
Hilton
On Tue, 09 Feb 2010 15:03:45 +
John Brydon john-c...@blueyonder.co.uk wrote:
Hi folks,
first post here as just delving into the world of cmake.
My first question is about the structure of my project. It is like so:
Project Folder
'- Module A
'- Module B
'- Module C
From reading the CMake book it appears I've got 3 options for
building. 1) Single makefile at top that lists all the sources with
their subdirectories.
2) Have each subdirectory build a library that can then be linked at
then end.
3) Mixture of 1 and 2.
I choose 3 as I wish to have each module as a library and then link
the 3 libraries together to make up the project.
Firstly, does this seem feasible i.e. is my understanding of the book
correct? Secondly, I managed to build each of
the libraries separately but I am unsure of the syntax of how to link
them together to create the 'super' library.
Any help or pointers in the right direction would be great.
Cheers,
John.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Sourceless targets
On 9. Feb, 2010, at 18:11 , C. Meissa wrote:
Hello,
thx for your reply…
Am Dienstag, 9. Februar 2010 schrieb Michael Wild:
What is it exactly you are trying to achieve?
Well, you got me perfectly right…
I like to have all symbols in my static libraries included as is… :-)
IMHO this can't possibly work. I assume that you want to create a shared
library from a set of static libraries, right? Well, due to the nature of
static linking, you'll need a source file that pulls in all the symbols
that you want in your final library, otherwise nothing will happen.
Ok, so I might have to generate a right sourcefile, right?
thx again
C.M.
Or do away with the static libraries in the first place...
I often do something like this:
lib/A/files.cmake:
--
set(LIB_A_SRCS)
foreach(s srcA1.c srcA2.c srcA3.c)
list(APPEND LIB_A_SRCS ${CMAKE_SOURCE_DIR}/lib/A/${s})
endforeach()
lib/B/files.cmake:
--
set(LIB_B_SRCS)
foreach(s srcB1.c srcB2.c srcB3.c)
list(APPEND LIB_B_SRCS ${CMAKE_SOURCE_DIR}/lib/B/${s})
endforeach()
lib/CMakeLists.txt:
include(A/files.cmake)
include(B/files.cmake)
add_library(superduper ${LIB_A_SRCS} ${LIB_B_SRCS})
HTH
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to turn off incremental linking for MSVC Debug and RelWithDebInfo targets?
It would be great to have an answer on this, did I miss it in the FAQs?
How can we switch off incremental linking for Debug and RelWithDebInfo
target on Windows Visual Studio projects?
Thanks a lot,
Erwin
On 8 February 2010 11:44, Erwin Coumans erwin.coum...@gmail.com wrote:
I've search a while and noticed several similar requests, but couldn't find
a solution that works.
http://www.mail-archive.com/cmake@cmake.org/msg19612.html
http://www.ogre3d.org/forums/viewtopic.php?f=4t=45160
http://www.ogre3d.org/forums/viewtopic.php?t=28115view=previoussid=4671d7d566b65f8a4475bad1da67c78f
STRING(REPLACE INCREMENTAL:YES INCREMENTAL:NO replacementFlags
${CMAKE_EXE_LINKER_FLAGS_DEBUG})
message (${replacementFlags})
SET(CMAKE_SHARED_LINKER_FLAGS_DEBUG ${replacementFlags})
STRING(REPLACE INCREMENTAL:YES INCREMENTAL:NO replacementFlags2
${CMAKE_EXE_LINKER_FLAGS})
message (${replacementFlags2})
SET(CMAKE_EXE_LINKER_FLAGS ${replacementFlag2})
Is there a method using CMake 2.8 or CMake 2.8.1 that works?
Thanks a lot,
Erwin
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to turn off incremental linking for MSVC Debug and RelWithDebInfo targets?
STRING(REPLACE INCREMENTAL:YES INCREMENTAL:NO replacementFlags
${CMAKE_EXE_LINKER_FLAGS_DEBUG})
message (${replacementFlags})
SET(CMAKE_SHARED_LINKER_FLAGS_DEBUG ${replacementFlags})
STRING(REPLACE INCREMENTAL:YES INCREMENTAL:NO replacementFlags2
${CMAKE_EXE_LINKER_FLAGS})
message (${replacementFlags2})
SET(CMAKE_EXE_LINKER_FLAGS ${replacementFlag2})
Is there a method using CMake 2.8 or CMake 2.8.1 that works?
I thought that the following worked in the past since I have this in
my CMakeLists.txt:
SET(CMAKE_EXE_LINKER_FLAGS /INCREMENTAL:NO /MANIFEST /STACK:1000 )
but it appears that this no longer works with cmake 2.8.0. I believe
it worked previously.
I do not have a solution for this yet.
John
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to findXXX libraries with debug suffix
On Tue, Feb 9, 2010 at 11:15 AM, Will Dicharry
wdicha...@stellarscience.com wrote:
Mike Jackson wrote:
Here is one I wrote for Expat:
--8
# - Find expat
# Find the native EXPAT headers and libraries.
#
# EXPAT_INCLUDE_DIRS - where to find expat.h, etc.
# EXPAT_LIBRARIES - List of libraries when using expat.
# EXPAT_LIBRARY_DEBUG - Debug version of Library
# EXPAT_LIBRARY_RELEASE - Release Version of Library
# EXPAT_FOUND - True if expat found.
The macro below has been generalized and placed in the standard set of CMake
modules with the 2.8 release. I saw it duplicated in enough places that I
added it for general use in the Modules directory. It's called
SelectLibraryConfigurations, you can get information about it by typing
cmake --help-module SelectLibraryConfigurations. You don't have to use the
standard one, but it's there if you need it. Let me know if you run into any
trouble with it.
Thank you for adding this and mentioning it! There are probably lots
of modules out there that need to be modified to take advantage of
this.
One minor thing I don't like about the module is this line (70) right here:
set( ${basename}_LIBRARY ${${basename}_LIBRARY} CACHE FILEPATH The
${basename} library)
Presumably users of this module have already called
find_library(${basename}_LIBRARY_RELEASE) and
find_library(${basename}_LIBRARY_DEBUG) since it's expecting these
names. Why then add a 3rd cache variable? If the user were to change
${basename}_LIBRARY_DEBUG after an initial configure, the cache
variable will not get fixed since set() does not operate on cache
variables that have already been initialized unless FORCE is used.
This isn't a major issue since you define a ${basename}_LIBRARY normal
variable which overrides the cache variable immediately above it. At
best, line 70 where you declare the CACHE variable is superfluous. It
could also be a little confusing to some users who change it in the
CACHE and see no effect.
===
My only other comment is that some modules already use the following
form (usually due to someone adding DEBUG support later)
FOO_LIBRARY (cache variable)
FOO_LIBRARY_DEBUG (cache variable)
FOO_LIBRARIES (normal variable with debug/optimized keywords when
FOO_LIBRARY_DEBUG is available, else normal variable set to
FOO_LIBRARY)
It would be nice to see a second macro that supports this format.
Also, the redefinition of FOO_LIBRARY to have optimized release
keywords in it may or may not be desired. The only harm I can see
this causing is if a user were to have done this already in his
CMakeLists.txt. In this case they might find themselves with a CMake
error or linking against liboptimized.so! :)
if(FOO_LIBRARY_DEBUG)
target_link_libraries(bar optimized ${FOO_LIBRARY} debug
${FOO_LIBRARY_DEBUG})
else()
target_link_libraries(bar ${FOO_LIBRARY})
endif()
--
Philip Lowman
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] set “Whole Program Optimization ”to Yes in VS 2005
nbsp;
When I use the blow statement for MSVC:
nbsp;
SET (CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE} /GL)
nbsp;
The corresponding statement in the .vcproj file generated by CMake is:
nbsp;
AdditionalOptions= /Zm1000 /GL
nbsp;
When I open the property pages in VS 2005，I can see /GLnbsp;on the
pagenbsp;on command line, but the item of“Whole Program Optimization”on the
pagenbsp;of Optimization is still No.
nbsp;
Why does not CMake generate WholeProgramOptimization=1 in the .vcproj file?
nbsp;
Thnaks!
nbsp;___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] set “Whole Program Optimization ”to Yes in VS 2005
On Wed, Feb 10, 2010 at 10:51:28AM +0800, xiad...@sina.com wrote:
SET (CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE} /GL)
nbsp;
The corresponding statement in the .vcproj file generated by CMake is:
nbsp;
AdditionalOptions= /Zm1000 /GL
nbsp;
When I open the property pages in VS 2005，I can see /GLnbsp;on the
pagenbsp;on command line, but the item of“Whole Program Optimization”on the
pagenbsp;of Optimization is still No.
nbsp;
Why does not CMake generate WholeProgramOptimization=1 in the .vcproj file?
I've seen a similar case where the CMake-generated .vcproj looked
wrong in the IDE but the compiler was actually using the appropriate
setting (the /DEBUG flag iirc).
It may be that Visual Studio is actually compiling the code with Whole Program
Optimization. Can you check that somehow?
tyler
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] link static lib to dll
Am Dienstag, den 09.02.2010, 11:34 +0100 schrieb Michael Wild:
On 9. Feb, 2010, at 11:05 , Micha Renner wrote:
A DLL-library is linked to static library.
The structure of the project is this:
main-project
+- Project STATIC
|
+- Project DLL
This works very well.
But if I include the following export part to the project of the DLL...
INSTALL(TARGETS T-DLL EXPORT T-DLLExport
RUNTIME DESTINATION dll
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib)
INSTALL(EXPORT T-DLLExport DESTINATION lib/${T-DLL})
... CMake generates the message: CMake Error: INSTALL(EXPORT
TLIBExport ...) includes target T-DLL which requires target
T-Static that is not in the export set.
This is unexpected. I don't want export the static library because it is
already linked to the DLL and it is used only by the DLL.
Micha
But CMake can't know that somebody linking against the DLL won't need the
static library. This is because the static library might contain additional
symbols which are not used directly by any of the code in the DLL, and thus
are not present in there. That's one of the most surprising facts of static
linking...
This is true. Now, I understand the default behavior of CMake (Not bad,
CMake of course).
The solution is to tell CMake explicitly which of the libraries are in the
link interface and thus must be also exported using the
LINK_INTERFACE_LIBRARIES target property of your DLL. Set it to the list of
libraries which appear in the link interface of your library (i.e. NOT the
static library you're talking about). But be careful, if you miss any of the
real dependencies, all hell might break loose at any time, even far in the
future...
Hopeless, I would have never found this solution.
Thank you very much.
Micha
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] set “Whole Program Optimization”to Y es in VS 2005
On Tue, Feb 9, 2010 at 9:51 PM, xiad...@sina.com wrote:
When I use the blow statement for MSVC:
SET (CMAKE_CXX_FLAGS_RELEASE ${CMAKE_CXX_FLAGS_RELEASE} /GL)
The corresponding statement in the .vcproj file generated by CMake is:
AdditionalOptions= /Zm1000 /GL
When I open the property pages in VS 2005，I can see /GL on the page on
command line, but the item of“Whole Program Optimization”on the page of
Optimization is still No.
Why does not CMake generate WholeProgramOptimization=1 in the .vcproj
file?
Not sure, probably an omission. /GL appears to be supported in
cmVS10CLFlagTable.h but not cmLocalVisualStudio7Generator.
Here's a patch
http://public.kitware.com/Bug/view.php?id=10263
P.S.
If it's not clear, CMake not supporting the WholeProgramOptimization
XML tag only affects what the Visual Studio GUI looks like and doesn't
affect the compiling of the code since the /GL shows up in the
additional options line and thus gets added to the command line when
the compiler is run.
--
Philip Lowman
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
