Re: [CMake] problem compiling with cmake
On 03/28/2011 04:47 PM, João Oliveira wrote: Hello, I am a student of Instituto Politecnico de Castelo Branco from Portugal and I having some problems compiling it is necessary to run the toolbox PCL. I am using cmake 2.8.4 and when I try to compile cminpack 1.0.4 the following error appears: Check for working C compiler using: Visual Studio 10 Check for working C compiler using: Visual Studio 10 -- works Detecting C compiler ABI info Detecting C compiler ABI info - done Check for working CXX compiler using: Visual Studio 10 Check for working CXX compiler using: Visual Studio 10 -- works Detecting CXX compiler ABI info Detecting CXX compiler ABI info - done Operating system is Windows Building static libraries. Check for working Fortran compiler using: Visual Studio 10 Check for working Fortran compiler using: Visual Studio 10 -- broken CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:40 (MESSAGE): The Fortran compiler ifort is not able to compile a simple test program. It fails with the following output: Change Dir: C:/cminpack-1.0.4_build/CMakeFiles/CMakeTmp Run Build Command:C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe cmTryCompileExec.vcxproj /p:Configuration=Debug Microsoft (R) Build Engine Version 4.0.30319.1 [Microsoft .NET Framework, Version 4.0.30319.1] Copyright (C) Microsoft Corporation 2007. All rights reserved. Build started 28-03-2011 15:39:29. Project C:\cminpack-1.0.4_build\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj on node 1 (default targets). InitializeBuildStatus: Creating cmTryCompileExec.dir\Debug\cmTryCompileExec.unsuccessfulbuild because AlwaysCreate was specified. ManifestResourceCompile: C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\rc.exe /nologo /focmTryCompileExec.dir\Debug\cmTryCompileExec.exe.embed.manifest.res cmTryCompileExec.dir\Debug\cmTryCompileExec_manifest.rc Link: C:\Program Files\Microsoft Visual Studio 10.0\VC\bin\link.exe /ERRORREPORT:QUEUE /OUT:C:\cminpack-1.0.4_build\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec.exe /VERSION:0.0 /INCREMENTAL /NOLOGO /MANIFEST /ManifestFile:cmTryCompileExec.dir\Debug\cmTryCompileExec.exe.intermediate.manifest /MANIFESTUAC:level='asInvoker' uiAccess='false' /PDB:C:\cminpack-1.0.4_build\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec.pdb /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:C:/cminpack-1.0.4_build/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.lib /MACHINE:X86 cmTryCompileExec.dir\Debug\cmTryCompileExec.exe.embed.manifest.res LINK : error LNK2001: unresolved external symbol _mainCRTStartup [C:\cminpack-1.0.4_build\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj] C:\cminpack-1.0.4_build\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec.exe : fatal error LNK1120: 1 unresolved externals [C:\cminpack-1.0.4_build\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj] Done Building Project C:\cminpack-1.0.4_build\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj (default targets) -- FAILED. Build FAILED. C:\cminpack-1.0.4_build\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj (default target) (1) - (Link target) - LINK : error LNK2001: unresolved external symbol _mainCRTStartup [C:\cminpack-1.0.4_build\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj] C:\cminpack-1.0.4_build\CMakeFiles\CMakeTmp\Debug\cmTryCompileExec.exe : fatal error LNK1120: 1 unresolved externals [C:\cminpack-1.0.4_build\CMakeFiles\CMakeTmp\cmTryCompileExec.vcxproj] 0 Warning(s) 2 Error(s) Time Elapsed 00:00:00.37 CMake will not be able to correctly generate this project. Call Stack (most recent call first): examples/CMakeLists.txt:31 (enable_language) Configuring incomplete, errors occurred! already communicated with the users http://www.willowgarage.com/ and forward my question to you all. grateful to give me some help. According to a previous user of the site: problem is solved with ifort 10.1. Sorry, ifort is the intel fortran compiler embedded with Microsoft Visual Studio, I am not sure how you can upgrade or if someone else solved this issue but you may email cmake users and see if somebody can help you out. Once again I would appreciate help. carefully, João Oliveira http://www.cmake.org/Bug/view.php?id=11517 Regards, 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] set_target_properties not setting COMPILE_DEFINITIONS?
On 03/28/2011 08:23 PM, David Doria wrote:
I have setup a list of definitions:
SET(MAIN_BUILD_DEFINITIONS ${MAIN_BUILD_DEFINITIONS} UNIX;)
SET(MAIN_BUILD_DEFINITIONS ${MAIN_BUILD_DEFINITIONS} PIXEL_DIMENSION=3;)
I display them and apply them to my executable as follows:
add_executable(ImageCompleter ${MainSources})
message(Main build definitions: ${MAIN_BUILD_DEFINITIONS})
set_target_properties(ImageCompleter PROPERTIES COMPILE_DEFINITIONS
${MAIN_BUILD_DEFINITIONS})
The output is:
Main build definitions: UNIX PIXEL_DIMENSION=3
which looks correct (i.e. UNIX was defined)
However, in my code there is:
#if defined(UNIX)
... some code...
#else
#error Not implemented for this platform!
#endif
When I build, the error is produced, indicating that UNIX was not defined.
I created a small standalone example and it worked as expected... any
suggestions of what else to check?
Thanks,
David
AFAICS, you mess up the value of the MAIN_BUILD_DEFINITIONS
list variable. Look at the following CMakeLists.txt file:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(COMPDEFS C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
SET(MAIN_BUILD_DEFINITIONS
${MAIN_BUILD_DEFINITIONS} UNIX;)
LIST(LENGTH MAIN_BUILD_DEFINITIONS n)
MESSAGE(MAIN_BUILD_DEFINITIONS: ${MAIN_BUILD_DEFINITIONS} -- n=${n})
SET(MAIN_BUILD_DEFINITIONS
${MAIN_BUILD_DEFINITIONS} PIXEL_DIMENSION=3;)
LIST(LENGTH MAIN_BUILD_DEFINITIONS n)
MESSAGE(MAIN_BUILD_DEFINITIONS: ${MAIN_BUILD_DEFINITIONS} -- n=${n})
SET_TARGET_PROPERTIES(main PROPERTIES
COMPILE_DEFINITIONS ${MAIN_BUILD_DEFINITIONS})
CMake's output contains:
MAIN_BUILD_DEFINITIONS: UNIX; -- n=2
MAIN_BUILD_DEFINITIONS: UNIX; PIXEL_DIMENSION=3; -- n=3
Provided that MAIN_BUILD_DEFINITIONS is initially empty, the command
SET(MAIN_BUILD_DEFINITIONS ${MAIN_BUILD_DEFINITIONS} UNIX;) makes
MAIN_BUILD_DEFINITIONS a list of *two* elements: UNIX - note the
leading blank - and the empty string , and the second SET() adds
PIXEL_DIMENSION=3. Probably, this is not what you intended. ;)
Instead, try
LIST(APPEND MAIN_BUILD_DEFINITIONS UNIX)
LIST(APPEND MAIN_BUILD_DEFINITIONS PIXEL_DIMENSION=3)
and CMake's output changes to
MAIN_BUILD_DEFINITIONS: UNIX -- n=1
MAIN_BUILD_DEFINITIONS: UNIX;PIXEL_DIMENSION=3 -- n=2
which should work when used as COMPILE_DEFINITIONS property.
IMO, the rule of thumb is: Don't use semicolons explicitly in SET()
commands to assign list variables, but let CMake do this by itself.
Moreover, be particularly careful when SETting list values, e.g.
SET(A1 a)
SET(AB1 ${A1} b)
LIST(LENGTH AB1 n)
MESSAGE(AB1: ${AB1} -- n=${n})
SET(A2 a a)
SET(AB2 ${A2} b)
LIST(LENGTH AB2 n)
MESSAGE(AB2: ${AB2} -- n=${n})
results in
AB1: a b -- n=1
AB2: a;a b -- n=2
i.e. AB1 is a non-list value which might by unexpected, and AB2 remains
a list with just two elements which might be unexpected, too. Here, the
correct coding is SET(AB1 ${A1} b) and SET(AB2 ${A2} b) which
could nevertheless lead to AB{1,2} being lists of length two with an
empty first element if AB{1,2} have been empty before. When adding
elements to lists it's best to use the LIST(APPEND ...) command.
BTW, I can see the abovementioned CMakeLists.txt work correctly with
CMake 2.8.4, so what version of CMake do you use for your project?
Regards,
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] set_target_properties not setting COMPILE_DEFINITIONS?
On 03/29/2011 07:47 AM, Michael Hertling wrote:
On 03/28/2011 08:23 PM, David Doria wrote:
I have setup a list of definitions:
SET(MAIN_BUILD_DEFINITIONS ${MAIN_BUILD_DEFINITIONS} UNIX;)
SET(MAIN_BUILD_DEFINITIONS ${MAIN_BUILD_DEFINITIONS} PIXEL_DIMENSION=3;)
I display them and apply them to my executable as follows:
add_executable(ImageCompleter ${MainSources})
message(Main build definitions: ${MAIN_BUILD_DEFINITIONS})
set_target_properties(ImageCompleter PROPERTIES COMPILE_DEFINITIONS
${MAIN_BUILD_DEFINITIONS})
The output is:
Main build definitions: UNIX PIXEL_DIMENSION=3
which looks correct (i.e. UNIX was defined)
However, in my code there is:
#if defined(UNIX)
... some code...
#else
#error Not implemented for this platform!
#endif
When I build, the error is produced, indicating that UNIX was not defined.
I created a small standalone example and it worked as expected... any
suggestions of what else to check?
Thanks,
David
AFAICS, you mess up the value of the MAIN_BUILD_DEFINITIONS
list variable. Look at the following CMakeLists.txt file:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(COMPDEFS C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
SET(MAIN_BUILD_DEFINITIONS
${MAIN_BUILD_DEFINITIONS} UNIX;)
LIST(LENGTH MAIN_BUILD_DEFINITIONS n)
MESSAGE(MAIN_BUILD_DEFINITIONS: ${MAIN_BUILD_DEFINITIONS} -- n=${n})
SET(MAIN_BUILD_DEFINITIONS
${MAIN_BUILD_DEFINITIONS} PIXEL_DIMENSION=3;)
LIST(LENGTH MAIN_BUILD_DEFINITIONS n)
MESSAGE(MAIN_BUILD_DEFINITIONS: ${MAIN_BUILD_DEFINITIONS} -- n=${n})
SET_TARGET_PROPERTIES(main PROPERTIES
COMPILE_DEFINITIONS ${MAIN_BUILD_DEFINITIONS})
CMake's output contains:
MAIN_BUILD_DEFINITIONS: UNIX; -- n=2
MAIN_BUILD_DEFINITIONS: UNIX; PIXEL_DIMENSION=3; -- n=3
Provided that MAIN_BUILD_DEFINITIONS is initially empty, the command
SET(MAIN_BUILD_DEFINITIONS ${MAIN_BUILD_DEFINITIONS} UNIX;) makes
MAIN_BUILD_DEFINITIONS a list of *two* elements: UNIX - note the
leading blank - and the empty string , and the second SET() adds
PIXEL_DIMENSION=3. Probably, this is not what you intended. ;)
Instead, try
LIST(APPEND MAIN_BUILD_DEFINITIONS UNIX)
LIST(APPEND MAIN_BUILD_DEFINITIONS PIXEL_DIMENSION=3)
and CMake's output changes to
MAIN_BUILD_DEFINITIONS: UNIX -- n=1
MAIN_BUILD_DEFINITIONS: UNIX;PIXEL_DIMENSION=3 -- n=2
which should work when used as COMPILE_DEFINITIONS property.
IMO, the rule of thumb is: Don't use semicolons explicitly in SET()
commands to assign list variables, but let CMake do this by itself.
Moreover, be particularly careful when SETting list values, e.g.
SET(A1 a)
SET(AB1 ${A1} b)
LIST(LENGTH AB1 n)
MESSAGE(AB1: ${AB1} -- n=${n})
SET(A2 a a)
SET(AB2 ${A2} b)
LIST(LENGTH AB2 n)
MESSAGE(AB2: ${AB2} -- n=${n})
results in
AB1: a b -- n=1
AB2: a;a b -- n=2
i.e. AB1 is a non-list value which might by unexpected, and AB2 remains
a list with just two elements which might be unexpected, too. Here, the
correct coding is SET(AB1 ${A1} b) and SET(AB2 ${A2} b) which
could nevertheless lead to AB{1,2} being lists of length two with an
empty first element if AB{1,2} have been empty before. When adding
Oops: ... if A{1,2} have been empty before., to be exact. 8-0
elements to lists it's best to use the LIST(APPEND ...) command.
BTW, I can see the abovementioned CMakeLists.txt work correctly with
CMake 2.8.4, so what version of CMake do you use for your project?
Regards,
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] Different CMAKE_CXX_FLAGS for different executables
On 03/24/2011 03:44 PM, David Doria wrote: Is there a way to explicitly set the CMAKE_CXX_FLAGS for a particular executable? That is, if I set CMAKE_CXX_FLAGS and then have a add_executable line, then change CMAKE_CXX_FLAGS and then have another add_executable, will the first set of CMAKE_CXX_FLAGS be applied to the first executable and the second set of CMAKE_CXX_FLAGS be applied to the second executable? AFAIK, CMAKE_CXX_FLAGS et al. are special in as much as the last value they receive within a CMakeLists.txt file is effective for all targets defined in that file, i.e. they undergo a kind of lazy evaluation. So, the answer to your question is: No, you can't specify CMAKE_CXX_FLAGS individually for targets within the same CMakeLists.txt, but you can specify them per directory, i.e. individually in each CMakeLists.txt. Nevertheless, CMAKE_CXX_FLAGS should be considered as project-wide settings, IMO. I guess my confusion is that I don't understand how CMake variables are cached. Each time I modify the variable, should I do it using SET(CMAKE_CXX_FLAGS some flags) or SET(CMAKE_CXX_FLAGS some flags CACHE STRING compiler flags) ? See [1] for a consideration of SET() w.r.t. the cache and scopes. In this example: http://codepad.org/PGJRBjss [...] ATM, that site seems to be offline. Could you post the example here? Regards, Michael [1] http://www.mail-archive.com/cmake@cmake.org/msg29869.html et seq. ___ 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] Different CMAKE_CXX_FLAGS for different executables
On 03/24/2011 11:39 PM, David Doria wrote:
On Thu, Mar 24, 2011 at 11:31 AM, Yuri Timenkov y...@timenkov.ru wrote:
Use COMPILE_FLAGS target property. Like this:
set_target_properties(Exec2 PROPERTIES COMPILE_FLAGS /flag1 /flag2)
You can see full list of properties in CMake documentation. Note that
compiler flags may be also set for particular source file with
set_source_files_properties command.
Hi Yuri,
I tried a CMakeLists.txt file like this:
cmake_minimum_required(VERSION 2.6)
PROJECT(SetTargetProperties)
ADD_EXECUTABLE(SetTargetProperties SetTargetProperties.cxx)
set_target_properties(SetTargetProperties PROPERTIES COMPILE_FLAGS -DUNIX)
Then I ran:
make VERBOSE=1
and I don't see anything in the output that indicates that this flag
was passed, but I also don't see the call to g++ at all. How would I
check that this worked correctly?
Could you post the output of make VERBOSE=1?
On *nix, the following CMakeLists.txt works as expected:
cmake_minimum_required(VERSION 2.6)
PROJECT(SetTargetProperties)
FILE(WRITE ${CMAKE_BINARY_DIR}/SetTargetProperties.cxx
int main(){return 0;}\n)
ADD_EXECUTABLE(SetTargetProperties SetTargetProperties.cxx)
set_target_properties(SetTargetProperties PROPERTIES COMPILE_FLAGS -DUNIX)
The output of make VERBOSE=1 contains:
.../c++ -DUNIX -o .../SetTargetProperties.cxx.o -c .../SetTargetProperties.cxx
BTW, preprocessor definitions like -DUNIX should be set via the
COMPILE_DEFINITIONS properties instead of the COMPILE_FLAGS ones.
Regards,
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] FIND_LIBRARY and PATH_SUFFIXES: documentation or implementation bug
On 03/24/2011 10:55 AM, Marcel Loose wrote:
Hi all,
I stumbled upon this issue, while trying to track down why
FindPythonLibs finds the static library libpython2.6.a
in /usr/lib64/python2.6/config, instead of the shared library
libpython2.6.so in /usr/lib64 on my system.
On my system, there is /usr/lib/python2.5/config/libpython2.5.a and
/usr/lib/libpython2.5.so, and a FIND_PACKAGE(PythonLibs) results in
PYTHON_LIBRARY==/usr/lib/libpython2.5.so. This is expected since the
first non-WIN32-specific FIND_LIBRARY() in FindPythonLibs.cmake does
not have PATH_SUFFIXES, so it doesn't look into the config directory
of the Python installations. However, if PYTHON_LIBRARY contains the
static .../pythonX.Y/config/libpythonX.Y.a, this usually means that
the first FIND_LIBRARY() has failed, so what is the result of a
FIND_LIBRARY(RESULT python2.6) on your system?
The find module uses PATH_SUFFIXES python${_CURRENT_VERSION}/config,
which in my case expands to python2.6/config. The documentation of
find_library() reads:
PATH_SUFFIXES specifies additional subdirectories to check below
each search path
Additional(!) subdirectories. However, if I do an strace I notice that
*only* the directories with the path suffixes are searched, not the
directories in the search path *without* the suffixes.
AFAICS, this is not true, see cmFindBase::AddPathSuffixes(). The paths
with the additional suffixes are searched first, but the paths without
the suffixes are considered, too. Look at the following CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(PATHSUFFIXES NONE)
FILE(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/lib/config)
FILE(WRITE ${CMAKE_BINARY_DIR}/lib/libxyz.so )
FILE(WRITE ${CMAKE_BINARY_DIR}/lib/config/libxyz.a )
SET(CMAKE_PREFIX_PATH ${CMAKE_BINARY_DIR})
FIND_LIBRARY(XYZ1 xyz PATH_SUFFIXES config)
MESSAGE(XYZ1: ${XYZ1})
SET(CMAKE_FIND_LIBRARY_SUFFIXES .so)
FIND_LIBRARY(XYZ2 xyz PATH_SUFFIXES config)
MESSAGE(XYZ2: ${XYZ2})
This yields:
XYZ1: ${CMAKE_BINARY_DIR}/lib/config/libxyz.a
XYZ2: ${CMAKE_BINARY_DIR}/lib/libxyz.so
The first call of FIND_LIBRARY() looks for libxyz.so and libxyz.a in
${CMAKE_BINARY_DIR}/lib/config and ${CMAKE_BINARY_DIR}/lib and finds
${CMAKE_BINARY_DIR}/lib/config/libxyz.a, but the second FIND_LIBRARY()
call only looks for libxyz.so and finds it in ${CMAKE_BINARY_DIR}/lib.
If the paths without the additional suffix are not taken into account,
this second call would fail.
Regards,
Michael
Is this a bug in the documentation or a bug in the implementation of
CMake?
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] Building a DLL and test driver EXE using CMake -- error by design?
On 03/23/2011 03:21 PM, Chris Volpe ARA/SED wrote: You might break this transitivity by explicitly setting the LINK_INTERFACE_LIBRARIES target properties of FeatureViewer to That did it Thanks, Michael. That's exactly what I needed. It's somewhat moot now, but your second suggestion confused me, and I'd like to understand better: As an alternative, you might use a second invocation TARGET_LINK_LIBRARIES(FeatureViewer TARGET_LINK_LIBRARIES ...) Oops: TARGET_LINK_LIBRARIES(FeatureViewer LINK_INTERFACE_LIBRARIES ...) Two questions: 1. Does a second invocation override the first invocation? 2. If I remove the VTK libs from this command, wouldn't that leave FeatureViewer with unresolved symbols? No, for both questions. Each shared library target has a set of transitive libraries, i.e. libraries other targets are additionally linked against if they are linked against the shared library target. As a default, this set consists of those libraries mentioned in the shared library target's TARGET_LINK_LIBRARIES() command invocation. Nevertheless, if the LINK_INTERFACE_LIBRARIES target property has a defined value, this is used for the set of transitive libraries. Now, TARGET_LINK_LIBRARIES() with the LINK_INTERFACE_LIBRARIES clause just adds the specified libraries to the aforementioned property without an impact on the libraries the target is actually linked against. Hence, a second invocation with LINK_INTERFACE_LIBRARIES clause would affect the TestDriver and further depending targets, but not the FeatureViewer one. Regards, Michael Thanks again for your help!! -Chris -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Michael Hertling Sent: Tuesday, March 22, 2011 7:30 PM To: cmake@cmake.org Subject: Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design? [my original elided for brevity --CRV] The TARGET_LINK_LIBRARIES() command works transitively, i.e. TestDriver will be linked against each shared library that FeatureViewer is linked against, too. You might break this transitivity by explicitly setting the LINK_INTERFACE_LIBRARIES target properties of FeatureViewer to or, in general, to the set of libraries which are still to be linked transitively. As an alternative, you might use a second invocation TARGET_LINK_LIBRARIES(FeatureViewer TARGET_LINK_LIBRARIES ...) in FeatureViewer/CMakeLists.txt to explicitly specify the transitive libraries. Of course, the VTK ones should not appear in these lists. 'hope that helps. Regards, 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] Building a DLL and test driver EXE using CMake -- error by design?
On 03/23/2011 05:26 PM, Chris Volpe ARA/SED wrote:
Jc-
Thanks for the suggestions, but it's not clear if your suggestions are
general suggestions, or if they actually address the problem I'm
experiencing. Moreover, the problems that your suggestions claim to solve
seem to be problems that I am not experiencing.
[...]
Also:
Moreover, in your example, it seems the command LINK_DIRECTORIES is
missing. Indeed, you should add the following command before calling
ADD_LIBRARY(FeatureViewer ...):
LINK_DIRECTORIES(${VTK_LIBRARY_DIRS})
What problem does LINK_DIRECTORIES solve? Note that I have no problem
building FeatureViewer: It finds the VTK libraries just fine without
LINK_DIRECTORIES. Again, the TestDriver application builds and runs just fine
if I manually remove the references to vtk*.lib in its project settings.
LINK_DIRECTORIES() can be subtly dangerous, see [1], so it should not
be used if it's avoidable. AFAICS, VTK uses imported targets for its
libraries, i.e. with full paths in the libraries' IMPORTED_LOCATION
properties, so there shouldn't be a need to use LINK_DIRECTORIES()
w.r.t. VTK.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg33519.html
___
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 place all executables in /build/bin directory
On 03/22/2011 11:33 PM, Jean-Christophe Fillion-Robin wrote:
Hi Arvind,
As documented
herehttp://www.cmake.org/cmake/help/cmake2.6docs.html#variable:CMAKE_RUNTIME_OUTPUT_DIRECTORY,
set the variable CMAKE_RUNTIME_OUTPUT_DIRECTORY instead.
Usually I set this one just after I invoke PROJECT() command.
In fact, these variables have the usual directory scope, so they don't
affect directories entered by ADD_SUBDIRECTORY() before they've been
set. Hence, set CMAKE_RUNTIME_OUTPUT_DIRECTORY before calling the
ADD_SUBDIRECTORY(Exec) command.
Regards,
Michael
Indeed, as specified
herehttp://www.cmake.org/cmake/help/cmake2.6docs.html#variable:EXECUTABLE_OUTPUT_PATH,
EXECUTABLE_OUTPUT_PATH has been deprecated since cmake 2.6.
Jc
On Tue, Mar 22, 2011 at 6:12 PM, Arvind Rao arvind.s...@gmail.com wrote:
Hi All,
I have what should be a simple issue. I have successfully built a project
using CMAKE(out of source build). The executables are all placed in the
Project/build/Exec. But I want them placed in Project/build/bin/ instead.
Toward this end, I set the EXECUTABLE_OUTPUT_PATH, in the top-level
CMakeList file, like so:
cmake_minimum_required(VERSION 2.6)
project(EXAMPLE)
set(CMAKE_CXX_FLAGS -Wall)
add_subdirectory(Exec)
set( EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/bin )
The result is that the executables are all placed in /Project/build/Exec,
whether Project/build/bin exists or not. Does anyone have ideas?
Best wishes,
Arvind
___
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 a DLL and test driver EXE using CMake -- error by design?
On 03/22/2011 03:16 PM, Chris Volpe ARA/SED wrote:
I posted this question in the VTK Users mailing list originally, but have
since determined that it is more of a CMake issue than a VTK issue, and the
involvement of VTK is only tangential.
I am trying to set up a source tree which will allow CMake to create a MSVC++
.sln file that contains the following two projects:
1. A DLL (called FeatureViewer) containing a vanilla C++ class that
links against several VTK kits (Graphics, Rendering, and Hybrid).
2. An EXE (called TestDriver) that links against the aforementioned
library containing the vanilla C++ class.
I want to deliver the DLL, LIB, and class header file from (1) above (as well
as the dependent VTK DLLs) to a co-worker who has his own application and
wants to use the functionality I'm encapsulating, but he doesn't want to
vtk-ify his build process. The EXE in (2) above is simply my test driver
for (1).
My problem is that the EXE won't build because the generated project is
spuriously looking for vtk libraries (e.g. vtkGraphics.lib et. al.) at link
time that it doesn't directly reference, and it doesn't know where to find
them. The EXE shouldn't need to know about them because their use is strictly
within the FeatureViewer library. If I go into the EXE project properties and
manually delete the references to vtkGraphics.lib et. al. from the
linker-input-additional-dependencies list, it works.
At first, I thought I was just doing something wrong in my CMakeLists.txt
files, but page 25 of the CMake User's Guide suggests that this behavior is
by design.
The example given is:
add_library(foo foo.cxx)
target_link_libraries(foo bar)
add_executable(foobar foobar.cxx)
target_link_libraries(foobar foo)
The text below the example states, This will link the libraries foo and bar
into the executable foobar even [sic], although only foo was explicitly
linked into foobar. With shared or DLL builds this linking is not always
needed, but the extra linkage is harmless.
It seems to me that this extra linkage is not harmless: I don't want clients
of FeatureViewer to have to know about vtkGraphics.lib et. al., but CMake is
creating a spurious reference.
Can someone provide a work-around?
My CMakeLists.txt files look like this:
Top Level:
CMAKE_MINIMUM_REQUIRED(VERSION 2.4)
IF(COMMAND CMAKE_POLICY)
CMAKE_POLICY(SET CMP0003 NEW)
ENDIF(COMMAND CMAKE_POLICY)
PROJECT(FeatureViewer)
add_subdirectory(TestDriver)
add_subdirectory(FeatureViewer)
FeatureViewer:
SET (FeatureViewer_SRCS
FeatureViewer.cxx
)
IF(NOT VTK_BINARY_DIR)
FIND_PACKAGE(VTK REQUIRED)
IF(NOT VTK_USE_RENDERING)
MESSAGE(FATAL_ERROR Example ${PROJECT_NAME} requires VTK_USE_RENDERING.)
ENDIF(NOT VTK_USE_RENDERING)
INCLUDE(${VTK_USE_FILE})
ENDIF(NOT VTK_BINARY_DIR)
ADD_LIBRARY(FeatureViewer SHARED ${FeatureViewer_SRCS})
TARGET_LINK_LIBRARIES(FeatureViewer vtkGraphics vtkRendering vtkHybrid)
TestDriver:
ADD_EXECUTABLE(TestDriver TestDriver.cxx)
TARGET_LINK_LIBRARIES(TestDriver FeatureViewer)
INCLUDE_DIRECTORIES(${FeatureViewer_SOURCE_DIR}/FeatureViewer)
Thanks in advance!!
Chris
The TARGET_LINK_LIBRARIES() command works transitively, i.e. TestDriver
will be linked against each shared library that FeatureViewer is linked
against, too. You might break this transitivity by explicitly setting
the LINK_INTERFACE_LIBRARIES target properties of FeatureViewer to
or, in general, to the set of libraries which are still to be linked
transitively. As an alternative, you might use a second invocation
TARGET_LINK_LIBRARIES(FeatureViewer TARGET_LINK_LIBRARIES ...)
in FeatureViewer/CMakeLists.txt to explicitly specify the transitive
libraries. Of course, the VTK ones should not appear in these lists.
'hope that helps.
Regards,
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] One too many ../ instances in the relative paths generated by file(GLOB_RECURSE variable RELATIVE ...)
On 03/18/2011 09:28 PM, Alan W. Irwin wrote:
I am using the following CMake code fragment to collect file depends for a
custom
target that generatates doxygen documentation:
# Collect essentially same source code dependencies that are in Doxyfile
# including most of the template files for configured code files.
set(doxygen_prefixes
*.c;*.cc;*.cxx;*.cpp;*.c++;*.d;*.java;*.h;*.py;*.f90;*.f)
set(doxygen_directories libs;src;bindings;drivers;include)
set(doxygen_globs)
foreach(directory ${doxygen_directories})
foreach(prefix ${doxygen_prefixes})
list(APPEND doxygen_globs ${CMAKE_SOURCE_DIR}/${directory}/${prefix})
endforeach(prefix ${doxygen_prefixes})
endforeach(directory ${doxygen_directories})
#message(STATUS DEBUG: doxygen_globs = ${doxygen_globs})
file(GLOB_RECURSE doxygen_file_depends ${doxygen_globs})
# message(STATUS DEBUG: doxygen_file_depends = ${doxygen_file_depends})
All is well with the file dependencies generated this way. When I
touch (say) include/plplot.h, the doxygen documentation is regenerated
just like I want when I run the custom target. However, I noticed
that the doxygen_globs list was getting really huge due to the
long absolute pathnames so out of curiosity I tried
file(GLOB_RECURSE doxygen_file_depends RELATIVE ${doxygen_globs})
AFAICS, the first item in doxygen_globs is taken as the path the
following items are to be relative to. You probably need to say:
file(GLOB_RECURSE doxygen_file_depends
RELATIVE ${CMAKE_SOURCE_DIR} ${doxygen_globs})
^^^
Look at the following CMakeLists.txt for a simple example:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(GLOBS NONE)
FILE(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/include ${CMAKE_BINARY_DIR}/doc)
FILE(WRITE ${CMAKE_BINARY_DIR}/include/header.h )
FILE(WRITE ${CMAKE_BINARY_DIR}/doc/latex.tex )
SET(GLOBS ${CMAKE_BINARY_DIR}/include/*.h ${CMAKE_BINARY_DIR}/doc/*.tex)
# Wrong:
FILE(GLOB_RECURSE RESULT1 RELATIVE ${GLOBS})
MESSAGE(RESULT1: ${RESULT1})
# Right:
FILE(GLOB_RECURSE RESULT2 RELATIVE ${CMAKE_BINARY_DIR} ${GLOBS})
MESSAGE(RESULT2: ${RESULT2})
The results are:
RESULT1: ../../doc/latex.tex
RESULT2: include/header.h;doc/latex.tex
While RESULT2 is correct, RESULT1 is ${CMAKE_BINARY_DIR}/doc/latex.tex
relative to ${CMAKE_BINARY_DIR}/include/header.h, i.e. with two ../.
Regards,
Michael
instead, and the result has one too many ../ instances in
the relative paths. That is, when I run the custom target, the
result is
make[3]: *** No rule to make target
/home/software/plplot_svn/HEAD/plplot_cmake_qt/doc/../../include/ps.h',
needed by doc/doxygen'. Stop.
Note, doc and include are subdirectories of the top-level source
directory, /home/software/plplot_svn/HEAD/plplot_cmake_qt so there
is one too many ../ instances in the above relative path, and I
have printed out doxygen_globs to verify that this issue
occurs for all relative paths.
Is this extra ../ issue with GLOB_RECURSE and RELATIVE for
the file command a known bug?
I happen to have run this test with cmake-2.8.4-rc2, although I
would be happy to move to 2.8.4 instead if anybody is having
trouble replicating this issue.
Alan
___
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] Is is possible to append to default module path?
On 03/18/2011 10:27 PM, Orion Poplawski wrote:
I would like to have the standard cmake module path searched first before a
local projects path. Is this possible to do?
SET(CMAKE_MODULE_PATH ${CMAKE_ROOT}/Modules local-project-path)
Regards,
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] Adding new language.
On 03/15/2011 06:30 PM, arrowdodger wrote: On Tue, Mar 15, 2011 at 12:20 PM, Michael Wild them...@gmail.com wrote: Just one warning: AFAIK these rule variables are only used for Makefile-based generators, *NOT* for Xcode and VisualStudio and the like. I'd prefer the route via add_custom_command/add_custom_target... Michael Oh, great, then i should abandon what i've written. So, since adding new language involves creating rule variables, this too works only with Makefile's? Yes, probably; I've just tried with Visual Studio 8, and it's actually not impressed by a modified CMAKE_C_COMPILE_OBJECT rule variable. BTW, this should be mentioned in the documentation and the Wiki. Anyway, perhaps, there is another alternative for your concern: If you achieve to sufficiently isolate your project's bytecode-related part - logically w.r.t. target interdependencies and organisationally w.r.t. to the directory structure - you might configure that part as an external project for a Makefile generator explicitly. In this way, you could use a non-Makefile generator for your overall project while the bytecode part is built by Make, so you've CMAKE_C_COMPILE_OBJECT, the RULE_LAUNCH properties etc. available. If the bytecode part comprises more than a few files, possibly with non-trivial relations among one another, this may be more appropriate than trying by hand with custom commands and custom targets. Regards, 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] No LANG_FLAGS_CONFIG target property.
On 03/15/2011 06:13 AM, Óscar Fuentes wrote:
Michael Hertling mhertl...@online.de
writes:
So you add global compiler flags which are not meant to be global? A usual
person would say: then do not set them globally!.
It's really that simple...
No, I want to replace those automatically setted by CMake.
AFAIK, CMake doesn't set compilation flags by itself, perhaps unless a
specific toolchain/platform file enforces this. Rather, the flags are
roughly set up as follows - for C compilations:
1) CMAKE_C_FLAGS for all configurations; explicitly set or initialized
by the CFLAGS environment variable when CMake is run initially.
2) Addition of CMAKE_C_FLAGS_CONFIG for the configuration.
3) Addition of COMPILE_FLAGS source/target properties.
If you set neither CFLAGS/CMAKE_C_FLAGS nor CMAKE_C_FLAGS_CONFIG nor
COMPILE_FLAGS, your source files should be compiled without any flags,
Say CMake, say a toolchain/platform file, once a project is started it
comes with the standard flags for compiling in the chosen mode (debug,
release, ...) and, IIRC, in some cases some other flags which are
deemed as good to have are added too.
Yes, but these standard flags are the default values of the various
CMAKE_LANG_FLAGS[_CONFIG] variables which you can (re)set during
the project's (re)configuration. Nevertheless, at first, they apply
to all of the project's targets, indeed.
However, you're right insofar that there's no possibility to specify
flags which will be used solely for a certain target *and* a certain
configuration, but in my experience, this is almost never necessary.
Do you have a special problem in this regard, i.e. a flag that must
be activated for one target in one configuration only?
Generally speaking, I had a case for building the same sources with
different flags. One project I maintain (LLVM) compiles an utility that
is used to generate files later in the same build. The problem is VC++
in Debug configurations: the debug VC++ runtime makes the utility to
perform excruciatingly slow. Someone was annoyed enough by that to
create a patch that builds the utility and one library it uses in
optimized mode when the user activates an option. The ugly part of the
patch was a trick for building the library used by the utility twice:
one with the usual Debug configuration (required because that library is
used by everything else on the project) and another with optimization
flags. He resorted to creating an extra directory for building the
optimized version, because CMAKE_C*_FLAGS* affects all targets defined
on the same CMakeLists.txt file.
Probably, I would have run the same path. While the utility might in
fact be built with SET(CMAKE_C_FLAGS_DEBUG ${CMAKE_C_FLAGS_RELEASE})
after all ADD_SUBDIRECTORY() commands in its CMakeLists.txt are done,
the prerequisite library must be built twice in different directories
to limit the modified set of flags to one of them - possible but ugly.
Fortunately our problem can be easily solved on a totally different way,
but I was surprised by the lack of target properties for setting the
compiler flags.
Perhaps, this would be worth a feature request, but I suppose there's
a fundamental difficulty: Due to the diverse possibilities to specify
a target's compilation flags - CMake/environment variables, target/
source properties - the final set is possibly not composed until the
project's configuration is finished, i.e. they are possibly not kept
centrally. So, how should one access them in their entirety? Anyway,
a configuration-specific version of the COMPILE_FLAGS properties is
off the ground [1].
Alternatively, you
might modify the CMAKE_C_COMPILE_OBJECT rule variable within the
affected directories, especially w.r.t. the FLAGS placeholder,
see [3].
I cannot access the link because gmane mangled it, but I guess that
CMAKE_C_COMPILE_OBJECT has the same restriction as CMAKE_C_FLAGS (it
acts with the same value over all targets defined on the same
CMakeLists.txt).
Yes, that's right, and the effect of CMAKE_C_COMPILE_OBJECT can be
limited in the same manner as for CMAKE_C_FLAGS[_CONFIG], i.e. by
placing it after the ADD_SUBDIRECTORY() commands. However, it still
applies to all targets in the current CMakeLists.txt file. Moreover,
I've been told that CMAKE_C_COMPILE_OBJECT et al. are available for
Makefile generators only although neither the documentation nor the
Wiki mentiones this.
Regards,
Michael
[1] http://www.cmake.org/Bug/view.php?id=6493
___
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] Adding new language.
On 03/14/2011 03:15 PM, arrowdodger wrote:
Hello. I'm using CMake as build system for a C/CXX project and i've faced
the following problem: I need to compile some sources as bytecode for VM.
This is achieved by using different linker (with different flags) and,
probably, different compiler. At the moment, the only solution i see is to
create two new CMake languages - BC_C and BC_CXX by setting
CMAKE_BC_C_{COMPILER,LINK_EXECUTABLE}. Then, i want to set LANGUAGE and
COMPILE_FLAGS properties on files, which i want to be compiled as bytecode
and finally define LINKER_LANGUAGE property on target.
Still, i need the way, to inherit all compiler flags and probably linker
from CXX language, and i don't know how to do it.
Also, if you know how to to implement such thing in better way, please share
your thoughts.
Thanks in advance.
Besides the introduction of new languages BC_C and BC_CXX - which is a
quite fundamental approach - I can imagine the following alternatives:
1) If there are only a few affected files, you might get along with
custom targets/commands, so at least, you can rely on CMake's
dependency tracking capabilities.
2) If you collect the affected files in a separate directory - which is
probably recommendable anyway - you might set CMAKE_C_COMPILE_OBJECT,
CMAKE_C_CREATE_SHARED_LIBRARY, CMAKE_C_LINK_EXECUTABLE etc. as well
as their CXX counterparts in that directory to whatever suits your
needs, and you can refer to the special placeholders DEFINES,
FLAGS etc. from within the abovementioned rule variables.
3) You might impose the RULE_LAUNCH_COMPILE/LINK properties on the
affected targets/directories. In this way, you can intercept the
compiling/linking phase at the very last moment in order to, e.g.,
replace the regular compiler/linker with the bytecode one. So, you
can use the entire CMake capabilities w.r.t. tracking dependencies,
setting up flags etc. while having the necessary modifications done
just before compiling/linking takes place. The downside is that the
RULE_LAUNCH properties are limited to the Makefile generators. See
[1,2,3] for examples.
'hope that helps.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg35215.html
[2] http://www.mail-archive.com/cmake@cmake.org/msg34375.html
[3] http://www.mail-archive.com/cmake@cmake.org/msg34148.html
___
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] Adding new language.
On 03/14/2011 06:42 PM, arrowdodger wrote: On Mon, Mar 14, 2011 at 7:16 PM, Michael Hertling mhertl...@online.dewrote: 2) If you collect the affected files in a separate directory - which is probably recommendable anyway - you might set CMAKE_C_COMPILE_OBJECT, CMAKE_C_CREATE_SHARED_LIBRARY, CMAKE_C_LINK_EXECUTABLE etc. as well as their CXX counterparts in that directory to whatever suits your needs, and you can refer to the special placeholders DEFINES, FLAGS etc. from within the abovementioned rule variables. Oh, CMAKE_C_COMPILE_OBJECT is a rule for compiling *.c file, not *.o? To be exact, it's a rule variable which describes how to compile a C source file to an object file. On my system, it currently expands to: CMAKE_C_COMPILER DEFINES FLAGS -o OBJECT -c SOURCE AFAIK, these rule variables can be redefined and have the usual directory scope; the bracketed placeholders have a special meaning when the rule is used to generate command lines in a Makefile, e.g. So, you might set CMAKE_C_COMPILE_OBJECT in a directory to whatever is necessary to compile a C source file to byte code while you can refer to flags, preprocessor definitions and the source and object file via the placeholders. With just a few files to be byte-code- compiled, that's possibly more appropriate than defining a new language for this purpose. Regards, 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] No LANG_FLAGS_CONFIG target property.
On 03/14/2011 11:55 PM, Óscar Fuentes wrote: Hendrik Sattler p...@hendrik-sattler.de writes: The COMPILE_FLAGS property sets additional compiler flags used to build sources within the target. So it *adds* flags. I want to *set* flags, i.e. replace the existing ones. So you add global compiler flags which are not meant to be global? A usual person would say: then do not set them globally!. It's really that simple... No, I want to replace those automatically setted by CMake. AFAIK, CMake doesn't set compilation flags by itself, perhaps unless a specific toolchain/platform file enforces this. Rather, the flags are roughly set up as follows - for C compilations: 1) CMAKE_C_FLAGS for all configurations; explicitly set or initialized by the CFLAGS environment variable when CMake is run initially. 2) Addition of CMAKE_C_FLAGS_CONFIG for the configuration. 3) Addition of COMPILE_FLAGS source/target properties. If you set neither CFLAGS/CMAKE_C_FLAGS nor CMAKE_C_FLAGS_CONFIG nor COMPILE_FLAGS, your source files should be compiled without any flags, so the art is to specify the latters such that each source file will be compiled with the correct/desired set of them. However, you're right insofar that there's no possibility to specify flags which will be used solely for a certain target *and* a certain configuration, but in my experience, this is almost never necessary. Do you have a special problem in this regard, i.e. a flag that must be activated for one target in one configuration only? Furthermore, the user is free to choose the compiler for the project, and the compilation flags are - basically, at least - specific to the compiler, so one should be particularly conservative w.r.t. hardcoding them in CMakeLists.txt files, IMO. Besides, the compilation flags are also mentioned in the linker command line which is required sometimes [1]; not doing so might result in subtle failures. The CMAKE_C_FLAGS and CMAKE_C_FLAGS_CONFIG are passed to the linker, too, but the COMPILE_FLAGS aren't, AFAICS. Finally, if you really need to drop a flag from a compilation command and can't avoid its addition by other means, you could use one of the RULE_LAUNCH_COMPILE properties to intercept the compiler command and adjust the command line to whatever is necessary [2]. Regrettably, this is restricted to the Makefile generators. Alternatively, you might modify the CMAKE_C_COMPILE_OBJECT rule variable within the affected directories, especially w.r.t. the FLAGS placeholder, see [3]. Regards, Michael [1] http://www.mail-archive.com/cmake@cmake.org/msg30015.html [2] http://www.mail-archive.com/cmake@cmake.org/msg35215.html [3] http://www.mail-archive.com/cmake@cmake.org/msg35282.html ___ 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] adding a custom command with the file name as a target
On 03/11/2011 08:00 PM, David Cole wrote:
On Fri, Mar 11, 2011 at 12:05 PM, Jim Newsome jnews...@cmu.edu wrote:
Unfortunately it seems that the target needs to have a different name
from its dependencies. When building I get:
make[2]: Circular CMakeFiles/hello.bin - hello.bin dependency dropped.
Another workaround I thought of is to change the output filename to,
e.g., _hello.bin and have a command in the target to move _hello.bin
to hello.bin. Unfortunately this forces _hello.bin to be regenerated
every time. I suppose I could work around _that_ by copying instead of
moving, but that's getting fairly ugly.
On Fri, Mar 11, 2011 at 11:56 AM, Tyler ty...@cryptio.net wrote:
The target in the Makefile is created with the add_custom_target()
call. So just change yours to:
add_custom_target(hello.bin ALL DEPENDS hello.bin)
hth,
tyler
On Fri, Mar 11, 2011 at 7:58 AM, Jim Newsome jnews...@cmu.edu wrote:
I'd like to do something like add_custom_command, with the output file
name as a target in the generated makefile. Is there an elegant way of
doing this?
The closest I've come is:
add_executable (hello hello.c)
add_custom_command(OUTPUT hello.bin
COMMAND objcopy --output-format=binary hello hello.bin
DEPENDS hello
COMMENT objcopying hello to hello.bin)
add_custom_target(bin ALL DEPENDS hello.bin)
However, the target name in the generated makefile is 'bin' rather
than 'hello.bin'. Is there a way to make 'hello.bin' itself a target
in the generated makefile?
___
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
How about making the *named output* of your custom command simply be a
sentinel file (with a different name) that just happens to produce the
real file (with the same name as the target)...?
Something like this:
add_executable (hello hello.c)
add_custom_command(OUTPUT hello.bin.sentinel
COMMAND objcopy --output-format=binary hello hello.bin
COMMAND ${CMAKE_COMMAND} -E touch hello.bin.sentinel
DEPENDS hello
COMMENT objcopying hello to hello.bin)
add_custom_target(hello.bin ALL DEPENDS hello.bin.sentinel)
Does that work?
No, you won't have a dependency of the hello.bin custom target on the
hello.bin file, i.e. if the latter is removed, it won't be rebuilt.
Instead, use absolute paths for the custom target's dependencies:
add_executable (hello hello.c)
add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/hello.bin
COMMAND hello-to-${CMAKE_BINARY_DIR}/hello.bin
DEPENDS hello
COMMENT objcopying hello to hello.bin)
add_custom_target(hello.bin ALL DEPENDS ${CMAKE_BINARY_DIR}/hello.bin)
^ ^^^
Apparently, that's sufficient to distinguish the hello.bin custom
target from the equally named output file of the custom command.
Regards,
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] adding a custom command with the file name as a target
On 03/11/2011 09:41 PM, Jim Newsome wrote:
That doesn't quite work either. I get some errors about circular
dependencies. Strangely, doing it this way hello.bin _does_ get built,
Yes, I can see these messages - not errors - too, but obviously, they
don't prevent the hello.bin file from being generated. Perhaps, this
works by accident, so one should play safe and get rid of them. One
approach is to put the hello.bin file in a directory where it does
not collide with the equally named custom target:
file(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/objbin)
add_executable (hello hello.c)
add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/objbin/hello.bin
COMMAND ...
DEPENDS hello
COMMENT objcopying hello to hello.bin)
add_custom_target(hello.bin ALL
DEPENDS ${CMAKE_BINARY_DIR}/objbin/hello.bin)
However, IMO, the most proper solution is to rename the custom target,
say objbin instead of hello.bin, so it doesn't match a file's or
directory's name anymore. At the latest, when you need to apply the
objcopy utility to another file, this becomes appropriate anyway.
but it gets built every time, even if 'hello' hasn't changed.
This seems to be a side effect of the custom target colliding with a
file of the same name. Try again with an intermediate directory or a
renamed custom target as suggested; the unnecessary regenerations of
the hello.bin file should go away along with the messages about the
circular dependencies.
Regards,
Michael
PS: If you use CMake 2.8.4, you should refer to the hello executable
in the custom command's COMMAND clause by a generator expression.
On Fri, Mar 11, 2011 at 2:30 PM, Michael Hertling mhertl...@online.de wrote:
On 03/11/2011 08:00 PM, David Cole wrote:
On Fri, Mar 11, 2011 at 12:05 PM, Jim Newsome jnews...@cmu.edu wrote:
Unfortunately it seems that the target needs to have a different name
from its dependencies. When building I get:
make[2]: Circular CMakeFiles/hello.bin - hello.bin dependency dropped.
Another workaround I thought of is to change the output filename to,
e.g., _hello.bin and have a command in the target to move _hello.bin
to hello.bin. Unfortunately this forces _hello.bin to be regenerated
every time. I suppose I could work around _that_ by copying instead of
moving, but that's getting fairly ugly.
On Fri, Mar 11, 2011 at 11:56 AM, Tyler ty...@cryptio.net wrote:
The target in the Makefile is created with the add_custom_target()
call. So just change yours to:
add_custom_target(hello.bin ALL DEPENDS hello.bin)
hth,
tyler
On Fri, Mar 11, 2011 at 7:58 AM, Jim Newsome jnews...@cmu.edu wrote:
I'd like to do something like add_custom_command, with the output file
name as a target in the generated makefile. Is there an elegant way of
doing this?
The closest I've come is:
add_executable (hello hello.c)
add_custom_command(OUTPUT hello.bin
COMMAND objcopy --output-format=binary hello hello.bin
DEPENDS hello
COMMENT objcopying hello to hello.bin)
add_custom_target(bin ALL DEPENDS hello.bin)
However, the target name in the generated makefile is 'bin' rather
than 'hello.bin'. Is there a way to make 'hello.bin' itself a target
in the generated makefile?
___
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
How about making the *named output* of your custom command simply be a
sentinel file (with a different name) that just happens to produce the
real file (with the same name as the target)...?
Something like this:
add_executable (hello hello.c)
add_custom_command(OUTPUT hello.bin.sentinel
COMMAND objcopy --output-format=binary hello hello.bin
COMMAND ${CMAKE_COMMAND} -E touch hello.bin.sentinel
DEPENDS hello
COMMENT objcopying hello to hello.bin)
add_custom_target(hello.bin ALL DEPENDS hello.bin.sentinel)
Does that work?
No, you won't have a dependency of the hello.bin custom target on the
hello.bin file, i.e. if the latter is removed, it won't be rebuilt.
Instead, use absolute paths for the custom target's dependencies:
add_executable (hello hello.c)
add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/hello.bin
COMMAND hello-to-${CMAKE_BINARY_DIR}/hello.bin
DEPENDS hello
COMMENT objcopying hello to hello.bin)
add_custom_target(hello.bin ALL DEPENDS ${CMAKE_BINARY_DIR}/hello.bin)
^ ^^^
Apparently, that's sufficient to distinguish the hello.bin custom
target from the equally named output file of the custom
Re: [CMake] Find Library would not find the library
On 03/10/2011 12:25 AM, Andreas Pakulat wrote:
On 09.03.11 21:36:25, Ankur Handa wrote:
I'm using find_library to find a library in a given directory but it has
many different versions of this library listed as libcxcore.so,
libcxcore.so.2.1 and libcxcore.so.2.1.0 I wrote a very simple cmake file
cmake_minimum_required(VERSION 2.8)
find_library(OpenCV_LIBRARY_RELEASE NAMES cxcore PATHS
/homes/ahanda/openCV2.1/OpenCV-2.1.0/opencvinstall/lib NO_DEFAULT_PATH)
if ( OpenCV_LIBRARY_RELEASE)
message(LIBRARY FOUND = ${OpenCV_LIBRARY_RELEASE})
endif()
if ( NOT OpenCV_LIBRARY_RELEASE)
message(LIBRARY NOT FOUND)
endif()
It works fine if I search for cxcore for which it returns me libcxcore.so
and the OpenCV_LIBRARY_RELEASE
as /homes/ahanda/openCV2.1/OpenCV-2.1.0/opencvinstall/lib/libcxcore.so
However if I try to search for cxcore21 or cxcore210 or even
libcxcore.so.2.1.0 it won't return me anything and I'd always see LIBRARY
NOT FOUND being printed.
Could anyone please let me know how to really search for libcxcore.so.2.1.0
You can't I think. Thats simply not how cmake or the linker work. The
linker during the compilation phase will always link against
libname.so. So you need to make sure that your libname.so is from
cxcore 2.1.0 and search simply for cxcore.
The linker exactly links against what is denoted on the command line,
so if you mention /homes/ahanda/.../libcxcore.so.2.1.0 directly, it
will take right this file for resolving symbols regardless whether
and how the libcxcore.so symlink is set.
The OP's issue is that FIND_LIBRARY() is somewhat restricted w.r.t. the
names of the library to look for; AFAICS, it works roughly as follows:
- If the user-supplied name in consideration has a valid library suffix
- specified by CMAKE_FIND_LIBRARY_SUFFIXES - it is searched literally.
- If no literally matching library is found, FIND_LIBRARY() looks for a
concatenation of the library prefixes in CMAKE_FIND_LIBRARY_PREFIXES,
the supplied name and the library suffixes as a regular expression,
i.e. (lib)name(\.so|\.a) on *nix.
Hence, FIND_LIBRARY() can't find libcxcore.so.2.1.0 even if the latter
is specified literally because .so.2.1.0 is no valid library suffix.
A possible solution - provided that one definitely knows that exactly
libcxcore.so.2.1.0 should be found - is to temporarily add .so.2.1.0
to CMAKE_FIND_LIBRARY_SUFFIXES. So, Ankur, try
LIST(APPEND CMAKE_FIND_LIBRARY_SUFFIXES .so.2.1.0)
FIND_LIBRARY(OpenCV_LIBRARY_RELEASE NAMES libcxcore.so.2.1.0 ...)
LIST(REMOVE_ITEM CMAKE_FIND_LIBRARY_SUFFIXES .so.2.1.0)
and you'll probably see libcxcore.so.2.1.0 being found. Alternatively,
you might use FIND_PATH() or FIND_FILE() to search libcxcore.so.2.1.0,
but in that way, you would lose FIND_LIBRARY()'s special capabilities,
e.g. looking in CMAKE_LIBRARY_PATH or CMAKE_PREFIX_PATH/lib.
Regards,
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] newbie q - where do I put what in which CMakeLists file? out of source build
On 03/10/2011 03:11 AM, Pierre Abbat wrote:
On Wednesday 09 March 2011 13:09:39 Michael Hertling wrote:
Could you boil down your project to a minimal but complete example
which demonstrates the issues with the header not being found and
the files not being placed properly and post it here?
Here's an example of it compiling correctly, but making a package wrong:
minimal.tar.gz .
-bash-4.1$ cd build
-bash-4.1$ cmake ../src
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
snip
-bash-4.1$ make
Scanning dependencies of target readmidi
[100%] Building CXX object CMakeFiles/readmidi.dir/midi.o
Linking CXX executable readmidi
[100%] Built target readmidi
-bash-4.1$ ./readmidi
Header, 6 bytes
Track, 19 bytes
Track, 655 bytes
Track, 675 bytes
Track, 1491 bytes
Track, 1334 bytes
-bash-4.1$ make package_source
snip
bash-4.1$ cd /tmp
-bash-4.1$ tar xvzf ~/minimal/build/minimal-0.1.1-Source.tar.gz
x minimal-0.1.1-Source/config.h.in
x minimal-0.1.1-Source/midi.h
x minimal-0.1.1-Source/CMakeLists.txt~
x minimal-0.1.1-Source/midi.cpp
x minimal-0.1.1-Source/CMakeLists.txt
x minimal-0.1.1-Source/midi.cpp~
For minimal2, follow the same steps except start with cmake ... The program
doesn't compile; the package is rooted correctly, but contains contents of
the build directory as well as the src directory.
Pierre
The question w.r.t. your first minimal example should be answered by
David and Eric in the meantime. The reason why your minimal2 example
doesn't compile is that you mentioned INCLUDE_DIRECTORIES() *after*
ADD_SUBDIRECTORY() in your top-level CMakeLists.txt, so it does not
take effect for the compilation of sources in the src directory. In
general, the order of commands in CMakeLists.txt files does matter.
Furthermore, you have a persistent file in the build directory; you
should not do so. Besides that you don't really do an out-of-source
build in such a manner, a build directory is usually temporary, i.e.
the users create and enter it, configure/build/test/install/package
the project from within in and finally throw it away. Instead, you
should place the MIDI files in their own directory, refer to them
by, say, ${CMAKE_SOURCE_DIR}/midi and reserve the build directory
for the build process only.
Moreover, while it's common to create a subdirectory of the project's
top-level directory for building, it's also common to use another one
for that purpose, e.g. /tmp, /var/tmp, ~/tmp, /dev/shm etc., and the
users are completely free to choose, so you should not insist on the
usage of ${CMAKE_SOURCE_DIR}/build. Additionally, ${CMAKE_SOURCE_DIR}
might be read-only, and build directories that are descendants of the
source directory could have some pitfalls - as you have seen. Finally,
with single-configuration generators, notably the Makefile ones, you
can build only one configuration per build directory, i.e. *either*
RELEASE *or* DEBUG *or* your-config-here etc., so it's perfectly
legal to have multiple build trees side by side at the same time.
Regards,
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] adjusting CMAKE_Fortran_LINK_EXECUTABLE
On 03/10/2011 03:07 PM, Brad King wrote: On 03/10/2011 03:48 AM, Ilias Miroslav wrote: By default, the current CMAKE_Fortran_LINK_EXECUTABLE consists of several variables: CMAKE_Fortran_COMPILER CMAKE_Fortran_LINK_FLAGS LINK_FLAGS FLAGS OBJECTS -o TARGET LINK_LIBRARIES [snip] selected variables only: LINK_FLAGS OBJECTS -o TARGET LINK_LIBRARIES The FLAGS are in there because there are cases where the compiler front-end needs to know what compilation flags were used to produce the object files to adjust the flags and libraries it passes to the underlying linker. The -ffast-mathflag works for compilation of fortran source codes, but is unsuitable for g95-linking in this case. Perhaps this change should be extended for executables too: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=88bd3b52 Then -ffast-math could be added to the forbidden flag list for linking. Meanwhile one can work around this problem by not putting -ffast-math in CMAKE_Fortran_FLAGS. Instead add it to each target that needs it using the COMPILE_FLAGS target property. Alternatively, if you use the Makefile generators only, you might set one of the RULE_LAUNCH_LINK properties to a script which removes the -ffast-math flag from the linker command line, e.g.: #!/bin/sh COMMAND=$1; shift for i in $*; do [ $i != -ffast-math ] COMMAND=$COMMAND $i; shift done exec $COMMAND In this way, you can use each flag as ever and have the link process intercepted right before linking takes place in order to remove any incriminated parameters. Regards, 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] newbie q - where do I put what in which CMakeLists file? out of source build
On 03/09/2011 05:54 PM, Pierre Abbat wrote: On Wednesday 09 March 2011 10:22:50 Michael Wild wrote: Make the ~/tone12/CMakeLists.txt your main CMake file (i.e. put the project() command in there and all other commands that apply to the whole project) and add a add_subdirectory(src) call, and then call CMake with cmake .. instead. Doesn't work. config.h is in ~/tone12/build as before, but it says it can't find it, and with VERBOSE=1 it appears to be compiling the file into ~/tone12/src/, which shouldn't exist. The package contains everything in ~/tone12/build and lots of temporary files, which shouldn't be in a package. Pierre Could you boil down your project to a minimal but complete example which demonstrates the issues with the header not being found and the files not being placed properly and post it here? Regards, 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] CMake command line arguments
On 03/06/2011 12:12 PM, Gabriel Petrovay wrote:
Hi,
Is there a way to read the arguments that were passed to CMake from
inside a CMakeLists.txt file?
There is a problem that some generators (like NMake Makefiles) set a
default value for certain variables (like CMAKE_BUILD_TYPE=Debug,
CMAKE_INSTALL_PREFIX=C:\Program Files\${CMAKE_PROJECT_NAME})
From inside CMake one can not set up a different default value if the
user does not specify it with a -D option. This is because
IF(CMAKE_BUILD_TYPE) will always be true because of the default set by
the generator (NMake Makefiles).
There was this guy having the same problem:
http://www.mail-archive.com/cmake@cmake.org/msg09640.html
Any solution how one can solve this? Reading the arguments passed to
CMake would be one, but I find no documentation/example/google_result
for this.
Thanks!
Scanning the command line for user-supplied settings wouldn't be
reliable because your project might also be configured via a GUI.
Furthermore, even an empty CMAKE_BUILD_TYPE variable may denote a
valid build type, so there's no robust criterion to decide when to
set a default value by examining this variable alone. Instead, you
might use another variable, say ${PROJECT_NAME}_BUILD_TYPE, and do:
IF(NOT DEFINED ${PROJECT_NAME}_BUILD_TYPE)
SET(${PROJECT_NAME}_BUILD_TYPE CUSTOM)
ENDIF()
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE})
In this way, an undefined ${PROJECT_NAME}_BUILD_TYPE results in a
default CMAKE_BUILD_TYPE on behalf of the CMakeLists.txt file. Of
course, you should document that variable and urge your project's
users to not directly use CMAKE_BUILD_TYPE anymore; perhaps, you
should even hide the latter in a GUI by marking it as advanced.
With regard to CMAKE_INSTALL_PREFIX, you could do the same - or use
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT, as a robust criterion,
to see whether the user has supplied a value explicitly. Note that
there're additional aspects to consider if the CMakeLists.txt file
is to write that variable's value to the cache, cf. [1] et seq.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg32848.html
___
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] CMake command line arguments
On 03/07/2011 11:33 AM, Michael Hertling wrote:
On 03/06/2011 12:12 PM, Gabriel Petrovay wrote:
Hi,
Is there a way to read the arguments that were passed to CMake from
inside a CMakeLists.txt file?
There is a problem that some generators (like NMake Makefiles) set a
default value for certain variables (like CMAKE_BUILD_TYPE=Debug,
CMAKE_INSTALL_PREFIX=C:\Program Files\${CMAKE_PROJECT_NAME})
From inside CMake one can not set up a different default value if the
user does not specify it with a -D option. This is because
IF(CMAKE_BUILD_TYPE) will always be true because of the default set by
the generator (NMake Makefiles).
There was this guy having the same problem:
http://www.mail-archive.com/cmake@cmake.org/msg09640.html
Any solution how one can solve this? Reading the arguments passed to
CMake would be one, but I find no documentation/example/google_result
for this.
Thanks!
Scanning the command line for user-supplied settings wouldn't be
reliable because your project might also be configured via a GUI.
Furthermore, even an empty CMAKE_BUILD_TYPE variable may denote a
valid build type, so there's no robust criterion to decide when to
set a default value by examining this variable alone. Instead, you
might use another variable, say ${PROJECT_NAME}_BUILD_TYPE, and do:
IF(NOT DEFINED ${PROJECT_NAME}_BUILD_TYPE)
SET(${PROJECT_NAME}_BUILD_TYPE CUSTOM)
ENDIF()
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE})
Alternatively, you might do:
SET(${PROJECT_NAME}_BUILD_TYPE CUSTOM
CACHE STRING ${PROJECT_NAME} Build Type)
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE})
So, you'll have at least your project's own build type in the cache -
and, thus, in the GUIs - along with the documenting comment while the
cached value of CMAKE_BUILD_TYPE is still not the one that's actually
used.
In this way, an undefined ${PROJECT_NAME}_BUILD_TYPE results in a
default CMAKE_BUILD_TYPE on behalf of the CMakeLists.txt file. Of
course, you should document that variable and urge your project's
users to not directly use CMAKE_BUILD_TYPE anymore; perhaps, you
should even hide the latter in a GUI by marking it as advanced.
With regard to CMAKE_INSTALL_PREFIX, you could do the same - or use
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT, as a robust criterion,
to see whether the user has supplied a value explicitly. Note that
there're additional aspects to consider if the CMakeLists.txt file
is to write that variable's value to the cache, cf. [1] et seq.
Regards,
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] CMake command line arguments
On 03/07/2011 12:37 PM, Gabriel Petrovay wrote:
Thanks for the tips, Michael.
We will do so, using project specific BUILD_TYPE and INSTALL_PREFIX.
However, the downside of this approach is that your project's users
should not refer to the well-known CMake variables CMAKE_BUILD_TYPE
and CMAKE_INSTALL_PREFIX anymore - possibly an issue to consider.
On Mon, Mar 7, 2011 at 12:20 PM, Michael Hertling mhertl...@online.de wrote:
On 03/07/2011 11:33 AM, Michael Hertling wrote:
On 03/06/2011 12:12 PM, Gabriel Petrovay wrote:
Hi,
Is there a way to read the arguments that were passed to CMake from
inside a CMakeLists.txt file?
There is a problem that some generators (like NMake Makefiles) set a
default value for certain variables (like CMAKE_BUILD_TYPE=Debug,
CMAKE_INSTALL_PREFIX=C:\Program Files\${CMAKE_PROJECT_NAME})
From inside CMake one can not set up a different default value if the
user does not specify it with a -D option. This is because
IF(CMAKE_BUILD_TYPE) will always be true because of the default set by
the generator (NMake Makefiles).
There was this guy having the same problem:
http://www.mail-archive.com/cmake@cmake.org/msg09640.html
Any solution how one can solve this? Reading the arguments passed to
CMake would be one, but I find no documentation/example/google_result
for this.
Thanks!
Scanning the command line for user-supplied settings wouldn't be
reliable because your project might also be configured via a GUI.
Furthermore, even an empty CMAKE_BUILD_TYPE variable may denote a
valid build type, so there's no robust criterion to decide when to
set a default value by examining this variable alone. Instead, you
might use another variable, say ${PROJECT_NAME}_BUILD_TYPE, and do:
IF(NOT DEFINED ${PROJECT_NAME}_BUILD_TYPE)
SET(${PROJECT_NAME}_BUILD_TYPE CUSTOM)
ENDIF()
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE})
Alternatively, you might do:
SET(${PROJECT_NAME}_BUILD_TYPE CUSTOM
CACHE STRING ${PROJECT_NAME} Build Type)
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE})
So, you'll have at least your project's own build type in the cache -
and, thus, in the GUIs - along with the documenting comment while the
cached value of CMAKE_BUILD_TYPE is still not the one that's actually
used.
If you say
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE}
CACHE STRING CMake Build Type FORCE)
here, the cached value of CMAKE_BUILD_TYPE will equal the value in the
current scope again. Obviously, I'm quite unconcentrated today... ;-)
In this way, an undefined ${PROJECT_NAME}_BUILD_TYPE results in a
default CMAKE_BUILD_TYPE on behalf of the CMakeLists.txt file. Of
course, you should document that variable and urge your project's
users to not directly use CMAKE_BUILD_TYPE anymore; perhaps, you
should even hide the latter in a GUI by marking it as advanced.
With regard to CMAKE_INSTALL_PREFIX, you could do the same - or use
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT, as a robust criterion,
to see whether the user has supplied a value explicitly. Note that
there're additional aspects to consider if the CMakeLists.txt file
is to write that variable's value to the cache, cf. [1] et seq.
Regards,
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] Looking for advice on creating targets that use external packages
On 03/01/2011 04:52 PM, L. A. Pritchett-Sheats wrote:
Thanks for the reply.
Just so I understand, is the following statement accurate: FIND_PACKAGE
for XXX sets plural XXX_INCLUDE_DIRS and XXX_LIBRARIES which include all
the needed include paths and libraries to compile and build anything using
XXX.
Exactly. In addition, a find module or config file usually sets the
cached XXX_INCLUDE_DIR and XXX_LIBRARY variables to the XXX include
directory and library file - typically as results of FIND_PATH() and
FIND_LIBRARY() - to prevent multiple searchings if FIND_PACKAGE(XXX)
is invoked more than once or to preset the results in a GUI or on the
command line if FIND_PACKAGE(XXX) can't or shouldn't find the include
directory or library for whatever reasons. See [1] for further details.
In my project that calls XXX
add_library(foo ${some_source_files})
target_link_libraries(foo ${XXX_LIBRARIES})
resolves all the dependencies at link time.
Yes, w.r.t. XXX.
We were looking into imported targets instead of explicit paths because we
were concerned about the command line length and we have already seen on
Mac OSX complaints from the compiler about repeated *.dylib files. I'm
assuming that if we define imported targets, that CMake would not repeat
libraries in the compile line.
AFAIK, CMake repeatedly mentions libraries on the link line if they are
necessary to resolve known dependencies, e.g. with circularly dependent
static libraries. OTOH, CMake drops libraries from the link command if
they're discernibly unnecessary for dependency resolution, see [2] for
an example. However, IIRC, imported targets were mainly introduced due
to the flexibility they provide in regard of different build types or
configurations, respectively; e.g.
ADD_LIBRARY(XXX SHARED IMPORTED)
SET_TARGET_PROPERTIES(XXX PROPERTIES IMPORTED_LOCATION_CUSTOM ...)
would make the linker use a special version of XXX if the build type
equals CUSTOM which is hardly possible with the path-based approach.
Here's the specific from my project. We have code (foo) using Boost, HDF5,
NetCDF, ExodusII (Mesh database), MOAB (Mesh framework) and Trilinos (huge
solver framework package). The dependencies are:
NetCDF - HDF5, ExodusII - NetCDF, MOAB-NetCDF, MOAB-HDF5, foo-MOAB,
foo-Boost, foo-Trilinos.
We either written a FIndXXX module or are using a config file
(Trilinos)for each of the external libraries.
HDF5 has been the difficult case here. The FindHDF5.cmake module usually
returns more than one library in HDF5_LIBRARIES (hdf5,hdf5_hl,z,m,...). So
in this case I would need to create an imported target for each library in
HDF5_LIBRARIES, correct? [...]
Yes, for the HDF5 libraries if you want to give imported targets a try.
Without knowing HDF5, I'd roughly do the following in its find module:
FIND_PACKAGE(ZLIB)
FIND_LIBRARY(HDF5_LIBRARY hdf5 ...)
FIND_LIBRARY(HDF5_HL_LIBRARY hdf5_hl ...)
IF(NOT TARGET hdf5 AND NOT TARGET hdf5_hl)
ADD_LIBRARY(hdf5 SHARED IMPORTED)
ADD_LIBRARY(hdf5_hl SHARED IMPORTED)
ENDIF()
SET_TARGET_PROPERTIES(hdf5 PROPERTIES IMPORTED_LOCATION ${HDF5_LIBRARY})
SET_TARGET_PROPERTIES(hdf5_hl PROPERTIES IMPORTED_LOCATION
${HDF5_HL_LIBRARY})
SET(HDF5_LIBRARIES hdf5 hdf5_hl ${ZLIB_LIBRARIES} m)
However, if a package provides multiple libraries which can be used
selectively/independently, it is possibly worth to consider whether
the find module or configuration file can be made component-aware.
[...] The other difficultly is Trilinos, which can have
up to +30 libraries. Do I need to create an imported target for each of
those libraries? [...]
Yes, if they're intended to be used explicitly by other projects. If
some of them are only needed by other libraries but are not meant to
be referred to by the package's users, you might mention the formers
in the IMPORTED_LINK_INTERFACE_LIBRARIES properties of the latters.
E.g., suppose the library XXX is linked against a library YYY, but
YYY does not have a public API; you might do in the config file:
IF(NOT TARGET XXX)
ADD_LIBRARY(XXX SHARED IMPORTED)
ENDIF()
SET_TARGET_PROPERTIES(XXX PROPERTIES
IMPORTED_LOCATION path/to/libXXX.so
IMPORTED_LINK_INTERFACE_LIBRARIES path/to/libYYY.so
)
Then, if the package's users mention XXX in TARGET_LINK_LIBRARIES(),
libYYY.so will appear on the link command line, too, but YYY can't
be directly referred to as a target, so it's hidden from the users.
[...] And if that is the case I can see why many projects do
not do this and instead just use XXX_LIBRARIES as a list of libraries. I
grep'd through the Modules directory in my CMake and only found one
FindXXX.cmake module creating imported targets, FindQT.cmake.
If I'm not mistaken, most of the modules are already present since the
days of CMake 2.4, i.e. the pre-imported-target era, and many of them
do not have a maintainer, so they are rarely touched. However, if you
provide a configuration file instead of a find
Re: [CMake] Is there an elegant way to get list of object files participating into a library?
On 02/27/2011 10:38 PM, Pere Mato Vila wrote: Hi, For the Windows platform I am generating the .DEF files with all defined symbols to be exported. For this I need to get the list of all object files (.obj) participating into a library. The question is whether this list is available knowing the library target name. I can try to construct it staring from the list of sources and try to reverse-engineer the correct suffix replacement and their location in the build tree. But clearly would be better if this is given to me directly. If you use a Makefile generator, you might utilise the RULE_LAUNCH_LINK target property for your purpose; see [1] for an example how to access the object files being incorporated in a library target on *nix. Regards, Michael [1] http://www.mail-archive.com/cmake@cmake.org/msg34148.html ___ 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 too set properties on all executables
On 02/24/2011 09:34 PM, Hanna Symanska wrote:
Hey,
I have a fairly large project with multiple executables, about 90 to
be exact and I would like to set the subsystem based on the
LINK_FLAGS_* property.
Is there a way for me to globally set this up in a top level
CMakeLists.txt file so that i do not have to place the below code in
every single project.
add_executable(project_n )
IF (WIN32)
SET_TARGET_PROPERTIES(project_n PROPERTIES LINK_FLAGS_RELEASE
/INCREMENTAL:NO /NODEFAULTLIB:LIBCMT.lib /SUBSYSTEM:WINDOWS )
SET_TARGET_PROPERTIES(project_n PROPERTIES LINK_FLAGS_RELWITHDEBINFO
/NODEFAULTLIB:LIBCMT.lib /SUBSYSTEM:WINDOWS )
SET_TARGET_PROPERTIES(project_n PROPERTIES LINK_FLAGS_DEBUG
/NODEFAULTLIB:LIBCMTD.lib /SUBSYSTEM:CONSOLE )
ENDIF (WIN32)
As it stands right now I have a top level CMakeLists.txt file with
several other CMakeLists.txt files in subsequent directories.
I have 1 CMakeLists.txt per project executable. I am trying to avoid
putting the above code in EVERY CMakeLists.txt file, when the only
thing I am changing is the target to reflect the the project that I am
setting the properties on.
I am using CMake 2.8.4 to generate visual studio 2008 project files to
be compiled 64-bit.
I do not want to use set_executable(project_n WIN32...) because I want
the subsystem to be console for projects that are being compiled as
debug.
- Hanna
AFAIK, you can't set the LINK_FLAGS properties in a global manner as
you do above for a single target. However, possible alternatives are:
1) In the top-level CMakeLists.txt, write a function SET_EXECUTABLE()
or the like which contains the IF/ENDIF block and apply it in each
subordinated CMakeLists.txt.
2) Similarly, write a function MY_ADD_EXECUTABLE() or the like which
encompasses the actual ADD_EXECUTABLE() and the IF/ENDIF block.
3) Rewrite ADD_EXECUTABLE() like:
FUNCTION(ADD_EXECUTABLE TARGET)
_ADD_EXECUTABLE(${TARGET} ${ARGN})
IF (WIN32)
ENDIF (WIN32)
ENDFUNCTION()
Note that the original function is still available, cf. [1].
4) Collect the concerned executable targets in a variable or,
preferably, in a global property - perhaps by use of special or
customized functions similar to the ones above - and impose the
LINK_FLAGS properties in one go in the top-level CMakeLists.txt.
5) If the CMakeLists.txt files for your numerous executable targets
differ in a few places only, e.g. the target name and one source
file, you might set up a suitably parameterised template, say
CMakeLists.txt.in, and copy it by use of CONFIGURE_FILE() at
configuration time before jumping into the directories via
ADD_SUBDIRECTORY(). With this appoach and a strict preference
for out-of-source builds, the executable targets' CMakeLists.txt
files will reside in the binary directory, so you'll need to use
full paths for the ADD_SUBDIRECTORY() command and possibly within
the CMakeLists.txt files, too.
'hope that helps.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg31299.html
___
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] Looking for advice on creating targets that use external packages
On 02/24/2011 06:00 PM, L. A. Pritchett-Sheats wrote:
I'm working on a software project that requires about a dozen external
packages to build our libraries. What is the correct way to define the
dependencies for our targets that depend on these external libraries?
So far I have created FindXXX.cmake files for each external library. These
files set XXX_INCLUDE_DIRS and XXX_LIBRARY or XXX_LIBRARIES. Should I make
a target in our build for XXX?
Example A:
in the root CMakeLists.txt file:
find_package(UnitTest)
add_library(unittest++ STATIC IMPORTED)
set_target_property(IMPORTED_LOCATION ${UnitTest_LIBRARY})
then in a subdirectory foo/CMakeLists.txt
add_executable(test_foo test/Main.cpp test/test_foo.cpp)
add_test(foo test_foo)
target_link_libraries(test_foo foo unittest++)
or should each subdirectory that contains a CMakeLists.txt file that needs
this library to link to an executable explicitly define the library in the
target's target_link_libraries call? Like this
Example B:
in foo/CMakeLists.txt:
find_package(UnitTest)
add_executable(test_foo test/Main.cpp test/test_foo.cpp)
add_test(foo test_foo)
target_link_libraries(test_foo foo ${UnitTest_LIBRARY})
We've been following Example A, but have run into numerous link problems
because we are using NetCDF, HDF5, ExodusII and a mesh framework package
that depends on all 3. I've looked at two other projects that use CMake:
Trilinos and Yarp. Both follow Example B and since we are having so much
difficulty resolving links at run time, I wanted to know if we are
defining these dependencies correctly.
Thanks for your time.
At first, your FindXXX.cmake files, provided XXX is a library, should
define XXX_LIBRARIES in any case since this variable is meant to hold
XXX_LIBRARY - usually the result of a FIND_LIBRARY() call - along with
XXX's prerequisite libraries. In other words, XXX_LIBRARIES contains
anything necessary to link against XXX. Mentioning UnitTest_LIBRARY
instead of UnitTest_LIBRARIES in TARGET_LINK_LIBRARIES() might be a
cause for the problems you report on.
Furthermore, defining imported targets for external libraries should be
the find module's job; it's intended as a more flexible alternative to
the direct specification of a library's full path, e.g. The necessary
prerequisites are specified appropriately enough by target properties
IMPORTED_LINK_INTERFACE_LIBRARIES. As it were, dropping them might
result in unresolved dependencies at link time.
Finally, if the target foo is sufficiently independent, particularly
if it can be configured and built by itself, I would tend to place the
needed FIND_PACKAGE() calls in foo's CMakeLists.txt as in example B
above, even if these calls appear in other CMakeLists.txt files, too.
In that way, this part of the project becomes more self-contained and
you do not need to rely on any FIND_PACKAGE() calls to be made before
somewhere in the current scope. Additionally, well written find modules
can be safely called multiple times and due to the cache, they do their
work usually once. OTOH, if foo is tightly connected with other parts
of the project, e.g. if it is a module which isn't useful on its own or
doesn't make sense without a main program, it's probably appropriate to
have a superordinate CMakeLists.txt call FIND_PACKAGE() and rely on the
results.
In summary, I'd recommend to write FindXXX.cmake files for external
libraries which set up imported targets *with* their prerequisites,
i.e. IMPORTED_LOCATION and IMPORTED_LINK_INTERFACE_LIBRARIES target
properties. Note that the find modules need to protect the imported
targets from being defined twice; this is important when the same
FIND_PACKAGE() call is multiply issued within the same scope. The
imported targets, however, should be conveyed to the caller via the
XXX_LIBRARIES variables, so the calling CMakeLists.txt file can just
say TARGET_LINK_LIBRARIES(... ${XXX_LIBRARIES}) regardless whether the
FindXXX.cmake file uses imported targets or returns full paths directly.
BTW, which link problems do you have exactly? You have also mentioned
a difficulty resolving links *at run time*, so are you sure these
problems are caused by the find modules and the way you use them?
Regards,
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] Include-Dir order problem
On 02/13/2011 01:27 AM, Andreas Pakulat wrote: Hi, I've got a somewhat tricky problem here with include directories. I'm building a couple of source files and for some of them I need to add an include-directory to the front of the list that cmake passes to the compiler. At the same time other source files in that directory need to not have that include-dir in front of the list. I can't see a way to do this, except by using COMPILE_FLAGS source file properties for each and every file to specify include-dirs and not use include_directories at all, as COMPILE_FLAGS always end up behind the includes. So, am I missing something here? If not I guess I'll have to find that bugreport about making include-dirs a source-file property and vote for it so it gets included into 2.8.5... Currently, AFAIK, it's not possible to set source-file-specific include directories unless one (mis)uses COMPILE_FLAGS which is accompanied by the shortcoming you've mentioned. Probably, the really clean solution ATM would be a reorganisation of the sources, but I doubt if the need for different include directories is an appropriate criterion for a project's directory layout. If there're only a few affected files, another possible workaround consists of file-specific configured headers, i.e. find the special include directories and inject them into config'd headers that are included by the concerned source files, or even modify the latters themselves in this manner. Of course, the sources must be touched to do that. IMO, from a conceptual point of view, INCLUDE_DIRECTORIES should be also available as target and source file property, so I would vote for 1968 and 8189 - seem to be relatives - and possibly 8874, too. However, if this undertaking is addressed, one should think about how the include directories are ordered on the compiler's command line. Perhaps, there might be a convention that they appear from most to least specific, i.e. in source-target-directory order. Regards, 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] detecting build configuration in Visual Studio
On 02/15/2011 03:49 PM, Dominik Szczerba wrote:
In MSVC I need to link different libraries depending on the chosen
build type. I have two questions:
1) If and how can I register my own build types
http://www.cmake.org/Wiki/CMake_FAQ#How_can_I_specify_my_own_configurations_.28for_generators_that_allow_it.29_.3F
2) How can I detect which one I am in for conditional linking
AFAIK, you can't, but you might do the following: Declare the differing
libraries for the different configurations as IMPORTED libraries and
set the IMPORTED_LOCATION_CONFIG properties accordingly, e.g.:
ADD_LIBRARY(xyz SHARED IMPORTED)
SET_TARGET_PROPERTIES(xyz PROPERTIES
IMPORTED_LOCATION_CUSTOMIZED ...
IMPORTED_LOCATION_RELEASE ...
IMPORTED_LOCATION_DEBUG ...
...
)
...
TARGET_LINK_LIBRARIES(... xyz ...)
If such a library should not be taken into account for a particular
configuration at all, things are more complex since you can't declare
an empty IMPORTED_LOCATION. A possible approach might look as follows:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(IMPORTEDDUMMY C)
ADD_LIBRARY(dummy STATIC )
SET_TARGET_PROPERTIES(dummy PROPERTIES LINKER_LANGUAGE C)
EXPORT(TARGETS dummy NAMESPACE imported FILE importeddummy.cmake)
INCLUDE(${CMAKE_BINARY_DIR}/importeddummy.cmake)
SET_TARGET_PROPERTIES(importeddummy PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_CUSTOMIZED ...
)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main importeddummy)
The target dummy is an empty static library and needed as anchor for
an imported static library importeddummy which refers to the former;
this is achieved by EXPORT() and the generated importeddummy.cmake
file. Finally, the importeddummy target is associated with additional
libraries via the IMPORTED_LINK_INTERFACE_LIBRARIES_CONFIG property.
This property is the reason for the intermediate importeddummy target
since it can't be imposed on non-imported ones. At the end of the day,
the additional libraries appear in the link command line only for the
CUSTOMIZED configuration. Maybe, it would be worth a feature request
to drop an imported library from the link command line completely if
there's no IMPORTED_LOCATION for the active configuration instead of
having make raise an error.
'hope that helps.
Regards,
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] Include-Dir order problem
On 02/15/2011 07:36 PM, Andreas Pakulat wrote:
On 15.02.11 17:54:29, Michael Hertling wrote:
On 02/13/2011 01:27 AM, Andreas Pakulat wrote:
Hi,
I've got a somewhat tricky problem here with include directories. I'm
building a couple of source files and for some of them I need to add an
include-directory to the front of the list that cmake passes to the
compiler. At the same time other source files in that directory need to
not have that include-dir in front of the list.
I can't see a way to do this, except by using COMPILE_FLAGS source file
properties for each and every file to specify include-dirs and not use
include_directories at all, as COMPILE_FLAGS always end up behind the
includes.
So, am I missing something here? If not I guess I'll have to find that
bugreport about making include-dirs a source-file property and vote for
it so it gets included into 2.8.5...
Currently, AFAIK, it's not possible to set source-file-specific include
directories unless one (mis)uses COMPILE_FLAGS which is accompanied by
the shortcoming you've mentioned. Probably, the really clean solution
ATM would be a reorganisation of the sources, but I doubt if the need
for different include directories is an appropriate criterion for a
project's directory layout.
Well, all those sources need to be in the same target, so I can't quite
see how moving some of the sources into subdirs wuld help with that.
Look at the following CMakeLists.txt files:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(INCLUDEDIRECTORIES C)
ADD_SUBDIRECTORY(subdir)
INCLUDE_DIRECTORIES(abc)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){f();return 0;}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main sub)
# subdir/CMakeLists.txt:
INCLUDE_DIRECTORIES(xyz)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(sub STATIC f.c)
So, main.c and f.c are compiled with different include directories, but
the main target is effectively composed from the same object files as
if f.c had been explicitly mentioned among the source files for main.
If you commute the ADD_SUBDIRECTORY() and INCLUDE_DIRECTORIES() commands
in the top-level CMakeLists.txt, the include directories for main.c will
also hold for f.c while the latter still has its own - additional - ones.
Things become worse if the target to be built is a shared library. Most
probably, you don't want an additional libsub.so, so you would need to
compile f.c at least with -fPIC as COMPILE_FLAGS to get further along
with a static library. Alternatively, you might use a RULE_LAUNCH_LINK
property in order to capture the object files from the subdirectory and
incorporate them in the actual target, see [1]. However, then you would
be restricted to a Makefile generator. IMO, none of these appoaches is
really convincing why one should aim at an INCLUDE_DIRECTORIES source
file and target property.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg34148.html
___
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] linking static vs dynamic
On 02/14/2011 10:02 AM, Yngve Inntjore Levinsen wrote: If you want everything linked statically I believe you can use the variable, BUILD_SHARED_LIBS, something like OPTION( BUILD_SHARED_LIBS Set to OFF to build static libraries OFF ) I do believe it will still use dynamic libraries if static aren't available, but I am unsure about that part. No, BUILD_SHARED_LIBS decides whether the *project's* libraries which have been declared without the STATIC/SHARED flag are built as static or shared, but it has no influence which kind of *external* libraries is picked up to link against. Regards, Michael On Sunday 13 February 2011 12:08:58 AM Dominik Szczerba wrote: Yes, full paths seem to work fine for me. Many thanks for your feedback! Dominik On Sat, Feb 12, 2011 at 11:11 PM, Michael Hertling mhertl...@online.de wrote: On 02/12/2011 09:39 PM, Andreas Pakulat wrote: On 12.02.11 21:20:58, Dominik Szczerba wrote: I never actually saw a solution to this problem in cmake: I need to link (independent constraint from above) with libguide.a and not libguide.so (in intel compiler, does not matter much), but both are available, and cmake always takes the shared one when given guide as the desired library to be linked. Is there an elegant way of static linking (other than -static passed to the linker for static linking of everything) of this particular lib other than hacking (like deleting the .so from the folder)? No, i.e. no elegant way. What you can do is force cmake to search only for .a files by setting a cmake variable, unfortunately I don't remember which one and can't easily find it right now. The archive of this list has more info as well as the cmake manual or the FAQ on the cmake website. Andreas Hi Dominik, it's CMAKE_FIND_LIBRARY_SUFFIXES; setting it to .a on *nix makes FIND_LIBRARY() search for static libraries only. It can be set to its original value at any time to restore the previous behaviour. However, if you know that you're looking exactly for libguide.a and have control over the FIND_LIBRARY() call, i.e. it's not buried in a find module or config file, you should follow Alexander's advice, use the library's full name in FIND_LIBRARY() and pass the latter's result to TARGET_LINK_LIBRARIES(). Regards, 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] ADD_CUSTOM_COMMAND() cannot depend on ADD_CUSTOM_TARGET()
On 02/15/2011 12:58 AM, John McGehee wrote:
I have a custom command that depends on a custom target. In the example
below, it is as if
ADD_CUSTOM_COMMAND(... DEPENDS t ...)
has no effect:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(CUSTOMDEPENDS NONE)
ADD_CUSTOM_TARGET(t
${CMAKE_COMMAND} -E echo Building target t
VERBATIM)
ADD_CUSTOM_COMMAND(OUTPUT stamp
COMMAND ${CMAKE_COMMAND} -E touch stamp
DEPENDS t
VERBATIM)
ADD_CUSTOM_TARGET(main ALL
${CMAKE_COMMAND} -E echo Building target main
DEPENDS stamp
VERBATIM)
# Fedora 11 with CMake 2.8 generating GNU make
make
Scanning dependencies of target t
Building target t
[ 0%] Built target t
Scanning dependencies of target main
make[2]: *** No rule to make target `t', needed by `stamp'. Stop.
make[1]: *** [CMakeFiles/main.dir/all] Error 2
make: *** [all] Error 2
Target t is built, and I can 'make t' myself, so the target is in fact there.
My particular situation is that I am,
1. Creating a language binding using SWIG
2. Compiling the resulting C#
If you look just beneath the surface, this is the same situation illustrated
in the above example. SWIG and C# themselves are working fine.
Is there any way to work around this? Shall I enter this as a bug?
This issue was raised earlier as
http://www.cmake.org/pipermail/cmake/2010-November/040541.html but no
solution was given. The excellent example is from that earlier message.
This will be fixed in CMake 2.8.4, see [1].
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg34598.html
___
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] Simple (?) problem with libraries executable dependencies
, everything looks OK, but I'm no MacOSXpert. ;) Spontaneously, I'd suggest to try the following: - Use otool -L on the executable and the library to check the paths. - Throw away the build tree and start anew from an empty directory. - Start the executable from within the library's directory, i.e.: cd /usr/local/AliRoot/NewIO/lib/tgt_macosx64 /usr/local/AliRoot/NewIO/bin/tgt_macosx64/aliroot Apart from that, perhaps a MacOSX specialist on this ML can help. Regards, Michael On 14 Feb 2011, at 02:26, Michael Hertling wrote: On 02/14/2011 01:32 AM, Carminati Federico wrote: Hello, I have a problem with the dependencies of an executable. The executable depends on a number of shared libraries. If I define the executable like this add_executable(aliroot aliroot.cxx) target_link_libraries(aliroot Mylib) then the link command really looks like g++ -o aliroot ../lib/libMylib.so and I have plenty of problems with relocation and rpaths. [...] Which problems do you have exactly? Could you post an excerpt from the output of make VERBOSE=1 that shows the issue in more detail? Have you already read [1]? How is the target Mylib defined? [...] If I just do target_link_libraries(aliroot -lMylib) the link command looks right: g++ -o aliroot -lMylib however the executable is NOT relinked in case a library is recreated. [...] No, this isn't right, not really. Besides other things - linker search paths [2], selection of static/shared libraries [3] - the -lMylib is taken verbatim and CMake does not recognize that you're aiming at your project's Mylib target. So, the dependency of aliroot on Mylib doesn't hold anymore and the executable isn't relinked when the library has been rebuilt. [...] I even tried to do add_dependencies(aliroot path to the library/libMylib.so) but it does not work. [...] ADD_DEPENDENCIES() only works on targets, not on files. [...] Any hint? Thanks! [1] http://www.cmake.org/Wiki/CMake_RPATH_handling [2] http://www.cmake.org/pipermail/cmake/2011-January/041647.html [3] http://www.cmake.org/Wiki/CMake_2.6_Notes#Link_Line_Generation Regards, 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] Boost macro behavior with respect to version
On 02/10/2011 09:17 PM, Adams, Brian M wrote: I'm curious if the behavior I'm seeing with respect to FindBoost.cmake is expected. (I realize I'm using these macros in a convoluted way, so understand if I can't make it work more cleanly.) What I'd like to be able to do is something like the following to probe for a system-provided or user-specified Boost, but then fall back on a distributed one that comes with our software as needed (probably in config instead of module mode, but that's for another day): find_package(Boost 1.40) if (NOT Boost_FOUND) set(BOOST_ROOT /path/to/boost/in/our/tree) find_package(Boost 1.40 REQUIRED) endif() I get problems with this, e.g., on RHEL5, which has Boost 1.33 installed. The first find fails due to version too low, then the second find doesn't probe because it detects Boost settings in the cache. After the first probe (and in the end) Boost_FOUND is false, AND the include and lib dirs for Boost are set to the 1.33 install location, which is misleading. It seems odd to me that these variables get set even though the probe failed. I can perform a workaround where I trick FindBoost.cmake to not use the cache: find_package(Boost 1.40) if (NOT Boost_FOUND) unset(Boost_INCLUDE_DIR CACHE) # these not needed, but could do to be safe: #unset(Boost_LIBRARY_DIRS CACHE) #unset(Boost_LIB_VERSION CACHE) #unset(Boost_VERSION CACHE) set(BOOST_ROOT /path/to/boost/in/our/tree) find_package(Boost 1.40) endif() Then I end up with the 1.40 that I'd expect. This seems likely to bite me down the road. How (besides requiring the user to have sufficiently new Boost on their system), should I handle this? Thanks, Brian Without having inspected FindBoost.cmake in detail, I think what you report here is a fundamental problem of find modules in general: They don't clean up if they're about to return with a negative result, i.e. XXX_FOUND==FALSE. Particularly, they leave variables in the cache that stem from diverse find function calls, and if some of these calls have succeeded, a following invocation of the same module can't perform the search again because the find functions are prevented to do so by the positive results in the cache. Even quite simple find modules like FindJPEG.cmake show that behaviour: Suppose you've the runtime component, i.e. the library only, installed from the distribution and another full installation in, say, /opt/jpeg. If you say FIND_PACKAGE(JPEG) without hinting CMake at the latter path, you would end up with JPEG_FOUND==FALSE as well as JPEG_INCLUDE_DIR== JPEG_INCLUDE_DIR-NOTFOUND but JPEG_LIBRARY==/usr/lib/libjpeg.so, so a following FIND_PACKAGE(JPEG) with, e.g., CMAKE_PREFIX_PATH==/opt/jpeg set before will result in JPEG_FOUND==TRUE with JPEG_INCLUDE_DIR==/opt/jpeg/include JPEG_LIBRARY==/usr/lib/libjpeg.so which means a non-matching combination of header and library. While one hardly calls FindJPEG.cmake more than once in this manner, there're quite good occasions to do so with more complex find modules like FindBoost.cmake, especially if they support the specification of a version via FIND_PACKAGE() as your scenario clearly shows, cf. [1]. An obvious solution would be to unset the concerned variables in the cache if the module is going to return with a negative result so that a subsequent invocation of the find module can start all over again. OTOH, if you configure with -DXXX_LIBRARY=... on the command line or a GUI, you'd probably expect this to be respected by all invocations of FindXXX.cmake throughout the entire project, so the module would need to keep track of which variables are passed in from the outside and which ones are actually set by the module. Of course, this would complicate things a lot when writing find modules. IMO, the best approach to address this issue in your case is the one you presented above: Explicitly unset the concerned variables in the cache before performing the search again with a modified BOOST_ROOT. Alternatively, you might simply bail out if Boost 1.40 has not been found and instruct the user to throw away the cache and reconfigure with BOOST_ROOT set appropriately - or provide a dedicated option, e.g. USE_INTERNAL_BOOST, to handle this in your CMakeLists.txt. Note that there's no such issue with configuration files: A negative result from FIND_PACKAGE() in config mode means that no config file has been found or all version files have declared their package as incompatibe. In either case, no config file has been processed, so there can't be any legacies in the cache. Regards, Michael [1] http://www.mail-archive.com/cmake@cmake.org/msg34515.html ___ 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
Re: [CMake] linking static vs dynamic
On 02/12/2011 09:39 PM, Andreas Pakulat wrote: On 12.02.11 21:20:58, Dominik Szczerba wrote: I never actually saw a solution to this problem in cmake: I need to link (independent constraint from above) with libguide.a and not libguide.so (in intel compiler, does not matter much), but both are available, and cmake always takes the shared one when given guide as the desired library to be linked. Is there an elegant way of static linking (other than -static passed to the linker for static linking of everything) of this particular lib other than hacking (like deleting the .so from the folder)? No, i.e. no elegant way. What you can do is force cmake to search only for .a files by setting a cmake variable, unfortunately I don't remember which one and can't easily find it right now. The archive of this list has more info as well as the cmake manual or the FAQ on the cmake website. Andreas Hi Dominik, it's CMAKE_FIND_LIBRARY_SUFFIXES; setting it to .a on *nix makes FIND_LIBRARY() search for static libraries only. It can be set to its original value at any time to restore the previous behaviour. However, if you know that you're looking exactly for libguide.a and have control over the FIND_LIBRARY() call, i.e. it's not buried in a find module or config file, you should follow Alexander's advice, use the library's full name in FIND_LIBRARY() and pass the latter's result to TARGET_LINK_LIBRARIES(). Regards, 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] Question about ADD_CUSTOM_COMMAND
On 02/12/2011 03:00 PM, Carminati Federico wrote: Dear All, I have a question about ADD_CUSTOM_COMMAND. I read in the doc If DEPENDS specifies any target (created by an ADD_* command) a target-level dependency is created to make sure the target is built before any target using this custom command. Additionally, if the target is an executable or library a file-level dependency is created to cause the custom command to re-run whenever the target is recompiled. However if I add to the DEPENDS list a target built with ADD_CUSTOM_TARGET, first the target is correctly scanned and built, then make crashes because it considers it also a file dependencies and looks for a file with the same name of the target. Is this the normal behaviour? I can fix it with ADD_CUSTOM_TARGET(all-todo COMMAND touch all-todo) ADD_CUSTOM_COMMAND(OUTPUT ... COMMAND ... DEPENDS all-todo ) See http://public.kitware.com/Bug/view.php?id=11332#c22532. This should be fixed in CMake 2.8.4. Regards, 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] find_package, quiet and yyyConfig files
On 02/10/2011 09:03 AM, Micha Renner wrote: There is a library, which is described with these TLIBConfig.cmake, TLIBConfigVersion.cmake files (The version of the library is 2.1). The library is used by FIND_PACKAGE(TLIB 2.30 QUIET) Is there a way to check the version of the library after FIND_PACKAGE? E.g., if TLIB_VERSION would have a value, then the library exists, but has the wrong version. Micha AFAICS from the documentation in [1], FIND_PACKAGE() is not obliged to set TLIB_VERSION et al. if no acceptable TLIBConfig[Version].cmake has been found, and that's quite reasonable: Suppose you've multiple TLIB installations, and all of them have inacceptable versions; which one would you expect to be mentioned in TLIB_VERSION? IMO, the best you can do in order to find out an available package's actual version after the search for a specific version has failed is: FIND_PACKAGE(TLIB 2.30 QUIET) IF(NOT TLIB_FOUND) FIND_PACKAGE(TLIB QUIET) # Check actual version. ENDIF() Here, of course, I'm relying on the assumption that a FIND_PACKAGE() call without version means that I'm willing to accept any version, and that the package's version file behaves accordingly. Regards, Michael [1] http://www.cmake.org/Wiki/CMake/Tutorials/Packaging#Package_Version_Files ___ 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] feed parsed information from source files into compile process
On 02/10/2011 02:11 PM, Verweij, Arjen wrote:
Thanks Tyler,
-Original Message-
From: Tyler Roscoe [mailto:ty...@cryptio.net]
You can't use add_custom_command() to drive this because the results of
any custom commands will only be available at build time. You need stuff
to happen at CMake configure time.
I noticed. Add_custom_target(foo ALL ... ) results are only processed at
make+1 and not immediately :(
Hence, I would use execute_process() to run your python script at
configure time. It would deposit its results into a file, which you
could then include() (or file(READ ...)).
While this does work, it will only function properly if cmake needs to run.
If for whatever reason (say a -O2/-O3 omp compiler bug in xlf_r ;) ) you
change the in-file compiler flags they will not be picked up until you run
cmake.
I'm gonna try a few things, but I'm not too hopeful :P
Regards,
Arjen
Possibly, you might do the following in your top-level CMakeLists.txt:
IF(NOT EXITST file-to-include)
EXECUTE_PROCESS(COMMAND generate-file-to-include)
ENDIF()
INCLUDE(file-to-include)
...
# Add targets/subdirectories/etc.
...
ADD_CUSTOM_TARGET(world
COMMAND generate-file-to-include
COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR}
)
The initial CMake run generates file-to-include, includes it and
proceeds as usual. Each following make world regenerates file-to-
include and rebuilds the project, and if file-to-include has been
actually touched, CMake will notice this via the INCLUDE() command and
reconfigure-before-rebuild. Furthermore, if generate-file-to-include
takes care of not touching file-to-include as long as the latter does
not change - cf. CONFIGURE_FILE() - you will avoid most of the overhead.
If I got your concern right, file-to-include is your override.cmake,
and generate-file-to-include is your Python script.
The downside is that you can't say just make anymore. However, you
may mark the custom target world with ALL, establish dependencies
of the ordinary targets on world and find a way to avoid an infinite
recursion. So, you can just say make, and the ordinary targets will
be built and finally checked for being up to date once more. To avoid
the recursion you could use a CMake script in junction with a marker
file, e.g.
ADD_CUSTOM_TARGET(world ALL
COMMAND ${CMAKE_COMMAND}
-D BINDIR=${CMAKE_BINARY_DIR}
-P ${CMAKE_SOURCE_DIR}/world.cmake
)
and a ${CMAKE_SOURCE_DIR}/world.cmake like:
IF(NOT EXISTS marker-file)
FILE(WRITE marker-file )
EXECUTE_PROCESS(COMMAND generate-file-to-include)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} --build ${BINDIR})
FILE(REMOVE marker-file)
ENDIF()
Of course, this approach is not of maximum elegance, but if your
CMakeLists.txt's dependency on extractable contents of your source
files really matters, there's at least one option how to address it.
'hope that helps.
Regards,
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] Recompiles everything every time
On 02/10/2011 09:47 PM, Collier, Jack wrote:
I have a large project that I recently converted from autotools to cmake.
Everything works great save for the fact that everytime I make the project
every single source file is recompiled. I think the reason is that my build
relies on a number of custom targets this generate a bunch of header files
that are used by almost all the other sources in the project. According to
the documentation for add_custom_target the target is always considered out
of date so it will recompile everytime. Is there anyway to get around this
and only compile if something has changed? I have included one of the custom
targets and the associated custom command below:
#Add command to compile IDL files
ADD_CUSTOM_TARGET(CompileIdl ALL)
ADD_CUSTOM_COMMAND(
DEPENDS ${TAO_IDL}
COMMAND ${TAO_IDL} -in -hc C.h -cs C.cpp -ci C.i.h -hs S.h -hT S_T.h
-ss S.cpp -sT S_T.cpp -si S.i.h ${IDL_INCLUDES} ${SRC_FINAL}
TARGET CompileIdl
OUTPUTS ${IDL_CLIENT_CPP} ${IDL_CLIENT_H} ${IDL_CLIENT_IH}
${IDL_SERVER_CPP} ${IDL_SERVER_H} ${IDL_SERVER_IH}
)
#Now compile the generated sources
SET(BUILT_SOURCES ${IDL_CLIENT_CPP} ${IDL_CLIENT_H} ${IDL_CLIENT_IH}
${IDL_SERVER_CPP} ${IDL_SERVER_H} ${IDL_SERVER_IH} )
SET_SOURCE_FILES_PROPERTIES(${BUILT_SOURCES} PROPERTIES GENERATED true)
Don't attach the custom command to the custom target, but make the
latter depend on the former, i.e. don't use the TARGET signature:
ADD_CUSTOM_COMMAND(
OUTPUT ${IDL_CLIENT_CPP} ${IDL_CLIENT_H} ${IDL_CLIENT_IH}
${IDL_SERVER_CPP} ${IDL_SERVER_H} ${IDL_SERVER_IH}
COMMAND whatever-necessary-to-generate-the-output-files
DEPENDS all-prerequisites-of-the-output-files-to-generate
)
ADD_CUSTOM_TARGET(CompileIdl ALL
DEPENDS ${IDL_CLIENT_CPP} ${IDL_CLIENT_H} ${IDL_CLIENT_IH}
${IDL_SERVER_CPP} ${IDL_SERVER_H} ${IDL_SERVER_IH}
)
Although the custom target is always out of date, the custom command
runs only if an OUTPUT file doesn't exist or a prerequisite after the
DEPENDS clause is newer. For this to work well, it is inevitable that:
1) The custom command carefully denotes all OUTPUT files - BTW, the
option is named OUTPUT, not OUTPUTS, and you don't need to set the
GENERATED property for these files explicitly.
2) The custom command carefully denotes all prerequisites of the OUTPUT
files after the DEPENDS clause, i.e. everything that should trigger
the OUTPUT files' regeneration when it's changed.
3) The custom target carefully denotes the custom command's OUTPUT
files as prerequisites after its DEPENDS clause.
If not all of the OUTPUT files depend on each prerequisite after the
DEPENDS clause, consider to use multiple custom commands in order to
reduce the dependency graph as far as possible, but no further. ;)
'hope that helps.
Regards,
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 specify $1 for compiler?
On 02/08/2011 08:12 PM, Jed Brown wrote:
On Mon, Feb 7, 2011 at 23:35, Jed Brown j...@59a2.org wrote:
On Fri, Feb 4, 2011 at 01:31, Michael Hertling mhertl...@online.dewrote:
With a Makefile generator, you might use a RULE_LAUNCH_COMPILE property:
SET_TARGET_PROPERTIES(target PROPERTIES RULE_LAUNCH_COMPILE win32fe)
Thanks for these suggestions. I went with this one, but I'll try the other
if someone complains (win32fe implies cygwin, I don't know if native Visual
Studio builds make sense in that context).
Hmm, although the Makefile would work, the compiler tests do not succeed
because they don't use these properties. Where do I have to munge
CMAKE_LANG_COMPILE_OBJECT to have that version used when testing whether a
compiler works?
First of all, IIRC, if you need the win32fe wrapper for the compiler
tests, too, you must enable it for the whole project, i.e. you won't
be able to use the plain compiler without win32fe anymore.
On *nix with a simple C project, I can see the following work:
% CC=env gcc cmake srcdir # Initial configuration!
-- The C compiler identification is GNU
-- Check for working C compiler: /usr/bin/env
-- Check for working C compiler: /usr/bin/env -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
[...]
% make VERBOSE=1
[...]
[...] Building C object CMakeFiles/main.dir/main.c.o
/usr/bin/env gcc -o CMakeFiles/main.dir/main.c.o -c [...]/main.c
[...]
Although CMAKE_C_COMPILER turns out to be /usr/bin/env, the gcc is
always in on it. Thus, setting FC=win32fe f90 before the very first
invocation of CMake on your project will possibly enable the win32fe
wrapper along with the Fortran compiler for the compiler tests as well
as for the actual compilations. If you want to enforce that, you might
have a SET(ENV{FC} win32fe f90) in your CMakeLists.txt ahead of the
PROJECT() or ENABLE_LANGUAGE() command. In this way, you do not need
the RULE_LAUNCH_COMPILE property. If things keep failing, you should
consider to use a platform file for win32fe as Bill Hoffman already
mentioned.
'hope that helps.
Regards,
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] get_target_property( LOCATION) and CMAKE_DEBUG_POSTFIX (aka: Installing PDB files)
On 02/07/2011 08:54 PM, Mathieu Malaterre wrote: Dear all, I am trying to retrieve the full path of a dll to be able to compute the full path of the associated pdb file. I thought I could simply use the get_target_property( LOCATION) API, however it fails to return the actual name of the TARGET, for instance the value of CMAKE_DEBUG_POSTFIX it not taken into account (using cmake 2.8.3). AFAIK, the LOCATION property is deprecated right because it doesn't work well with different configurations, see [1] and especially [2]. Is there another API to retrieve the path to a dll file generated by cmake from its target name ? Have you already tried the LOCATION_CONFIG target property? ^ Perhaps, you might also use the RUNTIME_OUTPUT_DIRECTORY[_CONFIG] and [RUNTIME_]OUTPUT_NAME[_CONFIG] target properties to pre-construct the target's full path, possibly in junction with the CONFIG_POSTFIX and PREFIX properties or the CMAKE_SHARED_LIBRARY_(PREFIX|SUFFIX)[_LANG] variables. In CMake 2.8.4, there will be generator expressions for custom targets/ commands, so if you need the target's full path within the latters, you should take a look at the latest 2.8.4 RC. Regards, Michael [1] http://public.kitware.com/Bug/view.php?id=11671 [2] http://public.kitware.com/Bug/view.php?id=11671#c24538 ___ 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] FindTCL.cmake has a problem?
On 02/03/2011 04:10 PM, kent williams wrote: Unfortunately, I can't provide this because we had to get the builds running, and installed the proper packages. But I don't think I was imagining things. Far be it from me to impute this, but your report contains fairly little information to investigate this issue. The reasons for my remarks/questions are: - Sometimes, distributions tend to fix packages, so it would be of interest if your FindTCL.cmake is identical with the official one. - The results you've reported could be obtained by a manipulation of the cache, e.g. if somebody who knows that the headers are absent configures with cmake -DTCL_INCLUDE_PATH=TRUE srcdir and does cmake -DTCL_INCLUDE_PATH=TCL_INCLUDE_PATH-NOTFOUND . afterwards. So, it would be of interest which output/result is generated by a FIND_PACKAGE(TCL) being run from within a clean environment/cache. - FIND_PACKAGE_HANDLE_STANDARD_ARGS() has undergone a major overhaul recently, so it would be of interest whether you are using the new version because your issue possibly reveals a regression, although I don't think so. IMO, you are absolutely right when saying that TCL_FOUND==TRUE with TCL_INCLUDE_PATH==FALSE certainly means some trouble, so this issue should be worth to take a closer look at. Regards, Michael On Wed, Feb 2, 2011 at 6:57 AM, Michael Hertling mhertl...@online.de wrote: On 01/31/2011 05:26 PM, kent williams wrote: I found this out on a RHEL6 machine, which comes stock with tclsh and wish but without the C header files for development. FindTCL.cmake sets TCL_FOUND, even though TCL_INCLUDE_PATH:PATH=TCL_INCLUDE_PATH-NOTFOUND Imagine the hilarity that ensues! The FindTCL module from CMake 2.8.3 contains the line FIND_PACKAGE_HANDLE_STANDARD_ARGS(TCL DEFAULT_MSG TCL_LIBRARY TCL_INCLUDE_PATH) so TCL_FOUND shouldn't come out as TRUE if TCL_INCLUDE_PATH isn't TRUE also. Is the questionable FindTCL module the same as the official one? Could you provide the complete output of a FIND_PACKAGE(TCL) resulting in TCL_FOUND==TRUE and TCL_INCLUDE_PATH==FALSE from a clean build? Regards, 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] The CMake bug tracker and the backlog of unresolved issues
On 02/03/2011 11:34 PM, David Cole wrote: Hello CMakers, The CMake issue tracker is located at: http://public.kitware.com/Bug All of the issues except for the most recent 15 or so have been assigned and looked at by at least one CMake developer at one point in each issue's history. However, not all issues that are assigned to developers are being actively worked on. Personally, I have just over 100 issues assigned to me, and I know it would take me on the order of months to work through all of them, even if I were able to work on them full time. I would like very much for us to introduce the notion of a backlog in the CMake bug tracker, where we can send bugs that are not being actively worked on, and we can review the backlog periodically for issues that should be brought forward into active development again. Since we do not have a status of backlog -- but we don't really use the status values of acknowledged or confirmed very much, I am thinking we could define backlog as: status=acknowledged AND assigned to= (empty string, none) As an exemplar, I just sent this one to the backlog by setting its status and de-assigning it: http://public.kitware.com/Bug/view.php?id=7867 Does this seem like a reasonable technique? Any comments or questions before we start sending more things to the backlog? When we send around the request (coming up soon, after the final 2.8.4 release is ready) to vote for your favorite issues... you'd still be able to vote for things in the backlog. And if we can find somebody willing to do the work, we'll assign it to them and set status=assigned again... Let me know what you think -- thanks for reading, Spontaneously, I like this idea of dividing the issues into the ones in progress and the ones in backlog. If someone is interested in an issue, it's quite helpful to see whether it is currently worked on to either - annoy the assigned developer when it will be finished, how it will look like, if additional features could be incorporated etc. ;-) or - ask for support on the mailing list in order to (re)activate it, or - start working on it without the risk that the effort will become obsolete by a CMake developer's parallel work in the meantime. However, IMO, the introduction of a backlog should be accompanied by a mechanism - possibly a quite informal one - how to bring an issue into the active development state. Periodical reviews, e.g. several times a year corresponding to CMake's new release cycle, are certainly a good foundation. Additionally, substantial contributions to an issue could be a suitable indicator for this purpose, too, as they usually denote a serious interest. So, if there're qualified proposals, constructive criticisms, patches with tests and the like since the latest review, this should be regularly used as an opportunity to (re)consider the particular issue for active development. In summary, I think that a backlog could help in multiple aspects: The CMake developers can focus on explicitly fewer issues at the same time, the users see if a solution for a specific issue is about to arrive in the near future, and people willing to contribute can pick up an issue and be sure not to get in the official development's way, so as for me, feel encouraged. Regards, 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] CMake removing duplicated static libraries from target_link_libraries list?
not necessary to resolve any known dependencies. An obvious solution is to fill the gap in the dependency graph, either by including the TrajGeom library as a target in your project or by treating it as an imported target and declaring its dependencies by hand: ADD_LIBRARY(TrajGeom STATIC IMPORTED) SET_TARGET_PROPERTIES(TrajGeom PROPERTIES IMPORTED_LOCATION full/path/to/libTrajGeom.a IMPORTED_LINK_INTERFACE_LIBRARIES BbrGeom ) After having done this, you'll probably see libBbrGeom.a reappear a second time in the link command following the - now - libTrajGeom.a. The other phenomena have different causes, IMO: - libboost_regex.a is dropped once from LIB_LINK_LIST because only the second occurrence is necessary, so it finally appears twice in the link command, the first time from BIN_LINK_LIST and the second one is the remaining occurrence from LIB_LINK_LIST. - ErrLogger, CLHEP etc. are external libraries which are mentioned with -l in the link command, and CMake can't know their interdependencies, so it doesn't drop any of them. OTOH, as discussed above, BbrGeom as one of the project's targets can be tracked w.r.t. its dependencies and, thus, is subject to CMake's optimization of the link command. In conclusion, I don't think that CMake's behavior you've reported is a bug or has anything to do with libraries treated as static or shared or the like. Of course, feel free to ask further if I missed your issue. Regards, Michael On 2/2/11 4:13 PM, Michael Hertling wrote: On 02/02/2011 03:04 PM, Marco wrote: Hi all, I'm wondering, if I understood correctly the behaviour of CMake, whether there'a a way to prevent CMake from deleting duplicated libraries in a target_link_libraries list. I have an executable which links against (all static) libraries A, B and C. A itself links against C,D,E... and so on. When CMake creates the link.txt file what I see is: c++ -o myExe -lA -lC -lD -lE -lB that is cmake links the executable against A followed by its dependents, then against B but not against C. The point is that B needs C to follow it as B depends on C. This is why I suspect that CMake removes the duplicated libraries listed in a target_link_libraries directive. Is it correct? And is there a way to force CMake to preserve exactly the list of libraries passed to target_link_libraries? If B depends on C without C appearing after B in the link command, this probably means that CMake isn't aware of the B-on-C dependency, so how do you establish the latter? Could you provide a minimal but complete example which demonstrates this issue? AFAIK, CMake does not remove libraries from the link command if they are necessary to resolve any dependencies and if these dependencies are set up correctly, so the libraries' exact order - for library targets - is nothing the user usually needs to worry about. Regards, 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 specify $1 for compiler?
On 02/03/2011 08:30 PM, Jed Brown wrote:
I need to build a compilation command of the form
win32fe f90 -with -options -and source.f -o path/to/source.f.o
but setting CMAKE_Fortran_COMILER=/path/to/win32fe and
CMAKE_Fortran_FLAGS=f90 -with -options does not work because CMake places
other options in between:
win32fe -o path/to/source.f.o -with -options source.f
which does not work because win32fe needs the compiler to come first. Note
that the C compiler seems to place the -o options later so
CMAKE_C_COMPILER=/path/to/win32fo CMAKE_C_FLAGS=cl -with -options is
working.
Is this difference in options placement intentional? Is there a robust way
to make something be $1 in the command line?
With a Makefile generator, you might use a RULE_LAUNCH_COMPILE property:
SET_TARGET_PROPERTIES(target PROPERTIES RULE_LAUNCH_COMPILE win32fe)
This prepends win32fe to the Makefile's command lines which compile
the target's object files. Additionally, the special placeholders in
CMAKE_LANG_COMPILE_OBJECT et al. are expanded in those launchers,
so a RULE_LAUNCH_COMPILE property like, e.g.,
myscript CMAKE_C_COMPILER -o OBJECT -c SOURCE DEFINES FLAGS --
would invoke myscript with the defines and the flags moved behind
the source and the object file. The -- is intended to delimit the
launcher from the actual command line, so myscript can take the
parameters up to that mark and ignore the remaining ones in order
to construct an arbitrary command line to execute; see [1,2] for
further examples.
As a last resort, you might manipulate CMAKE_LANG_COMPILE_OBJECT.
IIRC, these variables are directory-specific, so you can possibly
SET(CMAKE_Fortran_COMPILE_OBJECT
win32fe CMAKE_Fortran_COMPILER ...
)
or
SET(CMAKE_Fortran_COMPILE_OBJECT
win32fe ${CMAKE_Fortran_COMPILE_OBJECT}
)
to define suitable Fortran compilation commands for a directory.
'hope that helps.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg29622.html
[2] http://www.mail-archive.com/cmake@cmake.org/msg34148.html
___
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] FindTCL.cmake has a problem?
On 01/31/2011 05:26 PM, kent williams wrote: I found this out on a RHEL6 machine, which comes stock with tclsh and wish but without the C header files for development. FindTCL.cmake sets TCL_FOUND, even though TCL_INCLUDE_PATH:PATH=TCL_INCLUDE_PATH-NOTFOUND Imagine the hilarity that ensues! The FindTCL module from CMake 2.8.3 contains the line FIND_PACKAGE_HANDLE_STANDARD_ARGS(TCL DEFAULT_MSG TCL_LIBRARY TCL_INCLUDE_PATH) so TCL_FOUND shouldn't come out as TRUE if TCL_INCLUDE_PATH isn't TRUE also. Is the questionable FindTCL module the same as the official one? Could you provide the complete output of a FIND_PACKAGE(TCL) resulting in TCL_FOUND==TRUE and TCL_INCLUDE_PATH==FALSE from a clean build? Regards, 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] Action to perform unconditionally
On 02/02/2011 01:44 PM, Ilja Golshtein wrote: Hello! I am trying to generate version.h in my project as described http://addisu.taddese.com/blog/inserting-svn-revision-number-in-your-cc-code/ I think the most natural place to do it is my project root CMakeLists.txt. The problem is it does not contain any target - just setting some variables and add_subdirectory(src) The question is what is the best way to perform an action make-time unconditionally. You might use a custom target to trigger a CMake script which invokes EXECUTE_PROCESS() to query Subversion for the current revision number and CONFIGURE_FILE() to transform a version.h.in template into the desired version.h header. Finally, use ADD_DEPENDENCIES() to establish a dependency of your targets on the custom target. See [1] for a quite similar example. Regards, Michael [1] http://www.mail-archive.com/cmake@cmake.org/msg29944.html ___ 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] Action to perform unconditionally
On 02/02/2011 02:27 PM, Ilja Golshtein wrote: Michael, the problematic step is ADD_DEPENDENCIES. I don't have any suitable target. The referred CMakeLists.txt has main/main.c. Unfortunately mine does not - just add_subdirectory. But in the subdirectory, there's a target, isn't it? So, just use ADD_DEPENDENCIES() there; with CMake, targets are global entities. Regards, 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] Action to perform unconditionally
On 02/02/2011 03:11 PM, Ilja Golshtein wrote: 02.02.2011, 16:42, Michael Hertling mhertl...@online.de: On 02/02/2011 02:27 PM, Ilja Golshtein wrote: the problematic step is ADD_DEPENDENCIES. I don't have any suitable target. The referred CMakeLists.txt has main/main.c. Unfortunately mine does not - just add_subdirectory. But in the subdirectory, there's a target, isn't it? So, just use ADD_DEPENDENCIES() there; with CMake, targets are global entities. No, there is not - just another bunch of add_subdirectory ;) But *somewhere* in your project, there is a target? 8| Obviously I can choose arbitrary executable and link my target to it. Preferably, choose the targets which need the version.h header. I am just looking for better solution ... As simple as Phony target. Another possible approach would be a dependency of the built-in target all on the custom target which generates the header, so consider to vote for #8438 when the question for the most appreciated bug fixes / feature requests will be asked again. Regards, 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] CMake removing duplicated static libraries from target_link_libraries list?
On 02/02/2011 03:04 PM, Marco wrote: Hi all, I'm wondering, if I understood correctly the behaviour of CMake, whether there'a a way to prevent CMake from deleting duplicated libraries in a target_link_libraries list. I have an executable which links against (all static) libraries A, B and C. A itself links against C,D,E... and so on. When CMake creates the link.txt file what I see is: c++ -o myExe -lA -lC -lD -lE -lB that is cmake links the executable against A followed by its dependents, then against B but not against C. The point is that B needs C to follow it as B depends on C. This is why I suspect that CMake removes the duplicated libraries listed in a target_link_libraries directive. Is it correct? And is there a way to force CMake to preserve exactly the list of libraries passed to target_link_libraries? If B depends on C without C appearing after B in the link command, this probably means that CMake isn't aware of the B-on-C dependency, so how do you establish the latter? Could you provide a minimal but complete example which demonstrates this issue? AFAIK, CMake does not remove libraries from the link command if they are necessary to resolve any dependencies and if these dependencies are set up correctly, so the libraries' exact order - for library targets - is nothing the user usually needs to worry about. Regards, 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] namespace support
On 02/02/2011 04:21 PM, Peter Kümmel wrote:
On 02.02.2011 16:17, Michael Wild wrote:
namespace(a)
include_directories(a)
add_library(a MODULE a/a.cpp)
endnamespace()
Put a CMakeLists.txt file in a/ and b/ and do the include_directories()
Exactly this is what I don't wanna do and why I've asked ;)
Seems it becomes a feature request.
Indeed, the restriction of INCLUDE_DIRECTORIES() is sometimes annoying;
having INCLUDE_DIRECTORIES target and source file properties available
along with the directory property - analogous to COMPILE_DEFINITIONS -
would be quite welcome, IMO. However, if your plugins are built in a
sufficiently unique manner, you might automate this process by use of
a CMake function:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(PLUGINS C)
FILE(WRITE ${CMAKE_SOURCE_DIR}/f/f.c void f(void){}\n)
FILE(WRITE ${CMAKE_SOURCE_DIR}/g/g.c void g(void){}\n)
FILE(WRITE ${CMAKE_SOURCE_DIR}/h/h.c void h(void){}\n)
FUNCTION(ADD_PLUGINS)
FOREACH(i IN LISTS ARGN)
IF(NOT IS_ABSOLUTE ${i})
SET(i ${CMAKE_CURRENT_SOURCE_DIR}/${i})
ENDIF()
GET_FILENAME_COMPONENT(t ${i} NAME_WE)
GET_FILENAME_COMPONENT(p ${i} PATH)
GET_FILENAME_COMPONENT(d ${p} NAME)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/${d}/CMakeLists.txt
INCLUDE_DIRECTORIES(${p})\nADD_LIBRARY(${t} MODULE ${i})\n)
ADD_SUBDIRECTORY(${CMAKE_CURRENT_BINARY_DIR}/${d}
${CMAKE_CURRENT_BINARY_DIR}/${d})
ENDFOREACH()
ENDFUNCTION()
ADD_PLUGINS(f/f.c g/g.c h/h.c)
For each plugin, the ADD_PLUGINS() function creates a directory and
provides a CMakeLists.txt which builds the plugin with an individual
search path for header files. Possibly, that approach can be adapted
to your needs.
Regards,
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] Adding a custom line to CMake's makefiles?
On 02/02/2011 03:34 PM, Clifford Yapp wrote:
Is there any way to customize the Makefile output from CMake to
include user-defined lines (say, something like #include
Makefile.inc) at the end of each Make file?
With GNU Make, you might do the following:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(INCLUDEMAKEFILE C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/Makefile.inc # Makefile.inc\n)
ADD_CUSTOM_COMMAND(
OUTPUT includemarker
COMMAND ${CMAKE_COMMAND} -E touch includemarker
COMMAND ${CMAKE_COMMAND} -E echo
include ${CMAKE_BINARY_DIR}/Makefile.inc
\$\(firstword \$\(MAKEFILE_LIST\)\)
)
ADD_EXECUTABLE(main main.c includemarker)
The $(firstword $(MAKEFILE_LIST)) provides access to the currently
processed Makefile, so you can plant additional lines from within a
custom command. However, this approach is neither portable nor clean
nor your-expectation-here, so I would ask Eric's questions, too. ;)
Regards,
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] Find_package: general question
On 01/21/2011 02:59 PM, Vincent Garcia wrote:
Dear CMake users,
I have this BIG project which has tons of subdirectories (many levels).
In each (final) subdirectory, I create targets (executables and libraires).
So I have my top level CMakeLists.txt and one CMakeLists.txt file (which is
also a project) in each subdirectory.
Everything compiles just fine!
My question is a general CMake question and is the following:
Imagine I can use ITK in my project. To do that, in the top level
CMakeLists.txt I define a variable USE_ITK.
If ITK is used, I search for it and I include useful files:
OPTION(USE_ITK If ON, search for Insight Toolkit package OFF)
IF(USE_ITK)
FIND_PACKAGE(ITK)
IF(ITK_FOUND)
INCLUDE(${ITK_USE_FILE})
ELSE(ITK_FOUND)
MESSAGE(FATAL_ERROR ITK not found. Please set ITK_DIR.)
ENDIF(ITK_FOUND)
ELSE(USE_ITK)
SET(ITK_FOUND OFF)
ENDIF(USE_ITK)
Now, if one subdirectory's project uses ITK, I have the following code (in
the subdir's CMakeLists.txt):
FIND_PACKAGE( ITK )
IF( NOT ITK_FOUND )
MESSAGE( Project ${PROJECT_NAME} requires ITK and ITK was not found.
${PROJECT_NAME} will not be built. )
RETURN()
ENDIF()
INCLUDE( ${ITK_USE_FILE} )
As you can see, find_package(ITK) and INCLUDE( ${ITK_USE_FILE} ) are at least
called twice (in fact much more).
Is there any performance issue the method describe above?
Usually, find modules save their results in CMake's cache to avoid any
repetitive searching for the same executables/libraries/files/... when
invoked multiple times. E.g., the FIND_{PROGRAM,LIBRARY,...}() commands
- which are used heavily in find modules - store their positive results
in cached variables and don't perform their particular search again if
these variables don't evaluate to -NOTFOUND. In general, well written
find modules ensure that it is safe and cheap to call them more than
once, so the performance penalty due to multiple invocations should
be bearable, ideally even negligible.
Since it's not my code and since i'm a CMake newbee, I'd like to understand
if this is normal.
I would say that this should be done once in the top level CMakeLists.txt.
In the subdirs' CMakeLists, we should use only ITK_FOUND to decide if we
build the target or not.
Some people of my team agree and some don't.
For several reasons, I'd join the latter group. ;) Please note that the
following remarks are just my personal opinion, and of course, one can
take up a different position.
Basically, your approach tends to collect information about the needs
of your subprojects/submodules in the top-level CMakeLists.txt which
is in opposition to a good modularization and a tight locality. E.g.,
if one of your subprojects, situated deep in the overall project's
directory tree, needs package XXX, the top-level CMakeLists.txt must
know this fact to enable XXX by FIND_PACKAGE(XXX). As a result, your
top-level CMakeLists.txt must know and enable all prerequisites of
all subprojects which appears quite inconvenient to me, especially
if your subprojects are somewhat selfcontained.
When using multi-component packages, the situation might even become
worse: Suppose you have two subprojects, app1 uses QtGui while app2
uses QtXml. The top-level CMakeLists.txt according to your approach
would look like:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(APPS C CXX)
FIND_PACKAGE(Qt4 COMPONENTS QtCore QtGui QtXml)
INCLUDE(${QT_USE_FILE})
ADD_SUBDIRECTORY(app1)
ADD_SUBDIRECTORY(app2)
Now, look at the following app{1,2}/CMakeLists.txt:
# app1/CMakeLists.txt:
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/main.c
int main(void){return 0;}\n
)
ADD_EXECUTABLE(app1 main.c)
TARGET_LINK_LIBRARIES(app1 ${QT_LIBRARIES})
# app2/CMakeLists.txt:
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/main.c
int main(void){return 0;}\n
)
ADD_EXECUTABLE(app2 main.c)
TARGET_LINK_LIBRARIES(app2 ${QT_LIBRARIES})
With this configuration, app{1,2} get linked against Qt{Core,Gui,Xml},
i.e. both will be overlinked. This is a consequence of the joint list
of components in FIND_PACKAGE(Qt4 ...) for both subprojects; in other
words: A consequence of information about those subprojects' needs,
collected in the top-level CMakeLists.txt.
What is the best way to proceed?
In each sufficiently selfcontained subproject, one should issue the
FIND_PACKAGE() commands for all of the subprojects' prerequisites in
order to minimize the dependency on any higher-level CMakeLists.txt.
OTOH, if a subproject consists of several tightly connected modules,
e.g., it's possibly not appropriate to do the same for each module.
Instead, one might concentrate FIND_PACKAGE()'s invocations in the
subproject's CMakeLists.txt and let the modules inherit the results
as long as there are no difficulties like the one mentioned above.
Probably, the question of concentrating or distributing FIND_PACKAGE()
calls for prerequisites in extensive projects, or finding a reasonable
trade-off,
Re: [CMake] Produce only an object file (*.o) from a CMake build target
On 01/24/2011 06:37 PM, Helseth, Nicholas H wrote:
I'm trying to build an object file using CMake, but I can't seem to get CMake
to build something other than a complete executable. I'm basically looking
for the result of the following compilation (the result will be loaded on a
VxWorks target and linked then-it needs to be a *.o because of the way our
build system works):
$(CC) $(CFLAGS) $(INC_DIRS) -c src/object.c
I've tried changing the OUTPUT_NAME property of the target, but that doesn't
seem to help, either.
I think I could work around this by using a custom command, but that seems
like I'm also working around the nice things that CMake provides.
Thanks for your help!
Look at the following ${CMAKE_SOURCE_DIR}/cpo script:
#!/bin/sh
d=$1; shift
while [ $1 != -- ]; do
cp $1 $d/$(basename $1); shift
done
Now, look at the following CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(CPO C)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(f SHARED f.c)
SET_TARGET_PROPERTIES(f PROPERTIES RULE_LAUNCH_LINK
${CMAKE_SOURCE_DIR}/cpo ${CMAKE_BINARY_DIR} OBJECTS --
)
The launch script cpo makes the target f produce object files in
the directory passed in as the first parameter instead of a library;
everything else should be business as usual. The key is the script's
access to the OBJECTS placeholder, so it can operate on the object
files while the actual link command after the -- is ignored. That
way, you can use all of CMake's capabilities for the compilation and
intercept right before linking takes place. IMO, that's a quite clean
solution which should be easily adaptable to your needs; the downside
is that the use of RULE_LAUNCH_LINK is limited to Makefile generators.
Regards,
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] Restrictions on where a binary can be put?
On 01/21/2011 08:47 AM, Andreas Pakulat wrote: On 21.01.11 01:37:41, Michael Hertling wrote: So, what's your conclusion in this matter? Should the behavior in question be considered as a bug or is it alright? IMO, such a subtle side effect of a read operation on a subsequent write operation is at least highly surprising. Besides, does one have to take this phenomenon into account elsewhere, i.e. when saying GET_TARGET_PROPERTY(VAR TARGET X) ... SET_TARGET_PROPERTIES(TARGET PROPERTIES Y ...) with X!=LOCATION and Y!=RUNTIME_OUTPUT_DIRECTORY, is it assured that the latter command works as expected? Are directory or source files properties possibly affected, too? Check the bugreport I mentioned further up in the thread. The docs have been expanded to mention this problem with LOCATION and RUNTIME_OUTPUT_DIRECTORY. As far as I understood Brad in the report its unique to those properties defining where a target ends up on disk (and how). And indeed (as he said also) changing the output directory _after_ querying it (via LOCATION) hints towards a bug in your cmake code, after all whatever you did with LOCATION is void if you change the output directory again and you'd have to re-run that code. Thanks for this hint, Andreas; I really should have taken a look at the bug tracker the day after you filed the report. ;) After one-and-a-half thought about that issue, it is rather obvious that changing a target's location on disk after querying the location results in strange effects one way or another. So, with the improved documentation and the already obsolete LOCATION property, it's certainly alright now. Regards, 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] Restrictions on where a binary can be put?
On 01/21/2011 04:41 PM, Alexander Neundorf wrote: On Friday 21 January 2011, Michael Hertling wrote: On 01/20/2011 07:01 PM, Alexander Neundorf wrote: On Sunday 09 January 2011, Michael Hertling wrote: ... I don't really understand why you want to get the LOCATION from your target, anyway, the get_target_property works fine if you use set_target_properties before it. [...] ...but SET_TARGET_PROPERTIES() doesn't work fine if it's used after GET_TARGET_PROPERTY(), even if both operate on different properties. Well, they are not completely different. If I remember correctly, the LOCATION property is calculcated when you query it. I think it changes some internal variables. Apparently to a state where setting the target property afterwards doesn't have the desired effect anymore :-/ So, what's your conclusion in this matter? Should the behavior in question be considered as a bug or is it alright? IMO, such a subtle IMO looks quite obvious like a bug. I just wanted to say that there is some connection between the properties. While this issue with the LOCATION/LOCATION_CONFIG properties has been clarified in #11671 in the meantime, I wonder whether there're more interconnections of that kind among other properties, just to be mindful of them when they emerge. So, does anybody have some information on this? Regards, 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] add_custom_command and generated true
On 01/25/2011 10:17 AM, Micha Renner wrote:
Recently, I learned that ADD_CUSTOM_COMMAND generated the property
GENERATED TRUE for the generated file.
Somehow I have trouble in this situation:
In a top level CMakeLists file a source file, blue.c, is generated. This
file should be used in a subdirectory with its own CMakeLists file.
Running CMake generates the message: cannot find blue.c etc...
Okay, the information, that this is a generated sourcefile is, maybe,
lost on the transition to the subdirectory.
The documentation of SET_SOURCE_FILES_PROPERTIES() states
Source file properties are visible only to targets added in the same
directory (CMakeLists.txt).
and GENERATED is a source file property, so it's not amazing that the
subdirectory's CMakeLists.txt doesn't recognize blue.c as generated,
even if the property is imposed by ADD_CUSTOM_COMMAND(OUTPUT ...).
So, I inserted in the CMakeLists file of subdirectory the line:
SET_SOURCE_FILES_PROPERTIES(blue.c PROPERTIES GENERATED TRUE)
which generates the make message
No rule to build target subdirectory/blue.c
Explicitly setting the GENERATED property here quiets CMake, but the
subdirectory's Makefile won't have a rule to generate blue.c because
the custom command is defined in the top-level CMakeLists.txt; from
the documentation of ADD_CUSTOM_COMMAND():
A target created in the same directory (CMakeLists.txt file)
that specifies any output of the custom command as a source file
is given a rule to generate the file using the command at build time.
So, the build will fail with the mentioned error message from make.
I changed the inserted line (see above) to...
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/blue.c
PROPERTIES GENERATED TRUE)
... which is okay.
AFAICS from your example, this works by accident: The custom target is
processed before make descends to the subdirectory, so blue.c already
exists when the cTest target gets built, and CMake is happy because
blue.c is marked as GENERATED in that *directory's* CMakeLists.txt.
Remove the ALL flag from the ADD_CUSTOM_TARGET() command, and you
will probably see your example fail, regardless if and how the
GENERATED property is set.
= Two question
- Is it general true, that properties are lost on transition to a
subdirectory?
This is true for the source file properties and for some directory
properties like EXCLUDE_FROM_ALL; the latter is not inherited by sub-
directories, but the COMPILE_DEFINITIONS directory property, e.g., is.
- In which cases is it absolute necessary to work with absolute paths
and SET_SOURCE_FILES?
IMO, the rule of thumb is: Use absolute paths where the behavior
for relative paths is not specified or not appropriate. E.g.,
ADD_CUSTOM_COMMAND(OUTPUT blue.c ...)
will generate ${CMAKE_CURRENT_BINARY_DIR}/blue.c, but which directory
SET_SOURCE_FILES_PROPERTIES(blue.c PROPERTIES ...)
bases on? For the GENERATED property, CMAKE_CURRENT_BINARY_DIR would be
reasonable, but for the LANGUAGE property, CMAKE_CURRENT_SOURCE_DIR
might suit better. Thus, SET_SOURCE_FILES_PROPERTIES() should be
invoked with absolute paths only.
BTW, you shouldn't do in-source builds, and do not write to the source
directories; it's bad style, doesn't play nicely with version control
systems and might be the reason for some quite subtle problems.
Regards,
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] Restrictions on where a binary can be put?
On 01/20/2011 07:01 PM, Alexander Neundorf wrote:
On Sunday 09 January 2011, Michael Hertling wrote:
On 01/09/2011 09:47 PM, Nizar Khalifa Sallem wrote:
At Sun, 09 Jan 2011 21:42:49 +0100,
Michael Hertling wrote:
On 01/09/2011 09:09 PM, Andreas Pakulat wrote:
On 09.01.11 21:05:21, Andreas Pakulat wrote:
On 09.01.11 14:24:16, Michael Hertling wrote:
On 01/09/2011 12:58 PM, Andreas Pakulat wrote:
Hi,
I'm having a bit of a problem here changing the runtime output
directory for a binary. Its an executable target named 'setup' and
I'd like to put it into the top-level directory. Unfortunately it
always ends up in the bin/ directory, which is what
CMAKE_RUNTIME_OUTPUT_DIRECTORY is being set to.
I'm using
set_target_properties( setup PROPERTIES RUNTIME_OUTPUT_DIRECTORY
${CMAKE_BINARY_DIR} ) after creating the target currently, which
should work as far as I can see from the documentation. Are there
maybe any restrictions on what the directory may be or what targets
can be put there?
If not, any suggestions how to debug this? I can see that the
build.make does already have the rule setup for putting the binary
into bin/, so it must be going wrong somewhere in the generation
stage, but a simple cmake --trace doesn't show up anything
suspicious. Is there a switch to follow the steps that cmake does
during makefile-generation?
Could you provide a minimal but complete example?
Ok, attached case produces the error. Apparently the problem is
fetching the LOCATION property from the target and setting the
RUNTIME_OUTPUT_DIRECTORY afterwards. Looks like a cmake bug to me, so
I'll file a report.
Ooops, forgot the attachment :)
Now, I can confirm the issue; indeed, the GET_TARGET_PROPERTY() on the
LOCATION apparently renders the following SET_TARGET_PROPERTY() on the
RUNTIME_OUTPUT_DIRECTORY ineffective. As I cannot see any reason for
this, I'd agree that it should be considered as a bug. Besides, my
example was pointless: A simple clash of an executable main with
a subdirectory of the same name in CMAKE_BINARY_DIR, sorry. :/
Regards,
Michael
I don't really understand why you want to get the LOCATION from your
target, anyway, the get_target_property works fine if you use
set_target_properties before it. [...]
...but SET_TARGET_PROPERTIES() doesn't work fine if it's used after
GET_TARGET_PROPERTY(), even if both operate on different properties.
Well, they are not completely different.
If I remember correctly, the LOCATION property is calculcated when you
query
it. I think it changes some internal variables. Apparently to a state where
setting the target property afterwards doesn't have the desired effect
anymore :-/
So, what's your conclusion in this matter? Should the behavior in
question be considered as a bug or is it alright? IMO, such a subtle
side effect of a read operation on a subsequent write operation is at
least highly surprising. Besides, does one have to take this phenomenon
into account elsewhere, i.e. when saying
GET_TARGET_PROPERTY(VAR TARGET X)
...
SET_TARGET_PROPERTIES(TARGET PROPERTIES Y ...)
with X!=LOCATION and Y!=RUNTIME_OUTPUT_DIRECTORY, is it assured that
the latter command works as expected? Are directory or source files
properties possibly affected, too?
Regards,
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] Does PATH_SUFFIXES work?
On 01/19/2011 06:00 AM, Jack Poulson wrote:
I've thoroughly read through the CMake documentation for the 2.8 release and
for the life of me I can't seem to get a simple case working for
find_library using PATH_SUFFIXES.
For instance, I am trying to find the library libiomp5.a located at
/opt/intel/Compiler/11.1/072/lib/intel64/libiomp5.a. Though the following
command works (in CMake 2.8.2):
find_library(IOMP5_LIB iomp5 PATH /opt/intel/Compiler/11.1/072/lib/intel64)
the following does _not_ work,
set(INTEL_ARCH_SUBDIRS lib/em64t lib/intel64)
find_library(IOMP5_LIB iomp5 PATH /opt/intel/Compiler/11.1/072/lib/intel64
PATH_SUFFIXES ${INTEL_ARCH_SUBDIRS})
find_library(IOMP5_LIB iomp5 PATHS /opt/intel/...
^
and neither does
set(INTEL_ARCH_SUBDIRS lib/em64t lib/intel64)
find_library(IOMP5_LIB iomp5 PATH /opt/intel/Compiler/11.1/072 PATH_SUFFIXES
${INTEL_ARCH_SUBDIRS})
find_library(IOMP5_LIB iomp5 PATHS /opt/intel/...
^
Am I missing something about how PATH_SUFFIXES should be used, or is it
broken? Any feedback is greatly appreciated.
The correct option to specify hard-coded search paths for the find
functions is PATHS. Apparently, FIND_LIBRARY() is tangled if you
say PATH instead, so the following PATH_SUFFIXES doesn't work as
expected.
Regards,
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] text file modifications while Install
On 01/17/2011 02:53 PM, Ilja Golshtein wrote:
Hello, list,
please, suggest proper way to do some text file modifications while Install.
Basically I need something similar with RPATH change Cmake does,
but against a configuration file.
Currently I create amended version of the config make-time and
use it install-time. It does not look like an elegant solution.
Ideas how to do it better?
You might use INSTALL(CODE ...) or INSTALL(SCRIPT ...) to perform last-
minute modifications at installation time, but I'm not sure if one can
reliably force these commands to be run before INSTALL(FILES ...) Co.
Alternatively, you could provide your own installation target, e.g.:
ADD_CUSTOM_TARGET(myinstall
COMMAND modify-config-files
COMMAND ${CMAKE_COMMAND} -P cmake_install.cmake
)
or
ADD_CUSTOM_TARGET(myinstall
COMMAND modify-config-files
COMMAND ${CMAKE_COMMAND}
--build ${CMAKE_BINARY_DIR} --target install
)
However, a dependency of the built-in install target on a custom
preinstall target doing the desired modifications would be a really
clean solution, IMO - provided you don't want to heed Michael's advice.
So, you should perhaps consider to vote for 8438 when the question for
the most welcome bug fixes and features for CMake 2.8.5 will be raised.
Regards,
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] retrieve the path of an object file
On 01/14/2011 12:17 PM, Andrea Galeazzi wrote: Given a source file (path/foo.c), does CMake provide a way to retrieve the obj file path/filename generate by the compiler? With the Makefile generators, you might use the RULE_LAUNCH properties to intercept the compiling/linking phase, including to influence where the object files are written to and read from, but this is of limited portability, error-prone and should be considered only in very special cases, see [1]. Alternatively, you could try to rewrite variables like CMAKE_LANG_COMPILE_OBJECT and friends to achieve your goal, but the same objections apply here, too, cf. [2]. Regards, Michael [1] http://www.mail-archive.com/cmake@cmake.org/msg29622.html [2] http://www.mail-archive.com/cmake@cmake.org/msg31533.html ___ 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] problem getting defines quoted properly
On 01/14/2011 08:25 PM, Andreas Pakulat wrote: Hi, I'm trying to set a define so that it can be used as string-literal in C++ code using add_definitions. This: add_definition( -DMYFOO=\BAR BAZ\ ) works fine on linux, but breaks with MSVC6 on windows. I always thought I understood cmake's quoting rules, but apparently I'm wrong :( I've already tried: add_definition( -DMYFOO=\\\BAR BAZ\\\ ) What I didn't think of trying when I was at the machine is add_definition( -DMYFOO=\\BAR BAZ\\ ) Would that be the correct one? Or do I need even more \? No, you probably need a configured header. ;) The documentation of ADD_DEFINITIONS() states Flags beginning in -D or /D that look like preprocessor definitions are automatically added to the COMPILE_DEFINITIONS property for the current directory. and from the COMPILE_DEFINITIONS directory property's documentation: The VS6 IDE does not support definition values with spaces... ^^^ So, I think your issue is not caused by CMake. Regards, 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] conditional selection of either local just built or system versions of a library
On 01/11/2011 05:46 PM, Marco wrote:
Dear CMake experts,
I'm facing the following problem. I have a project with many
subdirectories, all at the same hierarchical level:
/my/project/path/CMakeLists.txt
/my/project/path/A - include
|- src
|- CMakeLists.txt
/my/project/path/B - include
|- src
|- CMakeLists.txt
Each subdir corresponds to a package that a user is allowed to modify
and build against a given general release already installed centrally
or against other locally built packages.
Some of the executables of package A must be linked against an object
file generated by package B. The user could build package B, so that the
object file needed by executables in package A is the local one, but
could also decide to rely on the one that comes from the already
installed release.
To give an example:
- package A has something like:
add_executable(X src/X.cc)
target_link_libraries(X ${RIGHTPATH}/ObjFile.o A B C)
add_dependencies(X obj_file_target)
- package B has something like:
add_custom_command(
OUTPUT ${LIBRARY_OUTPUT_PATH}/ObjFile.o
COMMAND ${CMAKE_CXX_COMPILER} -Wall
-I${PROJECT_SOURCE_DIR}/include -c
${CMAKE_CURRENT_SOURCE_DIR}/src/ObjFile.cc -o
${LIBRARY_OUTPUT_PATH}/ObjFile.o)
add_custom_target(obj_file_target DEPENDS ${LIBRARY_OUTPUT_PATH}/ObjFile.o)
In this way executable X triggers the compilation of ObjFile.o which is
put into ${LIBRARY_OUTPUT_PATH}.
The point is that if the user wants to use the system ObjFile.o located
in, say, /Soft/Releases/V1/lib/ObjFile.o I don't have a way to determine
for package A the value of RIGHTPATH (either ${LIBRARY_OUTPUT_PATH} or
/Soft/Releases/V1/lib/) as the path variable is set when I enter package
A which can happen before I enter package B.
How could I solve this issue? Is there a way to conditionally select
which library my exe will be linked against?
You might use a user-supplied path to the external B as indicator:
SET(LIBRARY_OUTPUT_PATH ...) # Must be known at this place.
SET(RIGHTPATH ${LIBRARY_OUTPUT_PATH}) # Assume internal B.
SET(PATH_TO_B CACHE PATH Path to external B)
IF(PATH_TO_B)
SET(RIGHTPATH ${PATH_TO_B}) # Use external B.
ENDIF()
ADD_SUBDIRECTORY(A)
IF(NOT PATH_TO_B)
ADD_SUBDIRECTORY(B)
ENDIF()
So, the user can set PATH_TO_B on the command line or in the GUI to
demand the usage of the external B; if PATH_TO_B is left alone, the
internal B is used. Here, it is crucial that LIBRARY_OUTPUT_PATH is
set in the CMakeLists.txt above B. Because ADD_DEPENDENCIES() isn't
insulted if a prerequisite target doesn't exists, it can remain in
A/CMakeLists.txt without guard regardless whether B/CMakeLists.txt
is processed or not.
Regards,
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] CMake Error: Error required internal CMake variable not set, ...
On 01/12/2011 04:29 PM, Enrique Izaguirre wrote: Hello, I am new to CMake and following a few examples, I am now trying to cross-compile a C++ program from Cygwin to Linux, and I got the following errors: CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_C++_COMPILER_ENV_VAR CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_C++_COMPILER : I have a folder named helloC++-linux, where I have all my stuff: A simple hello.cpp program My CMakeLists.txt contains: #CMakeLists.txt : CMake configuration file PROJECT(helloC++-linux C++) Try with PROJECT(helloC++-linux CXX), i.e. CXX instead of C++. ^^ #States that CMake required version must be = 2.6 CMAKE_MINIMUM_REQUIRED(VERSION 2.6) #File to build and executable: ADD_EXECUTABLE(hello.o hello.cpp) My Toolchain file (named Toolchain-linuxcpp.cmake) contains: INCLUDE (CMakeForceCompiler) SET(CMAKE_SYSTEM_NAME Linux) #specify the cross-compiler SET(CMAKE_CXX_COMPILER /bin/g++-linux) and I tried to build it using following command: cmake -DCMAKE_TOOLACHAIN_FILE=./Toolchain-linuxcpp.cmake . Before this, I tried it compiling a simple C program, using gcc-linux compiler and setting CMAKE_C_COMPILER variable, and it worked correctly, but once that I am trying to do it with C++ I got these errors. I couldn't find anything about this on the web. Could you help me please? Thanks Enrique ___ 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] CPack and configure_file
On 01/11/2011 09:48 AM, Eric Noulard wrote:
2011/1/11 Michael Hertling mhertl...@online.de:
On 01/11/2011 12:55 AM, Tobias Ellinghaus wrote:
Because some information (like latest git commit as version string) is no
longer available when using a source package. Of course I can put the
generated files into the source tree, but that's kind of against the idea of
out-of-source builds.
You might use cmake --build in conjunction with a custom target:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(PKGSRC NONE)
IF(EXISTS ${CMAKE_SOURCE_DIR}/manifest.txt)
# In packaged source tree.
FILE(COPY ${CMAKE_SOURCE_DIR}/manifest.txt
DESTINATION ${CMAKE_BINARY_DIR})
ELSE()
# In original source tree.
FILE(WRITE ${CMAKE_BINARY_DIR}/manifest.txt ...\n)
INCLUDE(CPack)
ADD_CUSTOM_TARGET(pkgsrc
COMMAND ${CMAKE_COMMAND}
-E copy ${CMAKE_BINARY_DIR}/manifest.txt
${CMAKE_SOURCE_DIR}/manifest.txt
COMMAND ${CMAKE_COMMAND}
--build ${CMAKE_BINARY_DIR}
--target package_source
COMMAND ${CMAKE_COMMAND}
-E remove ${CMAKE_SOURCE_DIR}/manifest.txt
)
ENDIF()
Nice solution.
The pkgsrc target prepares the source tree for packaging, builds the
source package via cmake --build and cleans up. AFAICS, writing to
the source tree is unavoidable in order to achieve your aim,
in fact I think the real source for this is the fact the CPack lacks
the notion
of EXTRA distribution file which is available with autoconf, EXTRA_DIST var
http://www.gnu.org/software/hello/manual/automake/Basics-of-Distribution.html
or the dist-hook:
http://www.gnu.org/software/hello/manual/automake/The-dist-Hook.html#The-dist-Hook
The fact is CPack doesn't know much about source package and
in fact it package source using the CPACK_INSTALLED_DIRECTORIES directory
list.
(look at the generated CPackSourceConfig.cmake)
I think you can emulate the extra thing of autoconf.
If you want ot package more than the source tree with
package_source you can try
the following in your main CMakeLists.txt (before include(CPack))
SET(CPACK_SOURCE_INSTALLED_DIRECTORIES
${CMAKE_SOURCE_DIR};/;${CMAKE_BINARY_DIR}/extra;/extra)
then the content of the directory
${CMAKE_BINARY_DIR}/extra will added in the package source archive
inside extra dir.
it should work.
Indeed, it does; thanks for this hint, Eric. :)
Just two remarks about that solution from my side:
1) Is it an official feature? The CPACK_SOURCE_INSTALLED_DIRECTORIES
variable is not documented anywhere and does hardly appear on the
ML or the BT, and even G**gle says that it is used rather seldom.
2) In contrast to the usual package target, there is no dependency
of package_source on all, so one will possibly miss something
if the source package ingredients need to be set up at build time.
AFAICS, the latter can be addressed with CPACK_INSTALL_COMMANDS set to
${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR} or whatever is necessary
to prepare the source tree for packaging, but there's no source-package
specific CPACK_SOURCE_INSTALL_COMMANDS variable or the like. Perhaps,
this is worth a feature request as concerns like the OP's one, i.e.
the addition of certain build-time generated files to the source
package, are somewhat reasonable, IMO.
Regards,
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] add_subdirectory and link_directories
On 01/10/2011 06:24 PM, Andrea Galeazzi wrote:
I've got a main project which relies on several sub-library projects, so
the main CMakeLists.txt
add_subdirectory(W:/Omega/Kernel ${CMAKE_CURRENT_BINARY_DIR}/myLib1)
...
and then I also specify the directory where all libraries have been
built (by setting ARCHIVE_OUTPUT_DIRECTORY for each library)
link_directories(${ROOT_LIB}/{CMAKE_SYSTEM_NAME}/${CMAKE_BUILD_TYPE})
Anyway I noticed that the build process works fine also without
declaring the row above.
My question: is specifying link_directories useless when I use
add_subdirectory in order to build a library? If yes, is that true
regardless the target (I only tested it in VS2010 and MinGW)?
Since CMake prefers to specify libraries by path instead of using -l/-L
or the like, there's usually no need for the LINK_DIRECTORIES() command,
IMO. For the project's targets, CMake tracks their paths by itself and
takes OUTPUT_DIRECTORY properties and explicit binary directories into
account; the find modules and configuration files of external packages
also use full paths for their libraries, either immediately or via the
IMPORTED_LOCATION properties of imported targets, so you should rarely
have to use the LINK_DIRECTORIES() command, at least for new CMakified
projects. Moreover, it might involve the danger of luring the linker
into the wrong directories, see [1], and makes it harder to choose a
static library instead of a shared one, see [2]. Thus, I'd recommend
against using LINK_DIRECTORIES() unless there's a good reason for it.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg33519.html
[2] http://www.cmake.org/Wiki/CMake_2.6_Notes#Link_Line_Generation
___
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] Restrictions on where a binary can be put?
On 01/09/2011 12:58 PM, Andreas Pakulat wrote:
Hi,
I'm having a bit of a problem here changing the runtime output directory
for a binary. Its an executable target named 'setup' and I'd like to put it
into the top-level directory. Unfortunately it always ends up in the bin/
directory, which is what CMAKE_RUNTIME_OUTPUT_DIRECTORY is being set to.
I'm using
set_target_properties( setup PROPERTIES RUNTIME_OUTPUT_DIRECTORY
${CMAKE_BINARY_DIR} )
after creating the target currently, which should work as far as I can see
from the documentation. Are there maybe any restrictions on what the
directory may be or what targets can be put there?
If not, any suggestions how to debug this? I can see that the build.make
does already have the rule setup for putting the binary into bin/, so it
must be going wrong somewhere in the generation stage, but a simple cmake
--trace doesn't show up anything suspicious. Is there a switch to follow
the steps that cmake does during makefile-generation?
Could you provide a minimal but complete example? Currently, I can't
confirm this issue, i.e. the RUNTIME_OUTPUT_DIRECTORY property seems
to take precedence over the CMAKE_RUNTIME_OUTPUT_DIRECTORY variable.
Nevertheless, if RUNTIME_OUTPUT_DIRECTORY is set to CMAKE_BINARY_DIR
from within a subdirectory, i.e. CMAKE_CURRENT_BINARY_DIR isn't equal
to CMAKE_BINARY_DIR, I can see quite strange things happening:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(ROD C)
ADD_SUBDIRECTORY(main)
# main/CMakeLists.txt:
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/main.c
int main(void){return 0;}\n
)
ADD_EXECUTABLE(main ${CMAKE_CURRENT_BINARY_DIR}/main.c)
SET_TARGET_PROPERTIES(main PROPERTIES
RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}
)
After CMaking from within an empty directory, building fails with:
.../gcc CMakeFiles/main.dir/main.c.o -o . -rdynamic
.../ld: cannot open output file .: Is a directory
If the RUNTIME_OUTPUT_DIRECTORY property is set to CMAKE_BINARY_DIR/bin,
e.g., everything works as expected, i.e. the executable gets written to
CMAKE_BINARY_DIR/bin. Also, no such problem occurs from within the top-
level directory, i.e. CMAKE_CURRENT_BINARY_DIR == CMAKE_BINARY_DIR.
Perhaps, these two phenomena are related?
Regards,
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] Restrictions on where a binary can be put?
On 01/09/2011 09:32 PM, Nizar Khalifa Sallem wrote:
At Sun, 9 Jan 2011 21:09:37 +0100,
Andreas Pakulat wrote:
[1 text/plain; us-ascii (7bit)]
On 09.01.11 21:05:21, Andreas Pakulat wrote:
On 09.01.11 14:24:16, Michael Hertling wrote:
On 01/09/2011 12:58 PM, Andreas Pakulat wrote:
Hi,
I'm having a bit of a problem here changing the runtime output directory
for a binary. Its an executable target named 'setup' and I'd like to put
it
into the top-level directory. Unfortunately it always ends up in the bin/
directory, which is what CMAKE_RUNTIME_OUTPUT_DIRECTORY is being set to.
I'm using
set_target_properties( setup PROPERTIES RUNTIME_OUTPUT_DIRECTORY
${CMAKE_BINARY_DIR} )
after creating the target currently, which should work as far as I can see
from the documentation. Are there maybe any restrictions on what the
directory may be or what targets can be put there?
If not, any suggestions how to debug this? I can see that the build.make
does already have the rule setup for putting the binary into bin/, so it
must be going wrong somewhere in the generation stage, but a simple cmake
--trace doesn't show up anything suspicious. Is there a switch to follow
the steps that cmake does during makefile-generation?
Could you provide a minimal but complete example?
Ok, attached case produces the error. Apparently the problem is fetching
the LOCATION property from the target and setting the
RUNTIME_OUTPUT_DIRECTORY afterwards. Looks like a cmake bug to me, so
I'll file a report.
Ooops, forgot the attachment :)
Andreas
--
You should emulate your heros, but don't carry it too far. Especially
if they are dead.
[2 test_output_dir.tar.gz application/octet-stream (base64)]
[3 text/plain; us-ascii (7bit)]
___
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,
You I tested your CMakeLists.txt and this is no way a cmake bug but if
you sent a wrong CMakeLists.txt file.
just remove this line get_target_property( _var foo LOCATION ) since
your target name is also foo.
Tested without it and it works like a charm:
What's wrong with Andreas' CMakeLists.txt? He uses GET_TARGET_PROPERTY()
correctly - of course, on a target foo. The point is why *reading* a
target property has an influence on subsequently *setting* a different
target property.
Regards,
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] Restrictions on where a binary can be put?
On 01/09/2011 09:47 PM, Nizar Khalifa Sallem wrote:
At Sun, 09 Jan 2011 21:42:49 +0100,
Michael Hertling wrote:
On 01/09/2011 09:09 PM, Andreas Pakulat wrote:
On 09.01.11 21:05:21, Andreas Pakulat wrote:
On 09.01.11 14:24:16, Michael Hertling wrote:
On 01/09/2011 12:58 PM, Andreas Pakulat wrote:
Hi,
I'm having a bit of a problem here changing the runtime output directory
for a binary. Its an executable target named 'setup' and I'd like to put
it
into the top-level directory. Unfortunately it always ends up in the bin/
directory, which is what CMAKE_RUNTIME_OUTPUT_DIRECTORY is being set to.
I'm using
set_target_properties( setup PROPERTIES RUNTIME_OUTPUT_DIRECTORY
${CMAKE_BINARY_DIR} )
after creating the target currently, which should work as far as I can
see
from the documentation. Are there maybe any restrictions on what the
directory may be or what targets can be put there?
If not, any suggestions how to debug this? I can see that the build.make
does already have the rule setup for putting the binary into bin/, so it
must be going wrong somewhere in the generation stage, but a simple cmake
--trace doesn't show up anything suspicious. Is there a switch to follow
the steps that cmake does during makefile-generation?
Could you provide a minimal but complete example?
Ok, attached case produces the error. Apparently the problem is fetching
the LOCATION property from the target and setting the
RUNTIME_OUTPUT_DIRECTORY afterwards. Looks like a cmake bug to me, so
I'll file a report.
Ooops, forgot the attachment :)
Now, I can confirm the issue; indeed, the GET_TARGET_PROPERTY() on the
LOCATION apparently renders the following SET_TARGET_PROPERTY() on the
RUNTIME_OUTPUT_DIRECTORY ineffective. As I cannot see any reason for
this, I'd agree that it should be considered as a bug. Besides, my
example was pointless: A simple clash of an executable main with
a subdirectory of the same name in CMAKE_BINARY_DIR, sorry. :/
Regards,
Michael
I don't really understand why you want to get the LOCATION from your
target, anyway, the get_target_property works fine if you use
set_target_properties before it. [...]
...but SET_TARGET_PROPERTIES() doesn't work fine if it's used after
GET_TARGET_PROPERTY(), even if both operate on different properties.
[...] I am not sure that the
CMAKE_RUNTIME_OUTPUT_DIRECTORY makes a property which is
gettable. [...]
Why should any property be not gettable? Some are not settable, like
the LOCATION, but that's not the point. The point is that getting a
property, i.e. a read operation, should not have an impact on any
subsequent command which does not use the former's results.
[...] If you can better explain what do you want to do with the
LOCATION of your target may be someone can help.
Regards,
Michael
@ Martin O'Brien: On my side, everything works as usual.
___
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] Installing Python Modules with CMake
On 01/04/2011 08:50 AM, Michael Wild wrote:
On 01/03/2011 06:23 PM, Todd Gamblin wrote:
On Jan 3, 2011, at 1:34 AM, Michael Wild wrote:
On 01/03/2011 09:11 AM, Todd Gamblin wrote:
Is there some standard way in CMake to get a project-local install
destination for python libraries, e.g.:
${CMAKE_INSTALL_PREFIX}/lib/python2.6/site-packages
Is this something find modules typically provide? I can construct this
name easily enough myself, but it involves querying the python executable
for its version then regexing that string, and I feel like FindPythonLibs
should do stuff like that for me. It would be nice to have something
called, say, CMAKE_PYTHON_INSTALL_PREFIX set to this path in advance, so
that I can just install python modules there.
Or am I missing something? I couldn't fund much on installing python
files in the docs.
-Todd
I think you'll have to query Python yourself. Of course, this becomes
difficult if you're cross-compiling, in which case you would need to
parse the prefix/lib/pythonX.Y/config/Makefile file yourself and fetch
all the relevant variables (datarootdir, BINDIR, DESTSHARED, LIBDEST,
etc.) and then ask the user what prefix and exec_prefix he wants
(presumably CMAKE_INSTALL_PREFIX maps to prefix, and usually exec_prefix
is the same as prefix, but that's not always the case). Not sure how
that works on Windows, though...
That's kind of difficult because if I have just 'python', I don't have the
version yet, so how am I supposed to find the Makefile?
Off the top of my head, the most portable way to do this would be to find
the python-config (which you can get by appending -config to the exe path,
even if it's just python and not pythonX.Y) and then:
head -1 `which ${PYTHON_CONFIG}` | sed 's/.*\([0-9].[0-9]\)$/\1/'
Or the equivalent in CMake using string(REGEXP ...).
That will get you the version without running anything, and then you can go
and find the Makefile.
That only works on *NIX, on Windows there's AFAIK no python-config. So
if you plan to cross-compile for Windows you might run into trouble.
Probably it's best to not try being über-smart, and just leave it to the
user to provide the information.
In the non cross-compiled case, though, it would be nice to just have a
module that gives you all the information from python-config.
Better run
${PYTHON_EXECUTABLE} -c import sys; sys.stdout.write(sys.prefix+'\n')
and similar, which also works on WIN32.
-Todd
I wouldn't rely too much on FindPythonLibs. The whole FindPython* is a
sorry mess (IMHO) and needs some serious overhaul, but that is some
major undertaking an apparently the suffering wasn't big enough so far
for somebody to take action...
I noticed you guys had a long discussion about finding Python 3. Did you
come to any conclusions on this? It would be nice to have a python
detection Find module that works if you *just* give it your python
executable. I don't mind writing something like this up if no one else is
up for it, but if I'm going to write it I'd like to make something that
people will use.
Thoughts?
AFAIK, the issue hasn't been resolved. One of the big problems IMHO is,
that FindPythonInterp and FindPythonLibs can report different python
installations. Also, what should happen if the user manually changes the
cache entry for the interpreter, but doesn't update the libraries? Also,
some users of the module will just want the most recent version of
Python, while others will specifically want the most recent 2.x version
because their code isn't ready for python3. If
you can come up with something that works well on all important
platforms and is reasonably backwards compatible, you probably would
make a lot of people happy ;-)
Michael
On Todd's request for commentary. Please note that the following
remarks are merely my personal opinion; of course, one can take
different positions:
A major obstacle for the development of smart/robust/comprehensive
find modules is the current incapability of the four find functions
FIND_{PATH,FILE,PROGRAM,LIBRARY}() to process filename patterns, e.g.
FIND_PROGRAM(PYTHON_EXECUTABLE PATTERN python*.* ...) or regex'd with
FIND_PROGRAM(PYTHON_EXECUTABLE PATTERN python[0-9]+\.[0-9]+ ...). All
these functions are able to look in any corner of the system, but they
search for fixed filenames only, especially resulting in problems like
the one reported with versioned Python directories. Furthermore, this
limitation constrains the authors of several find modules to hard-code
versions, e.g. Find{Python{Interp,Libs},TCL,PNG,Boost}.cmake, bearing
the need for continuous maintenance on the developers' as well as the
users' side. Additionally, issues like 10718 occasionally prevents the
right version from being found. During the last few months, we've seen
all of the above-mentioned find modules on the mailing list because of
difficulties related to the hardcoded version
Re: [CMake] How to find the path to the currently include() or find_package file()
On 01/04/2011 05:47 AM, John McGehee wrote:
I am using CMake 2.8 on Linux and Windows.
When I include() or find_package() a .cmake file, is there a variable that I
can use within the included .cmake file that will tell me its path?
For example,
# In CMakeLists.txt
include(somePath/foo.cmake)
Within somePath/foo.cmake, I want to include bar.cmake which is in the same
directory as foo.cmake,
# In somePath/foo.cmake
include(${CMAKE_VARIABLE_THAT_IS_THE_ANSWER_TO_THIS_QUESTION}/bar.cmake)
where ${CMAKE_VARIABLE_THAT_IS_THE_ANSWER_TO_THIS_QUESTION} = somePath, the
path to foo.cmake, which is currently being evaluated.
Use CMAKE_CURRENT_LIST_FILE in conjunction with GET_FILENAME_COMPONENT():
# In somePath/foo.cmake
get_filename_component(somePath ${CMAKE_CURRENT_LIST_FILE} PATH)
include(${somePath}/bar.cmake)
Regards,
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 find the path to the currently include() or find_package file()
On 01/04/2011 07:41 AM, Michael Hertling wrote:
On 01/04/2011 05:47 AM, John McGehee wrote:
I am using CMake 2.8 on Linux and Windows.
When I include() or find_package() a .cmake file, is there a variable that I
can use within the included .cmake file that will tell me its path?
For example,
# In CMakeLists.txt
include(somePath/foo.cmake)
Within somePath/foo.cmake, I want to include bar.cmake which is in the same
directory as foo.cmake,
# In somePath/foo.cmake
include(${CMAKE_VARIABLE_THAT_IS_THE_ANSWER_TO_THIS_QUESTION}/bar.cmake)
where ${CMAKE_VARIABLE_THAT_IS_THE_ANSWER_TO_THIS_QUESTION} = somePath,
the path to foo.cmake, which is currently being evaluated.
Use CMAKE_CURRENT_LIST_FILE in conjunction with GET_FILENAME_COMPONENT():
Oops...or just CMAKE_CURRENT_LIST_DIR. ;|
Regards,
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] CMAKE uses wrong symlink to so
On 12/31/2010 03:43 PM, Michael Wild wrote:
On 12/31/2010 02:48 PM, Michael Hertling wrote:
On 12/31/2010 11:56 AM, Michael Wild wrote:
On 12/30/2010 07:55 PM, j s wrote:
Hello Michael Wild,
I regret deciding to go with an Python parser for my application. I use
such a small subset of the API, I was hoping to be able to rerelease my app
everytime it changes.
Apparently Python 2.6 is frozen.
In the future, the Python people are hoping to stabilize the ABI in the 3
series so that I can just link against a libpython3.so:
http://www.python.org/dev/peps/pep-0384/
As stated by Michael Hertling, the symlinks are not being recursively
resolved. The soname is encoded into the so, so the linker chooses to
ignore the original filename.
Regards,
Juan
On Thu, Dec 30, 2010 at 6:23 AM, Michael Wild them...@gmail.com wrote:
On 12/30/2010 12:28 AM, j s wrote:
I specified the full name to an so in CMAKE 2.8.1. Unfortunately it
links
against the versioned so name,
libpython2.6.so.1.0
instead of the exact name I specified.
/usr/lib/libpython2.6.so
SET (PYTHON_ARCHIVE /usr/lib/libpython2.6.so)
TARGET_LINK_LIBRARIES (myapp parser engine ${PYTHON_ARCHIVE}
${OPENSSL_ARCHIVE})
Is there any way to tell cmake to do the right thing in Linux? For some
strange reason using -l on the link line, and doesn't even use the
corresponding -L to the path I specify.
-lpython2.6
Regards,
Juan
There's nothing CMake can do about this, this is the linker getting in
your way. E.g. on my Ubuntu, /usr/lib/libpython2.6.so is a symlink to
/usr/lib/libpython2.6.so.1 which itself is a symlink to
/usr/lib/libpython2.6.so.1.0. The linker recursively resolves all
symlinks during the linking, and CMake can't do anything about it. You
could pass the full path to the /usr/lib/libpython2.6.so symlink instead
of -lpython2.6 and you would still get the same result.
Actually, this is considered to be a feature. This way, newly compiled
programs will always link against the current version (the one pointed
to by the symlink-chain), while old programs can still use older
versions of the library without requiring to be recompiled.
Michael
Huh?
$ echo int main(){} | gcc -x c -c -o test.o -
$ gcc test.o /usr/lib/libpython2.6.so
$ ldd a.out | grep libpython2.6
libpython2.6.so.1.0 = /usr/lib/libpython2.6.so.1.0 (0x7fbb350f1000)
$ ls -l /usr/lib/libpython2.6.so*
... /usr/lib/libpython2.6.so - libpython2.6.so.1
... /usr/lib/libpython2.6.so.1 - libpython2.6.so.1.0
... /usr/lib/libpython2.6.so.1.0
Sure looks like recursive symlink resolution to me...
No, it's the soname that gets incorporated in the resulting binary;
recursively resolving the symlinks is insignificant in this regard:
echo void f(void){} f.c
echo void g(void){} g.c
gcc -o libf.so -shared -fPIC -Wl,-soname,xyz f.c
gcc -o libg.so.1.0 -shared -fPIC g.c
ln -sf libg.so.1.0 libg.so.1
ln -sf libg.so.1 libg.so
ls -l libg.so*
... libg.so - libg.so.1
... libg.so.1 - libg.so.1.0
... libg.so.1.0
echo int main(void){return 0;} main.c
gcc -o main main.c libf.so libg.so
LD_LIBRARY_PATH=. ldd main
...
xyz = not found
libg.so = ./libg.so (0xb7fbd000)
...
A recursive symlink resolution would make the main executable being
linked against libg.so.1.0 instead of libg.so. In fact, main is linked
against the library specified by the soname - if present - even if that
library doesn't exist at all like xyz in the example above. If there is
no soname the linker incorporates the library as denoted on the command
line. With libpython2.6, the executable is linked against .so.1.0 since
this is the library's soname, but not due to the .so--so.1--.so.1.0
symlink resolution. BTW, the soname denoting the non-existing xyz is
completely artificial, of course, and designed only to clarify the
concern. Usually, ldconfig ensures that there is a valid symlink
soname -- actual library file.
Regards,
Michael
Ahh, yes, I see. Learned something new ;-) But still, not exactly a
CMake-issue, [...]
It's usual *nix/ELF business.
[...] although replacing full paths with -l flags might cause
wrong libraries from being picked up if a -L flag happens to be
specified before the library, right?
Even if -L appears after the library it remains a pitfall as all -L
options apply to all -l ones, regardless of their order. So, IMO, the
rule of thumb should be: Always use full paths for libraries but never
use -L, neither explicitly in TARGET_LINK_LIBRARIES(), LINK_FLAGS etc.
nor indirectly via LINK_DIRECTORIES(), and if there's any trouble with
CMake's decision to use -l because the library resides in a well known
system directory, use the imported-target approach to enforce a full
path in that case, too.
Regards and Happy New Year,
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Re: [CMake] How to make a ProjectConfig.cmake
On 12/30/2010 06:59 PM, Ian Monroe wrote: On Thu, Dec 30, 2010 at 09:42, Michael Wild them...@gmail.com wrote: On 12/30/2010 03:34 PM, Ian Monroe wrote: On Thu, Dec 30, 2010 at 08:08, Michael Hertling mhertl...@online.de wrote: On 12/30/2010 11:33 AM, Ian Monroe wrote: To create my QyotoConfig.cmake I need to know the full path of a library so that I can set a variable like QYOTO_LIBRARY. This is pretty standard requirement right? Its what we're supposed to do in *Config.cmake's? Yes. So anyways, how do I that? The only target property that hasn't returned NOTFOUND is LOCATION, which unhelpfully returns the location of the library in the build directory. I could parse this to get the file name, and then append it to the library install location... but that seems like such a hack. Feels like I'm doing something wrong if I need to use a hack to do something standard. Usually, I'd have a template QyotoConfig.cmake.in which contains FIND_LIBRARY(QYOTO_LIBRARY qyoto PATHS @CMAKE_INSTALL_PREFIX@/lib NO_DEFAULT_PATH ) and is processed by CONFIGURE_FILE(). If the library is installed with INSTALL(TARGETS qyoto RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib ) the FIND_LIBRARY() in the resulting QyotoConfig.cmake file will find the library right at the installation location but nowhere else, and the platform-dependent file names, e.g. libqyoto.so versus qyoto.dll, are also handled correctly. I looked at install(EXPORT which could work, but it seems to include a lot more information then is needed. I just want to set a variable with the full path to a library. Nevertheless, the imported-targets approach, i.e. the combination of INSTALL(TARGETS ... EXPORT ...) and INSTALL(EXPORT ...) along with an appropriately set up config file, is much more powerful and should be preferred, IMO; see [1] for more information. BTW, as the export file defines the imported targets, its inclusion in the config file should possibly be protected in a suitable way to avoid fatal redefinitions. The context I'm coming from is that I'm developing stuff that is distributed by Linux distributions. The export file has information about what the target is dependent on, including full paths. That feels like a bad thing to me. What was true about dependencies when a package was being built on a build server might not be true later. If the paths on the build server don't match the ones on the destination system, then that distro is broken. Period. Here's what happens in the case of Debian/Ubuntu/...: - A minimal installation is unpacked from a tar-ball - The system chroots into the unpacked system - All dependencies are installed into the build environment - The package is built - The system exits the chroot, retrieves the package and discards the build environment This is to guarantee that the dependencies are set up correctly and that no strange interferences occur. Yes, I know how build systems work. But if some library that I depends on changes where it is installed, that very well might not matter at all to running my application. And mostly certainly not to building it. ...yet the EXPORT-created cmake would still refer to this old file. Maybe it doesn't really matter, just seems like bad practice to be referring to files that aren't yours in these cmake files that get installed. This issue isn't limited to configuration files with imported targets or their usage in a Linux distribution. Even with the, say, classical approach, you have hardcoded paths of library/executable files or the like in the config file, so the latter is valid for the system's state at the very moment of the installation. When a package's prerequisites are changed later the config file is in danger to be broken. That's a fundamental difference to find modules which can search prerequisites dynamically and return with PACKAGE_FOUND==FALSE as the case may be. Anyway, I think we have to put up with this possible raw point, but a well administrated system - or a well organized distribution - should keep the risks small. Regards, 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] CMAKE uses wrong symlink to so
On 12/31/2010 11:56 AM, Michael Wild wrote:
On 12/30/2010 07:55 PM, j s wrote:
Hello Michael Wild,
I regret deciding to go with an Python parser for my application. I use
such a small subset of the API, I was hoping to be able to rerelease my app
everytime it changes.
Apparently Python 2.6 is frozen.
In the future, the Python people are hoping to stabilize the ABI in the 3
series so that I can just link against a libpython3.so:
http://www.python.org/dev/peps/pep-0384/
As stated by Michael Hertling, the symlinks are not being recursively
resolved. The soname is encoded into the so, so the linker chooses to
ignore the original filename.
Regards,
Juan
On Thu, Dec 30, 2010 at 6:23 AM, Michael Wild them...@gmail.com wrote:
On 12/30/2010 12:28 AM, j s wrote:
I specified the full name to an so in CMAKE 2.8.1. Unfortunately it
links
against the versioned so name,
libpython2.6.so.1.0
instead of the exact name I specified.
/usr/lib/libpython2.6.so
SET (PYTHON_ARCHIVE /usr/lib/libpython2.6.so)
TARGET_LINK_LIBRARIES (myapp parser engine ${PYTHON_ARCHIVE}
${OPENSSL_ARCHIVE})
Is there any way to tell cmake to do the right thing in Linux? For some
strange reason using -l on the link line, and doesn't even use the
corresponding -L to the path I specify.
-lpython2.6
Regards,
Juan
There's nothing CMake can do about this, this is the linker getting in
your way. E.g. on my Ubuntu, /usr/lib/libpython2.6.so is a symlink to
/usr/lib/libpython2.6.so.1 which itself is a symlink to
/usr/lib/libpython2.6.so.1.0. The linker recursively resolves all
symlinks during the linking, and CMake can't do anything about it. You
could pass the full path to the /usr/lib/libpython2.6.so symlink instead
of -lpython2.6 and you would still get the same result.
Actually, this is considered to be a feature. This way, newly compiled
programs will always link against the current version (the one pointed
to by the symlink-chain), while old programs can still use older
versions of the library without requiring to be recompiled.
Michael
Huh?
$ echo int main(){} | gcc -x c -c -o test.o -
$ gcc test.o /usr/lib/libpython2.6.so
$ ldd a.out | grep libpython2.6
libpython2.6.so.1.0 = /usr/lib/libpython2.6.so.1.0 (0x7fbb350f1000)
$ ls -l /usr/lib/libpython2.6.so*
... /usr/lib/libpython2.6.so - libpython2.6.so.1
... /usr/lib/libpython2.6.so.1 - libpython2.6.so.1.0
... /usr/lib/libpython2.6.so.1.0
Sure looks like recursive symlink resolution to me...
No, it's the soname that gets incorporated in the resulting binary;
recursively resolving the symlinks is insignificant in this regard:
echo void f(void){} f.c
echo void g(void){} g.c
gcc -o libf.so -shared -fPIC -Wl,-soname,xyz f.c
gcc -o libg.so.1.0 -shared -fPIC g.c
ln -sf libg.so.1.0 libg.so.1
ln -sf libg.so.1 libg.so
ls -l libg.so*
... libg.so - libg.so.1
... libg.so.1 - libg.so.1.0
... libg.so.1.0
echo int main(void){return 0;} main.c
gcc -o main main.c libf.so libg.so
LD_LIBRARY_PATH=. ldd main
...
xyz = not found
libg.so = ./libg.so (0xb7fbd000)
...
A recursive symlink resolution would make the main executable being
linked against libg.so.1.0 instead of libg.so. In fact, main is linked
against the library specified by the soname - if present - even if that
library doesn't exist at all like xyz in the example above. If there is
no soname the linker incorporates the library as denoted on the command
line. With libpython2.6, the executable is linked against .so.1.0 since
this is the library's soname, but not due to the .so--so.1--.so.1.0
symlink resolution. BTW, the soname denoting the non-existing xyz is
completely artificial, of course, and designed only to clarify the
concern. Usually, ldconfig ensures that there is a valid symlink
soname -- actual library file.
Regards,
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] CMAKE uses wrong symlink to so
On 12/30/2010 12:28 AM, j s wrote:
I specified the full name to an so in CMAKE 2.8.1. Unfortunately it links
against the versioned so name,
libpython2.6.so.1.0
instead of the exact name I specified.
/usr/lib/libpython2.6.so
SET (PYTHON_ARCHIVE /usr/lib/libpython2.6.so)
TARGET_LINK_LIBRARIES (myapp parser engine ${PYTHON_ARCHIVE}
${OPENSSL_ARCHIVE})
Is there any way to tell cmake to do the right thing in Linux? For some
strange reason using -l on the link line, and doesn't even use the
corresponding -L to the path I specify.
-lpython2.6
See [1] for an explanation of the latter behavior. Nevertheless, I
can confirm that - on my system - /usr/lib/libpython2.5.so turns to
-lpython2.5 whereas /usr/lib/libpython2.5.so.1{,.0} do not. Here, I
assume that CMake just uses the well-known extensions .so and .a when
deciding whether a file specification denotes a library in an implicit
system location, so /usr/lib/libpython2.5.so is identified as such one,
but /usr/lib/libpython2.5.so.1{,.0} are not. This results in full paths
in the linker's command line for the latters and a -l option without an
appropriate -L one for the former. Use the trick with imported targets
to force a full path for the /usr/lib/libpythonX.X.so library, too.
However, the fact that your target links against libpython2.6.so.1.0
instead of libpython2.6.so is no CMake issue, but relates to that
library's soname; try
readelf -d /usr/lib/libpython2.6.so | grep SONAME
and see ld's manpage, in particular:
-soname=name
When creating an ELF shared object, set the internal DT_SONAME field
to the specified name. When an executable is linked with a shared
object which has a DT_SONAME field, then when the executable is run
the dynamic linker will attempt to load the shared object specified
by the DT_SONAME field rather than the using the file name given to
the linker.
'hope that helps.
Regards,
Michael
[1] http://www.cmake.org/Wiki/CMake_2.6_Notes#Linking_to_System_Libraries
___
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 make a ProjectConfig.cmake
On 12/30/2010 11:33 AM, Ian Monroe wrote: To create my QyotoConfig.cmake I need to know the full path of a library so that I can set a variable like QYOTO_LIBRARY. This is pretty standard requirement right? Its what we're supposed to do in *Config.cmake's? Yes. So anyways, how do I that? The only target property that hasn't returned NOTFOUND is LOCATION, which unhelpfully returns the location of the library in the build directory. I could parse this to get the file name, and then append it to the library install location... but that seems like such a hack. Feels like I'm doing something wrong if I need to use a hack to do something standard. Usually, I'd have a template QyotoConfig.cmake.in which contains FIND_LIBRARY(QYOTO_LIBRARY qyoto PATHS @CMAKE_INSTALL_PREFIX@/lib NO_DEFAULT_PATH ) and is processed by CONFIGURE_FILE(). If the library is installed with INSTALL(TARGETS qyoto RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib ) the FIND_LIBRARY() in the resulting QyotoConfig.cmake file will find the library right at the installation location but nowhere else, and the platform-dependent file names, e.g. libqyoto.so versus qyoto.dll, are also handled correctly. I looked at install(EXPORT which could work, but it seems to include a lot more information then is needed. I just want to set a variable with the full path to a library. Nevertheless, the imported-targets approach, i.e. the combination of INSTALL(TARGETS ... EXPORT ...) and INSTALL(EXPORT ...) along with an appropriately set up config file, is much more powerful and should be preferred, IMO; see [1] for more information. BTW, as the export file defines the imported targets, its inclusion in the config file should possibly be protected in a suitable way to avoid fatal redefinitions. Regards, Michael [1] http://www.cmake.org/Wiki/CMake_2.6_Notes#Packaging_and_Exporting ___ 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] FLTKConfig.cmake on Microsoft Windows
On 12/30/2010 11:01 AM, Julia Jacobson wrote:
With your help, everything seems to work now.
My final subdirectory src/CMakeLists.txt looks like this:
SET(FLTK_DIR C:/Program Files/fltk-1.1.9/)
SET(FLTK_BASE_LIBRARY C:/Program Files/fltk-1.1.9/lib/)
SET(FLTK_FORMS_LIBRARY C:/Program Files/fltk-1.1.9/lib/)
SET(FLTK_GL_LIBRARY C:/Program Files/fltk-1.1.9/lib/)
SET(FLTK_IMAGES_LIBRARY C:/Program Files/fltk-1.1.9/lib/)
SET(FLTK_INCLUDE_DIR C:/Program Files/fltk-1.1.9/include/)
SET(FLTK_SKIP_FLUID TRUE)
FIND_PACKAGE(FLTK REQUIRED)
if( FLTK_FOUND )
include_directories( ${FLTK_INCLUDE_DIR} )
add_executable( hello main.cpp )
target_link_libraries( hello ${FLTK_LIBRARIES} )
else( FLTK_FOUND )
message(FATAL_ERROR Could not find FLTK)
endif( FLTK_FOUND )
What grieves me is that the CMake code I had prepared in linux looked
really nice (without any absolute paths and so on), but the file for
Windows doesn't.
Truth be told, what's the point of using CMake here instead of a
Makefile? Simply rewriting the build script doesn't cause that more work
either.
Would it help to add the FLTK directory to the Windows PATH variable?
FYI: On *nix, I have installed FLTK 1.1.10 in /tmp/fltk for testing
purposes, and CMake gracefully finds it when CMAKE_PREFIX_PATH is set
accordingly, i.e. cmake -DCMAKE_PREFIX_PATH=/tmp/fltk ... IMO, that's
the preferred way to direct FIND_PACKAGE() to an exceptional location.
So, have you already tried this instead of setting FLTK_INCLUDE_DIR,
FLTK_DIR or the like?
Regards,
Michael
Am Mittwoch, den 29.12.2010, 20:03 +0100 schrieb Julia Jacobson:
Thanks for your answer. The file FindFLTK.cmake exists within my CMake
installation, but I still get an error message:
CMake Error at C:/Program Files/CMake
2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:91
(MESSAGE):
Could NOT find FLTK (missing: FLTK_LIBRARIES FLTK_FLUID_EXECUTABLE)
This is probably due to the fact that I haven't indicated anywhere where
to find my FLTK installation (i.e. C:\Program Files\fltk-1.1.10).
Actually the module file (here FindFLTK) should find the libraries on
any platforms, but in this case...
Before FIND_PACKAGE(FLTK REQUIRED) insert:
SET(FLTK_DIR C:/Program Files/fltk-1.1.10) # NO backslash!
If you did not install fluid)
SET(FLTK_SKIP_FLUID TRUE)
FIND_PACKAGE(...
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] proper setup to create file and have it installed
On 12/28/2010 09:10 AM, edA-qa mort-ora-y wrote:
On 12/27/2010 09:51 PM, Michael Hertling wrote:
You might use the ALL option of ADD_CUSTOM_TARGET() to incorporate the
language target in CMake's all target which, in turn, is built as a
prerequisite of the install target. Alternatively, if the language
file should be installed only if the language target has been built
before, you might use the OPTIONAL flag of the INSTALL(FILES ...)
command to avoid the fatal error due to a missing file.
Thank you, that works.
Now, a related question. Is there some way to successively add files
dependencies to an add_custom_target? I know that DEPENDS does this, but
it'd be nice if I could create a install-files target and in various
points in the file add the files which are needed as dependencies.
Otherwise I will basically have a new target for every install line
which installs a generated file.
AFAIK, the ADD_CUSTOM_TARGET() command isn't open in this sense, i.e.
you can't enhance the dependencies after the target has been defined.
So, you must actually use multiple targets or collect everything and
define the custom target at the end, e.g. with your language files:
UNSET(LANGUAGES)
...
LIST(APPEND LANGUAGES English)
...
LIST(APPEND LANGUAGES French)
...
LIST(APPEND LANGUAGES German)
...
UNSET(LANGFILES)
FOREACH(i IN LISTS LANGUAGES)
SET(LANGFILE ${CMAKE_CURRENT_BINARY_DIR}/${i}.qm)
ADD_CUSTOM_COMMAND(OUTPUT ${LANGFILE} COMMAND ... DEPENDS ...)
LIST(APPEND LANGFILES ${LANGFILE})
ENDFOREACH()
ADD_CUSTOM_TARGET(languages ALL DEPENDS ${LANGFILES})
INSTALL(FILES ${LANGFILES} DESTINATION ...)
The tricky part is how to set up the custom command within the loop.
Regards,
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] Problem building libraries with no sources with Visual Studio 9 (2008)
On 12/22/2010 07:49 PM, Pere Mato Vila wrote:
AFAICS there are three different issues here:
- Having a .def file as a source in a ADD_LIBRARY() it does the correct
thing, which is using it to build the library, but it does not create a
dependency to it. I would call this a bug.
For the nmake generator, this was asked in [1] two years ago but hasn't
received an answer; nevertheless, it seems to have been fixed recently
in [2]. However, I have no idea if it will work with the Visual Studio
generators and, as the case may be, why not. Perhaps due to the same
reason the upcoming LINK_DEPENDS property is limited to Makefiles?
- The way to generate the .def file that I have figured out is perhaps not
optimal and Bill Hoffman has provided me with a solution that exploits
PRE_LINK option in ADD_CUSTOM_COMMAND().
If I understand correctly, you need a dependency of ${library}.def on
${library}-static, and such a dependency can't be established by the
ADD_CUSTOM_COMMAND(TARGET ...) signature. In other words: A changed
${library}-static doesn't invalidate ${library}.def, so ${library}
isn't rebuilt despite the new dependency on .def files. See the
following example with an object file instead of a .def file:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(OBJECT C)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/f0.c void f0(void){}\n)
EXECUTE_PROCESS(COMMAND cc -c f0.c)
ADD_LIBRARY(f SHARED f.c f0.o)
ADD_CUSTOM_COMMAND(TARGET f PRE_LINK COMMAND cc -c f0.c)
f0.o is compiled right before the library target is linked, but
touching f0.c - the prerequisite of f0.o - will entail nothing.
- If I use ADD_LBRARY() with no real source files and only with a .def file
does fail within the IDE (Visual Studio 9) and does work with nmake.
Just a spontaneous notion: On *nix, one can say
ADD_LIBRARY(f SHARED f.def) # Note the .
SET_TARGET_PROPERTIES(f PROPERTIES LINKER_LANGUAGE C)
In spite of f.def not being compilable such that there's no mediate
f.def -- f dependency - that is what I actually meant with CMake
does not know how to handle a .def file - the target gets happily
built without object files, but I don't know if the Visual Studio
tools can be duped in this way.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg17981.html
[2] http://public.kitware.com/Bug/view.php?id=11014
On Dec 22, 2010, at 12:09 AM, Michael Hertling wrote:
On 12/21/2010 08:45 PM, Bill Hoffman wrote:
On 12/21/2010 2:17 PM, Michael Hertling wrote:
AFAIK, this is because CMake does not know how to handle a .def file
for incorporation in the target, i.e. ${library}.def has no LANGUAGE
Actually, it should...
Something like this should work:
(assumes you have a perl script to create a .def file)
cmake_minimum_required (VERSION 2.6)
project (myexe)
set (SOURCES mylib.cxx mylib2.cxx)
# create a list of all the object files
string (REGEX REPLACE \\.cxx .obj OBJECTS ${SOURCES})
# create a shared library with the .def file
add_library (mylib SHARED ${SOURCES}
${CMAKE_CURRENT_BINARY_DIR}/mylib.def
)
# set the .def file as generated
set_source_files_properties (
${CMAKE_CURRENT_BINARY_DIR}/mylib.def
PROPERTIES GENERATED 1
)
# create an executable
add_executable (myexe myexe.cxx)
# link the executable to the dll
target_link_libraries(myexe mylib)
#convert to windows slashes
set (OUTDIR
${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}
)
string (REGEX REPLACE / OUTDIR ${OUTDIR})
# create a custom pre link command that runs
# a perl script to create a .def file using dumpbin
add_custom_command (
TARGET mylib PRE_LINK
COMMAND perl
ARGS ${CMAKE_CURRENT_SOURCE_DIR}/makedef.pl
${CMAKE_CURRENT_BINARY_DIR}\\mylib.def mylib
${OUTDIR} ${OBJECTS} )
Sorry, I haven't expressed myself precisely. My point is that mentioning
the .def file in the target's sources does not establish a dependency of
the target on the .def file, so the target isn't rebuilt when the .def
file has changed:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(DEFS C)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.def.in )
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_BINARY_DIR}/f1.def
COMMAND ${CMAKE_COMMAND} -E
copy ${CMAKE_BINARY_DIR}/f.def.in ${CMAKE_BINARY_DIR}/f1.def
DEPENDS ${CMAKE_BINARY_DIR}/f.def.in
)
SET_SOURCE_FILES_PROPERTIES(
${CMAKE_BINARY_DIR}/f2.def PROPERTIES GENERATED TRUE
)
ADD_LIBRARY(f SHARED f.c f1.def f2.def)
ADD_CUSTOM_COMMAND(
TARGET f
PRE_LINK
COMMAND ${CMAKE_COMMAND} -E copy
${CMAKE_BINARY_DIR}/f.def.in ${CMAKE_BINARY_DIR}/f2.def
)
Touching f1.def or f2.def does not make the target rebuild, and touching
f.def.in just makes f1.def regenerate. It's touching f.c that results in
rebuilding the target due to the f.c -- f.c.o -- libf.so dependencies.
AFAIK, such a dependency does not exist between the target and the .def
Re: [CMake] Problem building libraries with no sources with Visual Studio 9 (2008)
On 12/21/2010 04:13 PM, Pere Mato Vila wrote:
Dear all,
I am trying to build shared libraries on Windows exporting all symbols.
This is as an alternative of instrumenting the code with dllimport/dllexport
declarations. For this I do build first a static library from which I get all
the defined symbols to write a .DEF file which is then used to build the
shared library. The CMake code (using version 2.8.3) looks like this:
add_library( ${library}-static STATIC ${sources} )
add_custom_command( OUTPUT {library}.def COMMAND using ${library}-static
DEPENDS ${library}-static )
add_library(${library} SHARED ${library}.def)
target_link_libraries(${library} ${library}-static ${other-libs} )
set_target_properties(${library} PROPERTIES LINK_INTERFACE_LIBRARIES
${other-libs})
This works just fine when using the nmake generator. The library is
created and has all the symbols are exported as desired. But, when using
Visual C++ 2008 express edition I get the following error message:
1.\mylib.dir\Debug\mylib.dll.intermediate.manifest : general error c1010070:
Failed to load and parse the manifest. The system cannot find the file
specified.
The problem is that the shared library has been defined without any 'real'
source file (only the .def file is declared) and somehow the generated code
does not produce the required manifest file. Does anybody see a problem with
these kind of constructs? Should it just work from within the IDE?
Experimentally I have found a workaround, which consists in adding a dummy
source file in the shared library definition.
...
file( WRITE ${library}.cpp // empty file!!!\n )
add_library( ${library} SHARED ${library}.cpp ${library}.def)
...
I have also noticed that the dependency of the shared library to the .def
file is also missing. This is, newer versions of the .def file does not
trigger a re-build of the shared library.
AFAIK, this is because CMake does not know how to handle a .def file
for incorporation in the target, i.e. ${library}.def has no LANGUAGE
property. Thus, its inclusion in the target's sources results in the
execution of the custom command only. Perhaps, you can enhance your
workaround with the dummy ${library}.cpp as follows:
ADD_CUSTOM_COMMAND(
OUTPUT {library}.def
COMMAND using ${library}-static
COMMAND ${CMAKE_COMMAND} -E touch ${library}.cpp
DEPENDS ${library}-static
)
This would invalidate ${library}.cpp each time ${library}.def is
regenerated, so the dummy is recompiled and ${library} relinked.
Regards,
Michael
PS: Don't write to the source directory with FILE(WRITE ...) or the like.
___
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] Problem building libraries with no sources with Visual Studio 9 (2008)
On 12/21/2010 08:45 PM, Bill Hoffman wrote:
On 12/21/2010 2:17 PM, Michael Hertling wrote:
AFAIK, this is because CMake does not know how to handle a .def file
for incorporation in the target, i.e. ${library}.def has no LANGUAGE
Actually, it should...
Something like this should work:
(assumes you have a perl script to create a .def file)
cmake_minimum_required (VERSION 2.6)
project (myexe)
set (SOURCES mylib.cxx mylib2.cxx)
# create a list of all the object files
string (REGEX REPLACE \\.cxx .obj OBJECTS ${SOURCES})
# create a shared library with the .def file
add_library (mylib SHARED ${SOURCES}
${CMAKE_CURRENT_BINARY_DIR}/mylib.def
)
# set the .def file as generated
set_source_files_properties (
${CMAKE_CURRENT_BINARY_DIR}/mylib.def
PROPERTIES GENERATED 1
)
# create an executable
add_executable (myexe myexe.cxx)
# link the executable to the dll
target_link_libraries(myexe mylib)
#convert to windows slashes
set (OUTDIR
${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_INTDIR}
)
string (REGEX REPLACE / OUTDIR ${OUTDIR})
# create a custom pre link command that runs
# a perl script to create a .def file using dumpbin
add_custom_command (
TARGET mylib PRE_LINK
COMMAND perl
ARGS ${CMAKE_CURRENT_SOURCE_DIR}/makedef.pl
${CMAKE_CURRENT_BINARY_DIR}\\mylib.def mylib
${OUTDIR} ${OBJECTS} )
Sorry, I haven't expressed myself precisely. My point is that mentioning
the .def file in the target's sources does not establish a dependency of
the target on the .def file, so the target isn't rebuilt when the .def
file has changed:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(DEFS C)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.def.in )
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_BINARY_DIR}/f1.def
COMMAND ${CMAKE_COMMAND} -E
copy ${CMAKE_BINARY_DIR}/f.def.in ${CMAKE_BINARY_DIR}/f1.def
DEPENDS ${CMAKE_BINARY_DIR}/f.def.in
)
SET_SOURCE_FILES_PROPERTIES(
${CMAKE_BINARY_DIR}/f2.def PROPERTIES GENERATED TRUE
)
ADD_LIBRARY(f SHARED f.c f1.def f2.def)
ADD_CUSTOM_COMMAND(
TARGET f
PRE_LINK
COMMAND ${CMAKE_COMMAND} -E copy
${CMAKE_BINARY_DIR}/f.def.in ${CMAKE_BINARY_DIR}/f2.def
)
Touching f1.def or f2.def does not make the target rebuild, and touching
f.def.in just makes f1.def regenerate. It's touching f.c that results in
rebuilding the target due to the f.c -- f.c.o -- libf.so dependencies.
AFAIK, such a dependency does not exist between the target and the .def
files, or have I got you wrong?
Regards,
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] granular install advice
On 12/17/2010 03:31 PM, luxInteg wrote:
Greetings,
I am learning cmake.
If I were to have some homebrewed ModulesForCMakeIdiots.cmake from my
learning project in say ${CMAKE_SOURCE_DIR}/modules
and I set this command:-
install(FILES ${CMAKE_SOURCE_DIR}/modules/*.cmake /usr/local/someplace )
do be done AT INSTALL time
(i.e. I want to install the modules on the file syatem say
/usr/local/someplace) -the above is like to copy the modules to
${INSTALL_PREFIX}/usr/local/someplace.
So how do I tell cmake to copy to /usr/local/someplace instead?
The correct signature of the INSTALL(FILES ...) command is
INSTALL(FILES ... DESTINATION /usr/local/someplace ...)
^^^
and the manual - which you've studied thoroughly, I suppose - states:
DESTINATION arguments specify the directory on disk to which a file
will be installed. If a *full path* (with a leading slash or drive
letter) is given it is used directly. If a relative path is given
it is interpreted relative to the value of CMAKE_INSTALL_PREFIX.
Besides, you can't specify the files for INSTALL(FILES ...) using the
'*' and other globbing characters as they are meaningful only for the
shell or specialized CMake commands like FILE(GLOB ...).
Regards,
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] Linking archives in a sibling directory
On 12/03/2010 04:26 PM, Raymond Wan wrote:
Hi Michael,
Thank you for your continued advice!
On Fri, Dec 3, 2010 at 19:13, Michael Hertling mhertl...@online.de wrote:
Nevertheless, I wonder why you want to build main by configuring its
own source directory and alternatively via the top-level directory. If
this is because you'd like to exclude some modules from building, you
should handle such things in the top-level CMakeLists.txt, e.g. like:
# Define options:
OPTION(WITH_MAIN Build module main ON)
OPTION(WITH_A Build module A ON)
OPTION(WITH_B Build module B ON)
# Handle dependencies:
IF(WITH_MAIN)
SET(WITH_A ON)
ENDIF()
# Enable modules:
IF(WITH_B)
ADD_SUBDIRECTORY(dir-B)
ENDIF()
IF(WITH_A)
ADD_SUBDIRECTORY(dir-A)
ENDIF()
IF(WITH_MAIN)
ADD_SUBDIRECTORY(main)
ENDIF()
So, you can conveniently enable/disable the modules on the command line
or in the GUI, e.g. with cmake -DWITH_B=OFF path/to/top-level-dir
if you don't want to build module B.
As an alternative, you might consider to move dir-A to main/dir-A if
dir-A is essentially a submodule of main, but referring to a sibling
dir-A from main indicates that the latter is not sufficiently self-
contained to be built on its own with a cmake path/to/main, so
the modules' relationships should be handled by other means, IMO.
Hm, I see your point about why I'm providing support in a
top-level CMakeLists.txt and a lower level one. Perhaps I've simply
confused myself and made things more complicated than it needs to be.
Basically, what I want to do is, given this directory structure:
myproj/
+dirA/
+dirB/
+dirC/
+main1/
+main2/
+main3/
my final goal is that several programs (i.e., executables) will be
made. Let's say main1, main2, and main3. The libraries dirA, ...,
dirD are used by them and can also depend on each other with maybe
even multiple levels of dependencies. i.e.,
dirA -- dirB -- dirC
Any of these modules can be used by more than one program. i.e.,
main1 -- dirA -- dirB -- dirC
main2 -- dirC
My idea is that the top level CMakeLists.txt can create main1, main2,
and main3. The lower level CMakeLists.txt in dirA/, dirB/, and dirC/
have their own main () which I am using to test them -- obviously,
these main () functions are not linked into main1, main2, and main3.
I only need them for development. I think organizing dirA/, dirB/,
and dirC/ within main1/, main2/, and main3/ isn't the way to go since
these libraries are used by multiple executables.
Yes, absolutely, with such relations among executables and libraries,
their source directories should be siblings instead of descendants, and
the libraries' testing executables can be conveniently integrated using
ADD_TEST() without interfering with the main executables. However, when
your project grows and, hence, the number of source directories in the
project's root increases, say 10+, you should consider to organize them
further, e.g. like
myproj
executables
main{1,2,3,...}
libraries
dir{A,B,C,...}
plugins
...
or
myproj
source
core
...
gui
...
db
...
or whichever organizational criteria apply best, so the root directory
doesn't fill with countless source directories. Apart from that, there
is no need to have the top-level CMakeLists.txt create the main{1,2,3}
executables by itself; just add a CMakeLists.txt file in each of their
source directories as you do for the libraries, and use
ADD_SUBDIRECTORY(main1)
ADD_SUBDIRECTORY(main2)
ADD_SUBDIRECTORY(main3)
at the top level to enable them. In this way, you've a CMakeLists.txt
file in each of your project's source directories which does exactly
what needs to be done there, and the whole project is covered by the
top-level CMakeLists.txt with minimal assumptions w.r.t. the source
directories.
Perhaps I should create and use the low-level CMakeLists.txt and when
I am finished development, then create the top-level ones for just
main1, main2, and main3. In a way, I will only need to support either
the top-level CMakeLists.txt or the lower level one and never both at
the same time. I guess I am ahead of myself and did both now, which
is complicating things for me.
IMO, there is no reason to configure with lower-level CMakeLists.txt
files at first and switch to a top-level CMakeLists.txt later. Instead,
start right away with one CMakeLists.txt file per source directory and
one top-level CMakeLists.txt, and whenever a new source directory with
its own CMakeLists.txt is added to your project, just add an according
ADD_SUBDIRECTORY() at the top level, too. So, you will always have a
clean and regular configurational setup without the need to bother
with different starting points for configuring your project.
H, I need to give this a bit more thought -- any suggestions
welcome... Thank you!
Regards,
Michael
___
Powered
Re: [CMake] Dependency rule not included
On 12/08/2010 04:28 PM, Vivien Delmon wrote:
On 12/08/2010 04:13 PM, Michael Wild wrote:
On 12/08/2010 03:54 PM, Micha Renner wrote:
Am Mittwoch, den 08.12.2010, 14:55 +0100 schrieb Vivien Delmon:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
ADD_CUSTOM_COMMAND(OUTPUT toto.h toto.c
COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/create_totoc_totoh.sh
)
SET_SOURCE_FILES_PROPERTIES(toto.h toto.c PROPERTIES GENERATETED TRUE)
See:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:set_source_files_properties
and:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_sf:GENERATED
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR})
ADD_LIBRARY(titi toto.c)
ADD_LIBRARY(tata tata.c)
Greetings
Micha
the GENERATED property is set automatically by ADD_CUSTOM_COMMAND. But I
suspect the problem is that you used a relative path in your OUTPUT
option. *Always* specify full paths in the OUTPUT and DEPENDS options.
Also, make the custom command DEPENDS on the create_totoc_totoh.sh
script and it's input (perhaps it reads some configuration file or you
pass it another file as an argument, etc.).
Both solutions does not solve the problem.
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_CURRENT_SOURCE_DIR}/toto.h
${CMAKE_CURRENT_SOURCE_DIR}/toto.c
COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/create_totoc_totoh.sh
)
SET_SOURCE_FILES_PROPERTIES(toto.h toto.c PROPERTIES GENERATETED TRUE)
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR})
ADD_LIBRARY(titi toto.c)
ADD_LIBRARY(tata tata.c)
The problem is that tata.c include toto.h. cmake does not know it
because C file dependencies are constructed later by make. The result is
that CMakeFiles/tata.dir/build.make does not include the rule needed to
construct toto.h. I try to find a way to add this rule.
A workaround consists in putting toto.h in libtata dependencies but it's
not a dependency of libtata but a dependency of tata.c.
IMO, this isn't a workaround but the proper solution because the
dependency on toto.h actually doesn't consist for tata.c but for
tata.c.o and, thus, for the tata target, effectively. In other
words: Which action do you intend to perform in order to update
tata.c if toto.h has changed? Compiling updates the object file.
Alternatively, if the object file is newer than the header, and
the header is newer than the source file, is there a need to take
action? So, saying ADD_LIBRARY(tata tata.c toto.h) or setting the
OBJECT_DEPENDS property as Michael has proposed in the meantime is
certainly appropriate.
Regards,
Michael
The error is :
[ 33%] Building C object CMakeFiles/tata.dir/tata.c.o
/home/vivien/tmp/cmake_deps/tata.c:1:18: fatal error: toto.h: No such
file or directory
compilation terminated.
___
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 apply the --as-needed linker flag?
On 11/28/2010 09:10 AM, Alan W. Irwin wrote:
On 2010-11-28 06:39+0100 Michael Hertling wrote:
On 11/27/2010 06:45 PM, Alan W. Irwin wrote:
I just discovered that many Linux distros these days use the
--as-needed Linux linker option by default. At first glance that
option makes a lot of sense since it tends to reduce startup times.
But I guess there are some caveats as well which is probably why CMake
does not adopt this linker option by default for Linux builds.
However, I would at least like to try this option for my own Linux
builds without forcing it using target_link_libraries. Is it possible
to specify linker options such as --as-needed using environment
variables and/or -D options?
On Linux, CMake takes account of the LDFLAGS environment variable
for the initial configuration of the build directory, so saying
LDFLAGS=-Wl,--as-needed cmake path/to/srcdir
enables --as-needed for this build directory - forever.
Thanks, Michael, that was exactly what I needed. I was completely
unaware that environment variable worked for CMake despite many years
of using CMake on Linux. Is the LDFLAGS environment variable
documented for CMake anywhere? I couldn't find it in the
documentation you get with cmake --help-full, and it is also not
documented at http://www.cmake.org/Wiki/CMake_Useful_Variables. The
useful environment variables CXXFLAGS, CFLAGS, and FFLAGS that allow
you to specify general compiler flags in a convenient way are
undocumented as well, and that is a real shame.
AFAIK, these variables aren't documented anywhere apart from
occasionally appearing on the mailing list. However, a quick
grep \\\$ENV{[A-Za-z0-9_]\+} -r . | sed
s%^.*\\\$ENV{\([A-Za-z0-9_]\+\)}.*\$%\1% | sort -u
in the modules' directory reveals all of them which are read from
the environment. Apparently, the relevant ones are CC/CFLAGS, CXX/
CXXFLAGS, FC/FFLAGS, LDFLAGS, and RC/RCFLAGS for WIN32. Because of
their special meaning for a project's initial configuration, there
should be an enhancement of the useful-variables section, indeed.
Regards,
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] providing library information, what's the cmake way
On 12/01/2010 05:57 PM, Johannes Zarl wrote:
On 12/01/2010 at 16:06, Michael Hertling mhertling at online.de wrote:
FIND_PACKAGE(XXX COMPONENTS YYY)
...
ADD_SUBDIRECTORY(subdir)
...
TARGET_LINK_LIBRARIES(AAA ${XXX_LIBRARIES})
TARGET_LINK_LIBRARIES(BBB ${XXX_LIBRARIES} ${XXX_YYY_LIBRARIES})
In subdir/CMakeLists.txt:
FIND_PACKAGE(XXX COMPONENTS ZZZ)
...
TARGET_LINK_LIBRARIES(subBBB ${XXX_LIBRARIES} ${XXX_ZZZ_LIBRARIES})
As I mentioned above, I would expect XXX_LIBRARIES to contain only the
base library, and find_package calls to act accumulatively.
If I understand correctly, you'd like to have a set of variables like
XXX_*_{LIBRARIES,INCLUDE_DIRS,...} for each component instead of one
comprehensive set XXX_{LIBRARIES,INCLUDE_DIRS,...} for the entire
package including the components; this hasn't been obvious to me.
Correct.
The downside of your approach is that you have to mention component-
specific variables at various locations: For each component denoted
in the FIND_PACKAGE() invocation, you would usually have to mention
- XXX_*_INCLUDE_DIRS in INCLUDE_DIRECTORIES()
- XXX_*_LIBRARIES in TARGET_LINK_LIBRARIES()
- XXX_*_DEFINITIONS in ADD_DEFINITIONS()
Which is less work than saving all three values for each target that
I create.
It's not necessary to save these variables for each target. Typically,
it's necessary if there's more than one target in the CMakeLists.txt,
and two or more of them use the same package with a different set of
components; by far, this does not hold for all cases. Besides, when
loading multiple packages for multiple targets, it's not uncommon to
collect libraries in target-specific target_LIBRARIES variables as
well as one collects a target's sources in target_SOURCES, so the
only remaining overhead is an additional FIND_PACKAGE() call which
is inexpensive:
FIND_PACKAGE(A)
SET(T1_LIBRARIES ${A_LIBRARIES})
SET(T2_LIBRARIES ${A_LIBRARIES})
FIND_PACKAGE(B COMPONENTS B1)
LIST(APPEND T1_LIBRARIES ${B_LIBRARIES})
FIND_PACKAGE(B COMPONENTS B2) # -- That's all.
LIST(APPEND T2_LIBRARIES ${B_LIBRARIES})
...
TARGET_LINK_LIBRARIES(T1 ${T1_LIBRARIES})
TARGET_LINK_LIBRARIES(T2 ${T2_LIBRARIES})
A similar point might be applied to XXX_{INCLUDE_DIRS,DEFINITIONS}.
in addition to the package's base stuff, i.e. roughly speaking, with n
components you need to reference 3+3n variables.
These 3+3n variables have to be defined, anyways (the find module needs
them internally, if it wants to compose XXX_INCLUDE_DIRS etc.).
Here, it's the user I have in mind, who possibly doesn't want to
fourfold specify each set of components requested from a package.
Still, referencing the 3+3n variables are less work than having to
define _and_ reference 3N variables (with N being the number of targets
in your project).
The need to save the results of a FIND_PACKAGE() call may come up for
targets within the same CMakeLists.txt file, but not unconditionally
for each of a project's targets. Additionally, this measure is taken
only if it's really necessary whereas your approach compels the user
to always refer to each component four times. Look at one of the
simplest configurations - one target and one package with two
components - the two approaches manifest like:
FIND_PACKAGE(XXX COMPONENTS YYY ZZZ)
ADD_DEFINITIONS(${XXX_DEFINITIONS}
${XXX_YYY_DEFINITIONS} ${XXX_ZZZ_DEFINITIONS})
INCLUDE_DIRECTORIES(${XXX_INCLUDE_DIRS}
${XXX_YYY_INCLUDE_DIRS} ${XXX_ZZZ_INCLUDE_DIRS})
ADD_EXECUTABLE(...)
TARGET_LINK_LIBRARIES(... ${XXX_LIBRARIES}
${XXX_YYY_LIBRARIES} ${XXX_ZZZ_LIBRARIES})
versus
FIND_PACKAGE(XXX COMPONENTS YYY ZZZ)
ADD_DEFINITIONS(${XXX_DEFINITIONS})
INCLUDE_DIRECTORIES(${XXX_INCLUDE_DIRS})
ADD_EXECUTABLE(...)
TARGET_LINK_LIBRARIES(... ${XXX_LIBRARIES})
It's quite obvious which approach means less work, and having only one
target in a CMakeLists.txt is no configuration I would denote as rare.
IMO, this thwarts the
idea of a multi-component package: Specifying components to adjust the
well-known and officially recommended package-related variables like
XXX_LIBRARIES.
These variables are well-known and officially recommended for component-
less packages only. Nobody bothered to write recommendations for
component-packages yet.
${CMAKE_ROOT}/Modules/readme.txt mentions the XXX_YYY_EXECUTABLE and
XXX_YY_{LIBRARY,INCLUDE_DIR} variables explicitly, and IMO, wordings
as YYY tool that comes with XXX or YY library that is part of the
XXX system allow the general terms tool and part to be applied
smoothly to the components of a package. Furthermore, the component-
specific variables like XXX_FIND_COMPONENTS are handled also, so I
do believe that this file is relevant for multi-component packages,
too, including the XXX_{LIBRARIES,INCLUDE_DIRS} variables. However,
variables like XXX_YYY_{LIBRARIES,INCLUDE_DIRS} are not mentioned
at all, i.e. there're completely new and should be well founded.
Anyway, the ${CMAKE_ROOT}/Modules/readme.txt doesn't
Re: [CMake] providing library information, what's the cmake way
On 11/30/2010 05:53 AM, Kishore wrote: On Tuesday 23 Nov 2010 5:27:56 pm Johannes Zarl wrote: Another somehow related topic seems to be import/export of targets. Should a LibraryConfig.cmake or FindLibrary.cmake file create imported targets for the library? Thanks for this thread. It has helped. However, i am still not clear about the use of the export/import feature. I thought that libraries built with cmake would not need to write their Find*.cmake or *Config.cmake modules as they could simply use the EXPORT feature. No, the file created and installed by INSTALL(EXPORT ...) - casually denoted as a targets file - contains information about the targets provided by the package. The targets are set up as IMPORTED in the targets file, and the latter must be included by *Config.cmake which is still necessary. This is meant as a more flexible alternative to explicit paths in XXX_LIBRARIES variables, e.g.; with targets files, XXX_LIBRARIES contains the imported targets instead of the targets' paths, so the different build types can be handled much better at link time. The actual paths of the imported targets are specified by means of IMPORTED_LOCATION properties in the targets file, too. It would be really helpful if someone could explain the proper use of these features. In [1,2], the machinery is explained quite well. Regards, Michael [1]http://www.cmake.org/Wiki/CMake_2.6_Notes#Exporting_from_an_Installation_Tree [2]http://www.cmake.org/Wiki/CMake_2.6_Notes#Packaging_and_Exporting ___ 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] Linking archives in a sibling directory
On 12/02/2010 03:13 PM, Raymond Wan wrote:
Hi Michael,
On Thu, Dec 2, 2010 at 19:40, Michael Hertling mhertl...@online.de wrote:
On 12/01/2010 06:03 PM, Raymond Wan wrote:
Ah! I see. Then is it recommended that this top-level CMakeLists.txt
have just these lines, or should I move the ADD_EXECUTABLE, etc. lines
here as well? Or is this really up to me and there isn't a
suggested paradigm?
Basically, IMO, a CMakeLists.txt with ADD_EXECUTABLE() et al. should be
placed in the same directory as the related source files unless there's
a reason not to do so; this makes for modularity and a well organized
code base. The above-mentioned directory structure with its top-level
CMakeLists.txt containing just ADD_SUBDIRECTORY() commands keeps the
modules main, dir-A and dir-B separate with minimal interconnections.
In the previous structure, e.g., main/CMakeLists.txt had to know that
dir-A resides in ../dir-A; now, such information is concentrated in
the top-level CMakeLists.txt, and the sole reference of main to dir-A
is the target subprogA_ar. Due to CMake's capabilities to track the
dependencies among targets, it doesn't matter where dir-A is placed
within the project's source tree. So, in short, don't move the
ADD_EXECUTABLE() etc. to the top-level CMakeLists.txt.
I see -- I did not realize this point you made about CMake's
dependency tracking abilities. So, basically the only thing I need to
worry about is the order of the ADD_SUBDIRECTORY ()'s. As long as I
put
ADD_SUBDIRECTORY (dir-A)
before
ADD_SUBDIRECTORY (main)
then main will be built correctly?
Even this is not necessary if the only reference of main to dir-A is
TARGET_LINK_LIBRARIES(... subprogA_ar) in main/CMakeLists.txt since
TARGET_LINK_LIBARIES(), AFAIK, does a lazy evaluation of the targets'
dependencies, i.e. they are evaluated when all CMakeLists.txt files
have been processed and, hence, all dependencies are known. If you
refer to subprogA_ar in another way, e.g. SET_TARGET_PROPERTIES(),
then you will get an error if dir-A hasn't been configured yet.
But, if I am not mistaken and following what you are saying, I can
only build main using the top-level CMakeLists.txt. The lower
CMakeLists.txt in main/ does not know the location of dir-A. The
only way for both to work is to have this in main/CMakeLists.txt:
ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
yet this kind of duplication should be an error at worse; unnecessary
repetition at best?
Each invocation of ADD_SUBDIRECTORY() for a source directory must be
associated with an own binary directory, so the above-mentioned line
would allow you to use both alternatives. However, when configuring
the top-level CMakeLists.txt, you will get an error due to multiple
definitions of the subprogA_ar target. In main/CMakeLists.txt, you
might protect ADD_SUBDIRECTORY() against multiple invocations like
IF(NOT TARGET subprogA_ar)
ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
ENDIF()
or
IF(${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_SOURCE_DIR})
ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
ENDIF()
but this does not appear really appropriate to me.
Nevertheless, I wonder why you want to build main by configuring its
own source directory and alternatively via the top-level directory. If
this is because you'd like to exclude some modules from building, you
should handle such things in the top-level CMakeLists.txt, e.g. like:
# Define options:
OPTION(WITH_MAIN Build module main ON)
OPTION(WITH_A Build module A ON)
OPTION(WITH_B Build module B ON)
# Handle dependencies:
IF(WITH_MAIN)
SET(WITH_A ON)
ENDIF()
# Enable modules:
IF(WITH_B)
ADD_SUBDIRECTORY(dir-B)
ENDIF()
IF(WITH_A)
ADD_SUBDIRECTORY(dir-A)
ENDIF()
IF(WITH_MAIN)
ADD_SUBDIRECTORY(main)
ENDIF()
So, you can conveniently enable/disable the modules on the command line
or in the GUI, e.g. with cmake -DWITH_B=OFF path/to/top-level-dir
if you don't want to build module B.
As an alternative, you might consider to move dir-A to main/dir-A if
dir-A is essentially a submodule of main, but referring to a sibling
dir-A from main indicates that the latter is not sufficiently self-
contained to be built on its own with a cmake path/to/main, so
the modules' relationships should be handled by other means, IMO.
Regards,
Michael
The top-level directory of non-trivial projects should not contain any
source files, perhaps a config.h header or the like. Usually, there're
enough things gathering in a project's root, e.g. READMEs, subdirs for
documentation, resources or CMake stuff, a CMakeLists.txt file ;) etc.
The sources, however, should be organized in their own subdirectories,
so the top-level CMakeLists.txt typically contains ADD_SUBDIRECTORY()
commands along with configurational stuff like setting up compiler
flags, processing options or investigating the underlying system,
but no ADD_EXECUTABLE() or the like.
Of course
Re: [CMake] find_package with ###Config.cmake
On 12/03/2010 08:45 AM, Andreas Pakulat wrote:
On 03.12.10 07:11:23, Micha Renner wrote:
There is a small library TLib which is installed like this
Install the project...
-- Install configuration: Debug
-- Installing: /usr/local/lib/libTLibd.so
-- Installing: /usr/local/lib/TLib/TLibExport.cmake
-- Installing: /usr/local/lib/TLib/TLibExport-debug.cmake
-- Installing: /usr/local/include/TLib/cmFile.h
-- Installing: /usr/local/lib/TLib/TLIBConfig.cmake
-- Installing: /usr/local/lib/TLib/TLIBConfigVersion.cmake
The CMakeLists file for the application program has the following line
to find the library
FIND_PACKAGE(TLIB)
This works, surprisingly, very good. No CMAKE_MODULE_PATH, no TLIB_DIR
in this case.
But...
If I call FIND_PACKAGE with version:
FIND_PACKAGE(TLIB 1.3)
I get the std-warning:
-
CMake Warning at TestDLL/CMakeLists.txt:20 (FIND_PACKAGE):
Could not find module FindTLIB.cmake or a configuration file for
package
TLIB.
Adjust CMAKE_MODULE_PATH or TLIB_DIR...
-
Why can't CMake find the TLIBConfig file, if FIND_PACKAGE is called with
version and TLIB_DIR is not set?
The problem might not be finding the Config file, but rather that the
ConfigVersion file doesn't set the VERSION_COMPATIBLE or VERSION_EXACT
variables. Or maybe it even sets the VERSION_UNSUITABLE to indicate that
the installed version of TLib doesn't match the version you request.
Unfortunately cmake currently cannot seem to distinguish between these
two cases (non-matching version vs. no config-file found), hence it
produces the same message in both cases.
Meanwhile, with 2.8.3 to be exact, the warning message issued by CMake
if a version file is found but the requested version doesn't suit is:
Could not find a configuration file for package ... that is compatible
with requested version
The following configuration files were considered but not accepted:
..., version: ...
So, Micha, which CMake version do you use? If it's not 2.8.3 could you
give that a try and report the message if the problem still persists?
Additionally, the package_CONSIDERED_{CONFIGS,VERSIONS} variables
would be of special interest, see dfe9c95.
Regards,
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] Linking archives in a sibling directory
On 12/01/2010 06:03 PM, Raymond Wan wrote:
Hi Michael,
On Thu, Dec 2, 2010 at 01:03, Michael Hertling mhertl...@online.de wrote:
On 12/01/2010 08:18 AM, Raymond Wan wrote:
Hi all,
I'm having a problem understanding how I can link to an archive in
another directory which is not a subdirectory. For example:
myproj
+-- main
+-- CMakeLists.txt
+-- source files for main program
+-- dir-A
+-- CMakeLists.txt
+-- source files for sub-program A
+-- dir-B
+-- CmakeLists.txt
+-- source files for sub-program B
This error is caused by the fact that the directory dir-A is outside
the main directory tree, so dir-A's binary directory would likewise
be outside main's binary tree, and this is reasonably forbidden when
configuring main. You might specify dir-A's binary directory in
main/CMakeLists.txt explicitly, e.g.:
ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
Hence, subprogA_ar will be built within the binary tree's dir-A.
Ah! I see now. I didn't realize I could prepend a path like that. I
was trying to find some kind of ADD_DIRECTORY command which had this
restriction removed. But then I realized if I'm looking for something
like that, there might be a bigger problem in terms of how I'm
organizing things...
myproj
+-- main
+-- CMakeLists.txt
+-- source files for main program
+-- dir-A
+-- source files for sub-program A
+-- dir-B
+-- source files for sub-program B
Is this what I should have done??
As an alternative, consider to add a CMakeLists.txt in myproj
CMAKE_MINIMUM_REQUIRED(...)
PROJECT(myproj)
ADD_SUBDIRECTORY(dir-A)
ADD_SUBDIRECTORY(dir-B)
ADD_SUBDIRECTORY(main)
and subsequently, configure this directory instead of main.
Ah! I see. Then is it recommended that this top-level CMakeLists.txt
have just these lines, or should I move the ADD_EXECUTABLE, etc. lines
here as well? Or is this really up to me and there isn't a
suggested paradigm?
Basically, IMO, a CMakeLists.txt with ADD_EXECUTABLE() et al. should be
placed in the same directory as the related source files unless there's
a reason not to do so; this makes for modularity and a well organized
code base. The above-mentioned directory structure with its top-level
CMakeLists.txt containing just ADD_SUBDIRECTORY() commands keeps the
modules main, dir-A and dir-B separate with minimal interconnections.
In the previous structure, e.g., main/CMakeLists.txt had to know that
dir-A resides in ../dir-A; now, such information is concentrated in
the top-level CMakeLists.txt, and the sole reference of main to dir-A
is the target subprogA_ar. Due to CMake's capabilities to track the
dependencies among targets, it doesn't matter where dir-A is placed
within the project's source tree. So, in short, don't move the
ADD_EXECUTABLE() etc. to the top-level CMakeLists.txt.
I guess I chose my first directory layout because the source in a
directory (i.e., dir-A) can be several dependencies down and it can
even be used by two targets in two different directories. So, I
figured that keeping them all at the same directory level would be
best. But it seems what you're suggesting here seems better -- never
thought of it; the myproj directory has no files in it...just
directories right now...
The top-level directory of non-trivial projects should not contain any
source files, perhaps a config.h header or the like. Usually, there're
enough things gathering in a project's root, e.g. READMEs, subdirs for
documentation, resources or CMake stuff, a CMakeLists.txt file ;) etc.
The sources, however, should be organized in their own subdirectories,
so the top-level CMakeLists.txt typically contains ADD_SUBDIRECTORY()
commands along with configurational stuff like setting up compiler
flags, processing options or investigating the underlying system,
but no ADD_EXECUTABLE() or the like.
Of course, there're exceptions and probably strong different opinions.
Regards,
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] providing library information, what's the cmake way
On 11/30/2010 01:32 PM, Johannes Zarl wrote:
- Do multiple consecutive FIND_PACKAGE(XXX ...) invocations act in an
accumulative manner on the invocation-specific variables?
Generally speaking, I would say: yes. At least this is the way of the
least surprise for the user, as in sufficiently complex projects a
package may be included at different places with different arguments.
For the same reason, I'd tend to the opposite; look at the following:
FIND_PACKAGE(XXX COMPONENTS YYY)
...
ADD_SUBDIRECTORY(subdir)
In subdir/CMakeLists.txt:
FIND_PACKAGE(XXX COMPONENTS ZZZ)
...
TARGET_LINK_LIBRARIES(... ${XXX_LIBRARIES})
Here, the target is also linked against XXX_YYY_LIBRARY as the latter is
inherited via XXX_LIBRARIES from the parent directory, but if the target
only needs XXX_ZZZ_LIBRARY it will possibly be overlinked. Although this
can be avoided by resetting XXX_LIBRARIES before each FIND_PACKAGE()
invocation, I don't think that's the way one would like to go.
IMO, the invocation-specific results of any FIND_PACKAGE() call should
depend solely on the parameters passed in and the well-known variables
like CMAKE_PREFIX_PATH. The downside is that one must possibly process
or save the results before they could be overwritten, e.g.:
FIND_PACKAGE(XXX REQUIRED YYY)
SET(LIBRARIES ${XXX_LIBRARIES})
FIND_PACKAGE(XXX COMPONENTS ZZZ)
LIST(APPEND LIBRARIES ${XXX_LIBRARIES})
...
TARGET_LINK_LIBRARIES(... ${LIBRARIES})
Since such related calls to FIND_PACKAGE(XXX ...) usually occur nearby
each other within the same CMakeLists.txt, this little penalty should
be acceptable whereas accumulated XXX_LIBRARIES and the like may have
far reaching and surprising effects, especially in complex projects.
Funny enough, my example is almost the same:
FIND_PACKAGE(XXX COMPONENTS YYY)
...
ADD_SUBDIRECTORY(subdir)
...
TARGET_LINK_LIBRARIES(AAA ${XXX_LIBRARIES})
TARGET_LINK_LIBRARIES(BBB ${XXX_LIBRARIES} ${XXX_YYY_LIBRARIES})
In subdir/CMakeLists.txt:
FIND_PACKAGE(XXX COMPONENTS ZZZ)
...
TARGET_LINK_LIBRARIES(subBBB ${XXX_LIBRARIES} ${XXX_ZZZ_LIBRARIES})
As I mentioned above, I would expect XXX_LIBRARIES to contain only the
base library, and find_package calls to act accumulatively.
If I understand correctly, you'd like to have a set of variables like
XXX_*_{LIBRARIES,INCLUDE_DIRS,...} for each component instead of one
comprehensive set XXX_{LIBRARIES,INCLUDE_DIRS,...} for the entire
package including the components; this hasn't been obvious to me.
Nevertheless, what do you understand by accumulative in this regard,
i.e. what accumulates in which variables if FIND_PACKAGE() is invoked
multiple times and each component has an independent set of variables
separate from the package's base stuff?
If it was otherwise, then target AAA would be overlinked, and BBB would
probably fail to link. Even without the ADD_SUBDIRECTORY the situation
would be far from ideal: in order to avoid overlinking of BBB I have to
make an additional find_package invocation. In a worst-case scenario one
would need multiple find_package invocations for the same packages before
each target!
At first, BBB could not fail to link due to the FIND_PACKAGE() in the
subdir/CMakeLists.txt because the XXX_LIBRARIES variable in the parent
directory is not modified unless the find module uses the PARENT_SCOPE
option of SET(), but there's no reason to do so as it is pretty unwise.
In contrast, the potential overlinking of AAA is a point, indeed, as it
is generally with multiple targets, each depending on an individual set
of components, within the same CMakeLists.txt. Here, I'd actually need
to call FIND_PACKAGE() multiple times and immediately process/save the
variables like XXX_LIBRARIES if they're really invocation-specifically
populated, but I'm in doubt whether this can be reckoned as far from
ideal. Note that because of CMake's caching, repeated invocations of
FIND_PACKAGE() don't tend to be expensive, so
FIND_PACKAGE(XXX COMPONENTS base)
TARGET_LINK_LIBRARIES(AAA ${XXX_LIBRARIES})
FIND_PACKAGE(XXX COMPONENTS base YYY)
TARGET_LINK_LIBRARIES(BBB ${XXX_LIBRARIES})
is nothing I'd be afraid of. Moreover, in subdir/CMakeLists.txt, you
have to call FIND_PACKAGE() anew anyway, as you've also when mixing
optional and required components with a usage of the REQUIRED flag.
The accumulative scenario of find_package without side-effects of the
components on the XXX_LIBRARIES is far more transparent:
If you link against XXX_LIBRARIES, you know exactly what you are linking
against, regardless of who called find_package(XXX) with whatever
components since you did your find_package call. You don't even have to
backup your XXX_LIBRARIES and other variables, because they are not
altered.
The downside of your approach is that you have to mention component-
specific variables at various locations: For each component denoted
in the FIND_PACKAGE() invocation, you would usually have to mention
- XXX_*_INCLUDE_DIRS in
Re: [CMake] (no subject)
On 12/01/2010 03:45 PM, Gary%20G.%20Little%20%40%20comcast wrote:
I have a Visual Studio 2010 solution and I am trying to set the
Configuration Properties - General - Platform Toolset of one
particular project to use V90 to allow this project to build with the VS
2008 tool set. I followed an older thread and tried this:
set_target_properties(WindowsApplication${version} PROPERTIES
PlatformToolset V90)
That results in an error: set_target_properties Can not find target to
add properties to. ${version} is set to a version string and the term
WindowsApplication${version} is used later in the file by an
add_library and a target_link_library with no error. How can I set the
platform toolset to V90 from CMAKE?
SET_TARGET_PROPERTIES() must not appear before the targets it
operates on, so move this command behind the ADD_LIBRARY().
Regards,
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] Linking archives in a sibling directory
On 12/01/2010 08:18 AM, Raymond Wan wrote:
Hi all,
I'm having a problem understanding how I can link to an archive in
another directory which is not a subdirectory. For example:
myproj
+-- main
+-- CMakeLists.txt
+-- source files for main program
+-- dir-A
+-- CMakeLists.txt
+-- source files for sub-program A
+-- dir-B
+-- CmakeLists.txt
+-- source files for sub-program B
Basically, I would like to make a larger project (main) and I'm
building and testing each of its components separately.
Right now, the main's CMakeLists.txt looks something like this:
INCLUDE_DIRECTORIES (../dir-A)
SUBDIRS (../dir-A)
ADD_EXECUTABLE (main ${MAIN_SRCS})
TARGET_LINK_LIBRARIES (main subprogA_ar)
which works fine so far (the CMakeLists.txt in dir-A generates the
archive subprogA_ar).
However, I just found out that SUBDIRS is deprecated and so, replaced
it with ADD_SUBDIRECTORY. That's when I got an error about dir-A
not being a subdirectory. Obviously, I was not using SUBDIRS before
as it was intended... :-)
This error is caused by the fact that the directory dir-A is outside
the main directory tree, so dir-A's binary directory would likewise
be outside main's binary tree, and this is reasonably forbidden when
configuring main. You might specify dir-A's binary directory in
main/CMakeLists.txt explicitly, e.g.:
ADD_SUBDIRECTORY(../dir-A ${CMAKE_CURRENT_BINARY_DIR}/dir-A)
Hence, subprogA_ar will be built within the binary tree's dir-A.
I've also tried adding dir-A as a LINK_DIRECTORIES with no success.
It is unable to find subprogA_ar.
I'm not sure if it is possible, but ideally, when I run make in
main/, I would like it to rebuild the targets in dir-A (including
the archive) and link that in.
I'm also open to the possibility that I got the above organization all
wrong and should have only one large CMakeLists.txt in a directory
structure like this:
myproj
+-- main
+-- CMakeLists.txt
+-- source files for main program
+-- dir-A
+-- source files for sub-program A
+-- dir-B
+-- source files for sub-program B
Is this what I should have done??
As an alternative, consider to add a CMakeLists.txt in myproj
CMAKE_MINIMUM_REQUIRED(...)
PROJECT(myproj)
ADD_SUBDIRECTORY(dir-A)
ADD_SUBDIRECTORY(dir-B)
ADD_SUBDIRECTORY(main)
and subsequently, configure this directory instead of main.
Regards,
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] providing library information, what's the cmake way
On 11/29/2010 02:28 PM, Johannes Zarl wrote:
Sorry for the late response, but your mail was simply to long for a
swift response...
No problem, this topic is not exactly trivial.
On 11/26/2010 at 05:47, Michael Hertling mhertl...@online.de wrote:
On 11/24/2010 04:51 PM, Johannes Zarl wrote:
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 this mean that XXX_LIBRARIES etc. should normally incorporate the
settings for the components as well? [...]
Yes, of course, if FIND_PACKAGE(XXX ...) returns successfully one would
expect XXX_LIBRARIES to hold all libraries necessary to link against in
order to use all components enabled by the FIND_PACKAGE() invocation,
i.e. the libraries provided by the components themselves as well as
their prerequisites.
[...] IMO this can't work if you call
find_package several times with different components. [...]
This is one of those questions to deal with when it comes to multi-
component packages: Does FIND_PACKAGE(XXX ...) act accumulatively?
[...] Also, this would
make it impossible to link to the base library alone, i.e. without
the components...
One might consider the base library as a component by itself, perhaps
enabled automatically by resolving inter-component dependencies. As an
alternative, one could a priori populate XXX_LIBRARIES et al. with the
base library stuff and add the components' contributions as required.
Furthermore, a package doesn't need to have a dedicated base library,
e.g. Boost hasn't, and if you don't specify any components the
Boost_LIBRARIES variable remains empty.
- 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.
Thanks, I hadn't thought of this. So the code-snippet above should
contain a set ( XXX_${component}_FOUND ${component}-NOTFOUND ).
Yes, one would expect that FOUND variables for requested components
receive defined values in all cases - positive as well as negative.
Besides, it's a good style to refer to any
component-related variables only if the particular component has been
requested explicitly.
Ok, so a better style would be to only set the XXX_HAS_* variables at
first (maybe unsetting them at the end of the config file?), and then
to conditionally set the XXX_YYY_INCLUDE_DIRS etc. if XXX_YYY_FOUND
is true.
Here, I meant it is a good *user* style to rely only on variables
related to explicitly requested components; maybe a bit ambiguous.
- 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.
I don't really see this as a problem. Although the code at hand lacks
support for this kind of dependencies, in most cases you won't need it.
And if you as the config file writer
Re: [CMake] Problems to find xmlrpc_server_abyss++.so on FreeBSD
On 11/30/2010 12:27 AM, Renato Botelho wrote:
On Mon, Nov 29, 2010 at 9:20 PM, Renato Botelho rbga...@gmail.com wrote:
Hi,
It's the first project i'm migrating from autotools to cmake,
and it's going really well, in 4 days it's almost done. \o/
The only issue I have now is following, i have this code
on my CMakeLists.txt:
find_package (XMLRPC REQUIRED abyss-server c++2)
It's always the same, one entire day trying to figure it out and
5 seconds after sending this email i found, i just changed the
order of components (c++2 abyss-server) and it detected my
xmlrpc fine. It's fixed now. The other problem below still persists.
Ah, since i'm talking about FindXMLRPC, I used REQUIRED
param, like i showed above, but if it doesn't find xmlrpc
it shows an error message but don't stop, i needed to add
this:
if (NOT XMLRPC_FOUND)
message (FATAL_ERROR XMLRPC-C not found)
endif (NOT XMLRPC_FOUND)
Is it the expected behavior?
It persists
AFAICS, this is due to the last code snippet in FindXMLRPC.cmake:
# Report the results.
IF(NOT XMLRPC_FOUND)
SET(XMLRPC_DIR_MESSAGE
XMLRPC was not found. Make sure the entries XMLRPC_* are set.)
IF(NOT XMLRPC_FIND_QUIETLY)
MESSAGE(STATUS ${XMLRPC_DIR_MESSAGE})
ELSE(NOT XMLRPC_FIND_QUIETLY)
IF(XMLRPC_FIND_REQUIRED)
MESSAGE(FATAL_ERROR ${XMLRPC_DIR_MESSAGE})
ENDIF(XMLRPC_FIND_REQUIRED)
ENDIF(NOT XMLRPC_FIND_QUIETLY)
ENDIF(NOT XMLRPC_FOUND)
If XMLRPC_FOUND is FALSE the MESSAGE(FATAL_ERROR ...) is emitted only
if XMLRPC_FIND_REQUIRED is TRUE - that's OK - and XMLRPC_FIND_QUIETLY
is TRUE also - which is wrong. IMO, the REQUIRED flag must absolutely
take precedence over the QUIET flag, e.g.:
IF(NOT XMLRPC_FOUND)
IF(XMLRPC_FIND_REQUIRED)
MESSAGE(FATAL_ERROR ...)
ELSEIF(NOT XMLRPC_FIND_QUIETLY)
MESSAGE(STATUS ...)
ENDIF()
ENDIF()
This is the pattern used by FIND_PACKAGE_HANDLE_STANDARD_ARGS(), too.
As it's done currently in FindXMLRPC.cmake, you must enable REQUIRED
*and* QUIET to make the find module bail out *with* a message if the
package hasn't been found.
As a general interpretation of the REQUIRED flag, the user does not
want to check whether the package has been found if FIND_PACKAGE()
returns, or vice versa: If there is any need to check whether the
requested stuff is actually present, the REQUIRED flag is useless.
In particular, this should apply also to the components of multi-
component packages.
Feel encouraged to file a bug report.
Regards,
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] Relink on library rebuild dilema
On 11/29/2010 05:05 AM, Bill Hoffman wrote:
On 11/28/2010 3:19 AM, Sebastian Schaetz wrote:
Michael Hertlingmhertl...@... writes:
1) In the top-level CMakeLists.txt, you might say
SET_SOURCE_FILES_PROPERTIES(
main.cpp PROPERTIES OBJECT_DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/kernels/libkernel_executable.a
)
When libkernel_executable.a has changed, this results in recompiling
main.cpp - a penalty - and the desired relinking of main_target. If
main.cpp's recompilation is expensive you may possibly add an empty
cpp file to main_target's sources and impose the property on that.
Wow, those suggestions all sound great and I'm completely unfamiliar with
them
(so I think there's a good chance they will work). I will try them as soon as
possible! Thanks a lot for the suggestions.
No need for all the complication...
If you already know where the library is going to be:
${CMAKE_CURRENT_BINARY_DIR}/kernels/libkernel_executable.a
Then link directly to the full path:
target_link_libraries(main_target
${CMAKE_CURRENT_BINARY_DIR}/kernels/libkernel_executable.a)
Now the makefiles will depend on that file and it will relink when that
.a changes. This is why link_directories/*link_libraries without a
full path to the library is almost always a bad idea...
Oops, the simplest solution at all. ~8) Thanks for pointing it out, Bill.
Perhaps, this is a good opportunity to ask a related question: Some
time ago, there has been an issue with special linker scripts which
are part of a project. Of course, one would like to see the linker
triggered when these scripts change, and the best solution I have
found so far is - just like suggested to the OP -
- a dummy source file to impose the OBJECT_DEPENDS property on, or
- a dummy static library that is invalidated when the scripts change
and (mis)used to force a dependency of the link line on the scripts.
Both alternatives are not really satisfying, so I wonder if there is any
smarter and more direct possibility to establish a file-level dependency
of the link line on an arbitrary file that's not mentioned as a library
in TARGET_LINK_LIBRARIES(). For Makefiles, this involves just a single
additional line.
Regards,
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
