[CMake] [Repost] How to resolve conflicts between local and imported targets?
Hello, A small correction to my previous post (see below). It should have read *local* target wherever I said *custom* target. Anyhow, the actual problem should remain the same: I would need to have local targets override imported targets of the same name. And the only solution I a came up with would be patching cmMakefile.cxx. Before I go on asking for a feature addition to cmake, I'd like to know whether I can solve my problem by other means. Any ideas? Benedikt On Nov 24, 2010, at 12:17 PM, Benedikt Hegner wrote: Hello, I am facing a problem here on conflicts between imported targets and custom targets. Basically I want to override an imported target by a custom target of the same name. A solution like avoiding clashes using NAMESPACE on EXPORT doesn't really work for me as the identical naming is more or less intended (*). Still I've been doing some gymnastics with using NAMESPACE and then 'importing' single targets over into the local 'namespace' . That resulted in a lot of fragile parsing-like code and just didn't work... So I ended up looking into the source code of cmake to see what's going on under the hood. And a new policy like ALLOW_OVERRIDE_IMPORT_TARGETS in cmMakefile would come handy (wouldn't be too different from ALLOW_DUPLICATE_CUSTOM_TARGETS I think). Giving it a quick shot it worked like a charm. Nevertheless I would hope to find a solution using already existing functionality. Maybe you have an idea what to do instead. Thanks, Benedikt (*) The use case is the following: we have a few hundred particle physicists working on a software project with a few MLOC. To facilitate the development we provide a hybrid environment - there is one central installation with a fully built and installed release. And then every user can set up a development area, check out newer package-versions from the repository, which override the ones in the central area, and do his development. At the moment this is handled by a custom build tool which we plan to replace by cmake. For cmake my current approach is having the central area as one project that exports all its targets. And the development area as another project importing these. ___ 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] providing library information, what's the cmake way
On 24-11-2010 at 17:34, in message
ddc068a445e2cc6dcf015e9b84217da0.squir...@webmail.sf-mail.de, Rolf
Eike
Beer e...@sf-mail.de wrote:
On Wed, Nov 24, 2010 at 6:57 AM, Rolf Eike Beer e...@sf-mail.de
wrote:
In KDE we have a macro MACRO_WRITE_BASIC_CMAKE_VERSION_FILE()
which
helps
with
creating a basic version-info file which should be installed along
with
the
Config-file.
It consists of MacroWriteBasicCMakeVersionFile.cmake and
BasicFindPackageVersion.cmake.in which you can find in
http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/ .
I wonder why you use
get_filename_component(_currentListFileDir
${CMAKE_CURRENT_LIST_FILE}
PATH)
in there instead of CMAKE_CURRENT_LIST_DIR.
Probably because CMAKE_CURRENT_LIST_DIR was just invented and is
only
in CMake 2.8.3... get_filename_component works with several
versions
of CMake, and does not require 2.8.3 or later.
So I think it is _really_ necessary to go through all the CMake
documentation items and add a line about when which feature was
added.
Everyone looks into his local CMake documentation and uses what he
finds
in there. And then it breaks on older versions. You currently have
no
chance to know what works but to install all older versions and do a
binary search in the documentation. That simply does not scale.
Eike
That's what CMAKE_MINIMUM_REQUIRED() is for. If you're developing with
CMake 2.8.2, and you want to make sure that you don't use any features
that are not supported by CMake prior to version 2.8.2, you should put
this at the top of your CMakeLists.txt file:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8.2)
But you do have a point. It would really help people developing CMake
files to know whether they can use a given command or not if they want
to support, say, CMake 2.6.0. To be honest, the people at Kitware don't
make that an easy job, because almost every patch-release contains new
features :-(
Best regards,
Marcel Loose.
___
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 CMAKE_INSTALL_PREFIX in CMakeLists
On 24-11-2010 at 17:45, in message 20101124164507.gg23...@cryptio.net, Tyler Roscoe ty...@cryptio.net wrote: On Wed, Nov 24, 2010 at 12:11:56PM +0100, Micha Renner wrote: SET(CMAKE_INSTALL_PREFIX /foo/bar CACHE PATH Foo install prefix) So, without the test to CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT, and without the FORCE option. No, as I mentioned, there was an article of one the CMake-maintainers who recommended this. Micha is correct. CMAKE_INSTALL_PREFIX is set before your CMakeLists.txt is processed, so the above will never do anything. tyler Well, I tested this before I posted my reply. It does work the way I describe it. Try it yourself. Marcel. ___ 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] providing library information, what's the cmake way
2010/11/25 Marcel Loose lo...@astron.nl: Everyone looks into his local CMake documentation and uses what he finds in there. And then it breaks on older versions. You currently have no chance to know what works but to install all older versions and do a binary search in the documentation. That simply does not scale. Eike That's what CMAKE_MINIMUM_REQUIRED() is for. If you're developing with CMake 2.8.2, and you want to make sure that you don't use any features that are not supported by CMake prior to version 2.8.2, you should put this at the top of your CMakeLists.txt file: CMAKE_MINIMUM_REQUIRED(VERSION 2.8.2) Unless I'm wrong this is NOT ensuring what you said. This statement will make CMake shout at you if you try to use CMake version less than the specified version: If the current version of CMake is lower than that required it will stop processing the project and report an error. When a version higher than 2.4 is specified the command implicitly invokes cmake_policy(VERSION major[.minor[.patch]]) which sets the cmake policy version level to the version specified. When version 2.4 or lower is given the command implicitly invokes so the minimum required version is checked and the corrresponding policy is enforced. BUT... this does NOT ensure that while requiring minimum 2.8.2 and you are currently using 2.8.3 (or any later version) your 2.8.3 will behave as if it was 2.8.2. If a new CMake command and/or option for an existing command has been added between 2.8.2 and 2.8.3 but is not subject to some policy then if you use it you won't get a warning. but you'll break your user using CMake 2.8.2. I think that's why Dave said: If you want to support CMake 2.6.4 (or whatever previous version you require, for whatever reason), then you should be using *that* version for your local development, and have that be the cmake_minimum_required version. And use that version to look up documentation... But you do have a point. It would really help people developing CMake files to know whether they can use a given command or not if they want to support, say, CMake 2.6.0. Thus my proposal based on Tyler idea to attach a list of version to each CMake command/variables/properties which contains the first CMake version which included the feature followed by the list of CMake version which modified the behavior/feature. To be honest, the people at Kitware don't make that an easy job, because almost every patch-release contains new features :-( May be they are too-responsive to user request :-] -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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] install guidelines (for multiple versions of the same library)
If I install using this kind of stuff
INSTALL (
FILES ${PROJECT_BINARY_DIR}/H5pubconf.h
DESTINATION ${HDF5_INSTALL_INCLUDE_DIR}
COMPONENT headers
)
and
INSTALL (
EXPORT ${HDF5_EXPORTED_TARGETS}
DESTINATION ${HDF5_INSTALL_LIB_DIR}/cmake/hdf5-${HDF5_PACKAGE_VERSION}
FILE hdf5-targets.cmake
)
Then the hdf5-1.8.5 directory gets created with a version file inside and
everything is lovely. The trouble is that the main headers go into a standard
include place and when I install 1.8.7 over 1.8.5 I have multiple version files
for cmake, but only one set of headers/libs and so everything is munged.
When installing many versions of the same libraries, what is the normal
procedure, seems as though if I add a version postfix to the install location,
I have to change all the find_package stuff too ...
are there any guidelines?
do I use
/usr/lib/hdf5-1.8.5 and
$ENV{ProgramFiles}/HDF5/${version}
etc.
And when I do FIND_PACKAGE(HDF5 1.8.5 REQUIRED NO_MODULE PATHS
$ENV{ProgramFiles}/HDF5)
will it search all sub dirs of the provided path for the right version file
stuff?
thanks
JB
--
John Biddiscombe, email:biddisco @ cscs.ch
http://www.cscs.ch/
CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82
___
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] linking no specified libraries
I currently use mingw and I noticed that in the linking phase the following options appear without specifying nothing of that: -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 How can avoid this? ___ 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] providing library information, what's the cmake way
On Wednesday 24 November 2010 19:03:21 David Cole wrote: On Wed, Nov 24, 2010 at 12:58 PM, Tyler Roscoe ty...@cryptio.net wrote: On Wed, Nov 24, 2010 at 11:41:46AM -0500, David Cole wrote: On Wed, Nov 24, 2010 at 11:34 AM, Rolf Eike Beer e...@sf-mail.de wrote: So I think it is _really_ necessary to go through all the CMake documentation items and add a line about when which feature was added. Adding that information in the documentation would be good, I agree. (Although quite time consuming and costly for somebody...) Perhaps a good compromise is simply to add version information to all new CMake commands/variables/properties that are added henceforth? Thanks, tyler That does sound like a good idea. From the information in http://www.cmake.org/Wiki/CMake_Released_Versions and using some shell-scripts to create the diffs between all neighbor-versions, it's not too much work to create a compatibility matrix for the documented features. I took the liberty and compiled such a compatibility matrix here: http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix It's a draft and does not (yet) contain information about properties and variables, but if this idea receives general consent I could complete the information. What do you think? Is this worth the effort, or would no one ever bother to update the information? cheers, Johannes ___ 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] providing library information, what's the cmake way
On Thursday 25 November 2010, Johannes Zarl wrote: On Wednesday 24 November 2010 19:03:21 David Cole wrote: On Wed, Nov 24, 2010 at 12:58 PM, Tyler Roscoe ty...@cryptio.net wrote: On Wed, Nov 24, 2010 at 11:41:46AM -0500, David Cole wrote: On Wed, Nov 24, 2010 at 11:34 AM, Rolf Eike Beer e...@sf-mail.de wrote: So I think it is _really_ necessary to go through all the CMake documentation items and add a line about when which feature was added. Adding that information in the documentation would be good, I agree. (Although quite time consuming and costly for somebody...) Perhaps a good compromise is simply to add version information to all new CMake commands/variables/properties that are added henceforth? Thanks, tyler That does sound like a good idea. From the information in http://www.cmake.org/Wiki/CMake_Released_Versions and using some shell-scripts to create the diffs between all neighbor-versions, it's not too much work to create a compatibility matrix for the documented features. I took the liberty and compiled such a compatibility matrix here: http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix It's a draft and does not (yet) contain information about properties and variables, but if this idea receives general consent I could complete the information. What do you think? Is this worth the effort, or would no one ever bother to update the information? I think it's cool :-) I for one update the http://www.cmake.org/Wiki/CMake_Released_Versions page manually after each release. Alex ___ 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] providing library information, what's the cmake way
On 11/24/2010 04:51 PM, Johannes Zarl wrote:
Hi,
On 11/23/2010 at 21:25, Alexander Neundorf a.neundorf-w...@gmx.net wrote:
CMAKE_MODULE_PATH is only for finding Find-modules, not for finding the
actual packages or Config-files.
For that you can set CMAKE_PREFIX_PATH. CMake uses each directory contained
in CMAKE_PREFIX_PATH for all its find_program/file/path/library/package()
calls to search in the respective subdirectories for the
executables/files/libraries/Config-files.
Thanks for this information! Knowing this greatly simplifies the whole
find_package stuff...
And is there any documentation on how to create a LibraryConfig.cmake file
with support for components?
In KDE we have a macro MACRO_WRITE_BASIC_CMAKE_VERSION_FILE() which helps
with creating a basic version-info file which should be installed along
with the Config-file.
It consists of MacroWriteBasicCMakeVersionFile.cmake and
BasicFindPackageVersion.cmake.in which you can find in
http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/ .
Nice to have some reusable code for versioning...
About the components question again: I played around a bit, and I think I
now more or less have comprehended this. I guess for a package XXX with
components YYY and ZZZ, one could set variables XXX_HAS_YYY and XXX_HAS_ZZZ
and then use a loop like this one in the XXXConfig.cmake file:
foreach( component ${XXX_FIND_COMPONENTS} )
if ( XXX_HAS_${component})
set ( XXX_${component}_FOUND TRUE )
else( XXX_HAS_${component})
if ( ${XXX_FIND_REQUIRED})
message(FATAL_ERROR Required component ${component} not found!)
elseif ( NOT XXX_FIND_QUIETLY)
message(STATUS Component ${component} not found!)
endif ( ${XXX_FIND_REQUIRED})
endif ( XXX_HAS_${component})
endforeach( component )
Correct?
While that's a possible approach it lacks the invocation-specific
variables, i.e. XXX_{INCLUDE_DIRS,LIBRARIES,DEFINITIONS}, and in
some cases, these can't be assembled in a simple component-wise
manner, see below. Moreover, there are further questions w.r.t.
multi-component packages and their config files:
- Does the config file provide the component-specific variables like
XXX_YYY_FOUND for each available component or for the requested ones
only, i.e. can you rely on XXX_ZZZ_FOUND to have a definite value if
you just said FIND_PACKAGE(XXX COMPONENTS YYY)? With your foregoing
approach, you can't. That's alright, but should be mentioned in the
package's documentation. Imagine the following scenario: There's one
installation of XXX for the native system and another one for cross
compiling purposes. The latter has YYY and ZZZ while the former has
YYY only. Due to FIND_PACKAGE()'s ability to search for config files
in various locations, such a coexistence is easily possible. Now, a
FIND_PACKAGE(XXX COMPONENTS YYY ZZZ) for the cross compilation XXX
returns with XXX_ZZZ_FOUND=TRUE, but does a subsequent invocation of
FIND_PACKAGE(XXX COMPONENTS YYY) within the same scope for the native
XXX return with XXX_ZZZ_FOUND=FALSE, or does XXX_ZZZ_FOUND=TRUE still
hold from the previous invocation? Both alternatives are fine, but the
user should know the score. Besides, it's a good style to refer to any
component-related variables only if the particular component has been
requested explicitly.
- Handling of inter-component dependencies: Imagine the user just says
FIND_PACKAGE(XXX COMPONENTS ZZZ), but ZZZ needs YYY. If YYY is to be
enabled automatically the config file must know about the dependency
and cannot simply add the ZZZ-specific variables to the invocation-
specific ones; the YYY-specific variables must be mentioned, too.
- Do multiple consecutive FIND_PACKAGE(XXX ...) invocations act in an
accumulative manner on the invocation-specific variables? E.g., does
FIND_PACKAGE(XXX COMPONENTS YYY)
FIND_PACKAGE(XXX COMPONENTS ZZZ)
result in XXX_LIBRARIES=${XXX_YYY_LIBRARY} ${XXX_ZZZ_LIBRARY}, or
does the second invocation overwrite the results of the first? Again,
both alternatives are fine, but should be documented. That's important
when there are required and optional components to handle: Imagine YYY
is required while ZZZ is optional for the user; one might tend to say
FIND_PACKAGE(XXX REQUIRED YYY)
FIND_PACKAGE(XXX COMPONENTS ZZZ)
instead of
FIND_PACKAGE(XXX COMPONENTS YYY ZZZ)
IF(NOT XXX_YYY_FOUND)
MESSAGE(FATAL_ERROR ...)
ENDIF()
When turning towards find modules, the situation becomes even more
complicated. From a user's perspective, find modules and config files
should behave the same, but the formers can't know which components are
available, so they must look for them; this gives rise to questions like:
- Meaning of the REQUIRED and QUIET options: When a find module looks
for any component the effects of REQUIRED and QUIET depend on whether
the component has been requested explicitly or not. If it hasn't, the
find module mustn't bail out if the component
Re: [CMake] set_source_files_properties for includedirectories
On 11/23/2010 03:23 PM, Andrea Galeazzi wrote: Marcel Loose ha scritto: On 23-11-2010 at 10:55, in message 4ceb8f76.80...@korg.it, Andrea Galeazzi galea...@korg.it wrote: In a project I've got two groups of files having different include paths. These paths have some conflicts so I need to specify just one for each file requires it. My first idea was to apply set_source_files_properties with a property like include_directories but I don't find anything similar. My next attempt is gonna use the COMPILE_FLAGS property, does anybody know a more efficient and elegant way to accomplish a such task? An equivalent issue was discussed in this thread http://www.mail-archive.com/cmake@cmake.org/msg05276.html but I didn't find any useful 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 Hi Andrea, As you noted include_directories is a per-directory setting. So, if you're free to reorganize your source files, you could put the two groups of files in two different directories. Then you can use include_directories() in each directory. Make sure you don't make one of these directories a subdirectory of the other. HTH, Marcel Loose. __ Informazioni da ESET NOD32 Antivirus, versione del database delle firme digitali 5639 (20101122) __ Il messaggio è stato controllato da ESET NOD32 Antivirus. www.nod32.it Yes, the sources are splitted in different directories but the CMakeLists.txt is just one: -Root CMakeLists.txt -dir1 file1.cpp file2.cpp .. -dir2 file1.cpp file2.cpp . I'd like to generate just one IDE project from this project. FYI, see [1] and especially [2]. Regards, Michael [1] http://public.kitware.com/Bug/view.php?id=1968 [2] http://public.kitware.com/Bug/view.php?id=8189 ___ 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
