Re: [CMake] Visual Studio configurations with cmake
On 12/03/2011 12:31 PM, terje loe wrote:
Hi,
I'm trying to set up cmake for my visual studio project.. I' ve set it up so
it works fine for make files, but got some problems setting it up as I want
it for visual studio.
1.
I'm setting up different visual studio configurations so I have DebugOpenGL,
DebugDirectX, ReleaseOpenGL and ReleaseDirectX. And I want to set special
defines for eachof the configurations, USE_OPENGL, USE_DIRECTX , but I cant
figure out how to do it? I know for QMake you can do this:
!build_pass:addExclusiveBuilds(use_opengl, OpenGL , use_directx,
DirectX)build_pass {CONFIG(use_opengl,
use_opengl|use_directx):DEFINES+=USE_OPENGLelse:DEFINES+=USE_DIRECTX}
Is it possible to do something similar with cmake? Note that this is not the
normal debug/release flag you give to cmake, but different configurations in
visual studio.
This is how I set up the configurations:
if(CMAKE_CONFIGURATION_TYPES AND MSVC)set(CMAKE_CONFIGURATION_TYPES
DebugOpenGL;ReleaseOpenGL;DebugDirectX;ReleaseDirectX)
set(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES} CACHE STRING
Reset the configurations to what we need FORCE)
#DebugOpenGL flags set(CMAKE_CXX_FLAGS_DEBUGOPENGL /D_DEBUG /MDd /Zi
/Ob0 /Od /RTC1 CACHE STRING Flags used by the C++ compiler during
maintainer builds. FORCE) set(CMAKE_C_FLAGS_DEBUGOPENGL /D_DEBUG /MDd
/Zi /Ob0 /Od /RTC1 CACHE STRING Flags used by the C compiler during
maintainer builds. FORCE) set(CMAKE_EXE_LINKER_FLAGS_DEBUGOPENGL /debug
/INCREMENTAL CACHE STRING Flags used for linking binaries during maintainer
builds. FORCE ) set(CMAKE_SHARED_LINKER_FLAGS_DEBUGOPENGL /debug
/INCREMENTAL CACHE STRING Flags used by the shared libraries linker during
maintainer builds. FORCE )
#ReleaseOpenGL flagsset(CMAKE_CXX_FLAGS_RELEASEOPENGL /MD /O2 /Ob2
/D NDEBUG CACHE STRING Flags used by the C++ compiler during maintainer
builds. FORCE) set(CMAKE_C_FLAGS_RELEASEOPENGL /MD /O2 /Ob2 /D
NDEBUG CACHE STRING Flags used by the C compiler during maintainer builds.
FORCE) set(CMAKE_EXE_LINKER_FLAGS_RELEASEOPENGL /INCREMENTAL:NO CACHE
STRING Flags used for linking binaries during maintainer builds. FORCE )
set(CMAKE_SHARED_LINKER_FLAGS_RELEASEOPENGL /INCREMENTAL:NO CACHE STRING
Flags used by the shared libraries linker during maintainer builds. FORCE )
#DebugDirectX flags set(CMAKE_CXX_FLAGS_DEBUGDIRECTX
/D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 CACHE STRING Flags used by the C++
compiler during maintainer builds. FORCE)
set(CMAKE_C_FLAGS_DEBUGDIRECTX /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 CACHE
STRING Flags used by the C compiler during maintainer builds. FORCE)
set(CMAKE_EXE_LINKER_FLAGS_DEBUGDIRECTX /debug /INCREMENTAL CACHE STRING
Flags used fo
r linking binaries during maintainer builds. FORCE )
set(CMAKE_SHARED_LINKER_FLAGS_DEBUGDIRECTX /debug /INCREMENTAL CACHE STRING
Flags used by the shared libraries linker during maintainer builds. FORCE )
#ReleaseDirectx flags set(CMAKE_CXX_FLAGS_RELEASEDIRECTX /MD /O2
/Ob2 /D NDEBUG CACHE STRING Flags used by the C++ compiler during maintainer
builds. FORCE) set(CMAKE_C_FLAGS_RELEASEDIRECTX /MD /O2 /Ob2 /D NDEBUG
CACHE STRING Flags used by the C compiler during maintainer builds. FORCE)
set(CMAKE_EXE_LINKER_FLAGS_RELEASEDIRECTX /INCREMENTAL:NO CACHE STRING Flags
used for linking binaries during maintainer builds. FORCE )
set(CMAKE_SHARED_LINKER_FLAGS_RELEASEDIRECTX /INCREMENTAL:NO CACHE STRING
Flags used by the shared libraries linker during maintainer builds. FORCE
)endif()
SET_DIRECTORY_PROPERTIES(PROPERTIES
COMPILE_DEFINITIONS_DEBUGOPENGL USE_OPENGL
COMPILE_DEFINITIONS_RELEASEOPENGL USE_OPENGL
COMPILE_DEFINITIONS_DEBUGDIRECTX USE_DIRECTX
COMPILE_DEFINITIONS_RELEASEDIRECTX USE_DIRECTX
)
2.
I have been able to exclude .cpp files from the visual studio build by doing
this:
set_source_files_properties(${files}PROPERTIES HEADER_FILE_ONLY true)
But in visual studio you can right click a file- properties and select
exclude file from build.. this sets a red icon on the file. I want to do this
for sepereate configurations as in question 1.
http://www.mail-archive.com/cmake@cmake.org/msg38418.html
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] output of custom_command ?
On 12/01/2011 03:50 PM, Anders Wallin wrote:
Hi all,
I'm building some Lyx documentation with asymptote figures.
I'm generating the figures in EPS format like this:
add_custom_command(
OUTPUT ${ASYFIG}.eps
COMMAND asy ${CMAKE_CURRENT_SOURCE_DIR}/${ASYFIG}.asy
DEPENDS ${ASYFIG}.asy
)
and the the document in PDF format like this:
add_custom_command(
OUTPUT manual.pdf
COMMAND lyx --export pdf ${CMAKE_CURRENT_SOURCE_DIR}/manual.lyx
DEPENDS manual.lyx
)
I put all .asy source files and .lyx source files in one directory.
When I do an out-of-source build in e.g. /src/bld/ the .eps files
which are produced from the first
custom_command are put in CMAKE_CURRENT_BINARY_DIR
Two questions/problems:
1. the pdf file from the second custom_command gets placed in
CMAKE_CURRENT_SOURCE_DIR.
Why is that happening?
Refer to http://wiki.lyx.org/FAQ/ImportExport#cl:
... This will create the output file in
the same directory as the input file.
2.
Since the input of the second custom_command, and the .eps files are
now in different directories, lyx is not finding the EPS-files.
How could I have the second custom_command run in
CMAKE_CURRENT_BINARY_DIR so that the figures would be found
and the output pdf would be generated in CMAKE_CURRENT_BINARY_DIR ?
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/manual.pdf
COMMAND ${CMAKE_COMMAND} -E create_symlink
${CMAKE_CURRENT_SOURCE_DIR}/manual.lyx
${CMAKE_CURRENT_BINARY_DIR}/manual.lyx
COMMAND lyx --export pdf ${CMAKE_CURRENT_BINARY_DIR}/manual.lyx
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/manual.lyx)
Moreover, be aware of possible in-source-builds and non-symlink-aware
platforms, and definitely heed David's advice w.r.t. the dependencies.
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] FindDCMTK Not setting up DCMTK_INCLUDE_DIRECTORIES Correctly?
On 12/01/2011 08:22 AM, Thomas Sondergaard wrote:
On 2011-11-30 07:23, Michael Hertling wrote:
On 11/29/2011 08:49 PM, Thomas Sondergaard wrote:
On 2011-11-29 18:19, kent williams wrote:
I actually install DCMTK in a subdirectory of my top-level build, and
then my program that uses DCMTK is configured with DCMTK_DIR.
What is DCMTK_DIR pointing at? The installation dir or the source dir?
As you can see in the description of the string it is meant to point at
the root of the source directory.
A source tree beneath /usr/include? That's a very strange default, IMO.
Yes, that doesn't make a lot of sense.
The problem isnt MY source, the problem is that the DCMTK headers use
the dcmtk/x/y.h path form to include OTHER DCMTK headers.
That shouldn't be a problem as long as the headers are actually
available in a directory structure that matches that.
AFAICS, the problem isn't the subpath in the #include directives, but
the fact that FIND_PATH() in FindDCMTK.cmake doesn't return suitable
paths. E.g., if osconfig.h is included via dcmtk/config/osconfig.h,
FIND_PATH() must return the path up to but *excluding* dcmtk/config;
however, FindDCMTK.cmake has FIND_PATH() search for osconfig.h, so
it'll yield the header's full path *including* dcmtk/config. If this
is passed to INCLUDE_DIRECTORIES(), one will end up with -I.../dcmtk/
config, and beneath this path, dcmtk/config/osconfig.h can't be found,
i.e. the headers' inclusions among each other can't work in this way
unless the root of DCMTK's header tree is found by other means. The
DCMTK_dcmtk_INCLUDE_DIR variable nearly adds the crucial path to
DCMTK_INCLUDE_DIRS, but seems to keep one directory too much.
@Kent: Including headers by use of subpaths is not bad, IMO;
instead, it's rather clever, e.g. for the following reasons:
(1) It has an additional documentation effect because the #include
directive indicates which module the included header stems from.
(2) It separates the namespaces of the package's modules, so multiple
modules might have headers of the same name. In fact, this applies
to DCMTK as the djdecode.h header appears twice; how would you use
dcmtk/dcmjpls/djdecode.h and dcmtk/dcmjpeg/djdecode.h
within the same compilation unit without specifying their
respective subpath in the #include directive? You'd need to use
further measures like configured pseudo headers to accomplish this.
(3) It reduces the number of necessary -I switches, i.e. arguments to
INCLUDE_DIRECTORIES(), and that's particularly true for DCMTK. If
all of the package's headers and all client code consistently use
subpaths in the #include directives, you need just one single -I
switch per installed header tree, and DCMTK has only one, so it
would actually suffice to haveDCMTK_INSTALL_PREFIX/include
in DCMTK_INCLUDE_DIRS.
Due to the latter point, and as long as client code uses subpaths
for header inclusion, the FIND_PATH() command in FindDCMTK.cmake
for the population of DCMTK_INCLUDE_DIRS might be simplified to
FIND_PATH(DCMTK_DCMTK_INCLUDE_DIR dcmtk PATHS ${DCMTK_ROOT}/include)
MARK_AS_ADVANCED(DCMTK_DCMTK_INCLUDE_DIR)
IF(DCMTK_DCMTK_INCLUDE_DIR)
SET(DCMTK_INCLUDE_DIRS ${DCMTK_DCMTK_INCLUDE_DIR})
ENDIF()
with DCMTK_ROOT pointing at a DCMTK installation tree. If one wants to
still have individual DCMTK_*_INCLUDE_DIR variables, e.g. as indicators
if the installation is complete, one could retain the loop and possibly
invoke LIST(REMOVE_DUPLICATES DCMTK_INCLUDE_DIRS). In either case, the
headers should be denoted with subpaths. In order to have this work if
FindDCMTK.cmake is searching for a source tree, the PATHS need to be
modified a bit, but is there a special reason why this find module
should work with source trees, too? AFAIK, that's quite unusual.
On Windows some packages don't have an install target, so it is not
unusual. DCMTK does have one, so I agree that it is not necessary or
desirable for FindDCMTK. Cannot be removed now without the risk of
breaking some packages though.
If FindDCMTK.cmake is expected to work with a source tree containing an
in-source-build, it's OK as far as I'm concerned, but shouldn't it work
with an installation tree, too? Anyway, IMO, the actual issue is that
none of the include directories returned by FindDCMTK.cmake suits to
find a header if the latter is included with subpath - neither from a
source tree nor from an installation tree - and AFAICS, the inclusions
among DCMTK's headers are done with subpaths. So, how could a directive
#include dcmtk/config/osconfig.h
e.g., ever work if all include directories do contain the dcmtk part?
A possible approach to fix this issue while respecting source trees and
installation trees and without harming backward compatibility might be:
(1) Don't provide a default value for DCMTK_DIR as there simply isn't
one; /usr/include/dcmtk is totally wrong
Re: [CMake] 2D arrays
On 11/30/2011 03:29 AM, Robert Dailey wrote:
On Tue, Nov 29, 2011 at 5:57 PM, Michael Hertling mhertl...@online.dewrote:
Just some spontaneous questions/remarks:
Thanks; I really appreciate it!
- Why do you use macros instead of functions?
I use macros so the _array2d_ variables fall through the scope of the macro
and are available in the next call to array2d_advance(). I could use
functions + properties but this solution works, I saw no need to use the
slightly more verbose global properties feature.
What I've had in mind are functions and the PARENT_SCOPE option of SET().
- What's about cleaning up the numerous helper variables,
e.g. by an additional array2d_cleanup() function or the like?
What specific helper variables are you referring to? I would most likely
use more uniquely mangled local variables instead, but I figured the
preceeding underscore in front of each was sufficient. What would you
recommend here? I'd like to avoid a cleanup() method because it seems
unnecessary. If my local variables cause conflicts later, and if name
mangling isn't the idiomatic solution, I'd like to hear whatever idea you
have (that doesn't involve cleanup() if possible).
Because you must preserve some variables between multiple function/macro
invocations - i.e. you can't work with local variables only - one might
like to have a mean to purge these variables when their job is done in
order to not pollute the current scope more than necessary. Of course,
it's not absolutely indispensable, but if a set of non-local variables
is used just internally by a set of related functions, it is possibly
worth a thought how to not have these variables hang around later on.
- In array2d_begin_loop(), couldn't you rearrange the parameters,
array2d_begin_loop(advanced fruit;animal ${two_dee_array}), use
LIST(LENGTH var_names _array2d_width) and take ARGN as the array?
What would this buy me? Typically I've avoided ARGN unless it is absolutely
necessary, but a variable in this case seems more direct. Can you explain
what benefits this has?
AFAICS, you don't need the width parameter because it can be obtained
as the length of var_names. Thus, additionally specifying width is
error-prone; e.g. (width,var_names)=(3,fruit;animal) is inherently
invalid.
Using ARGN would allow the user to specify the array elements freely as
separate arguments at the end of array2d_begin_loop(), without the need
to pass them in as a semicolon-separated list in double quotes.
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] 2D arrays
On 11/30/2011 12:28 AM, Robert Dailey wrote:
I have created a pretty clean solution to this until there is native
support for multi-dimensional arrays in CMake. I have attached the module,
hopefully it will prove useful to others. Here is an example of how to use
it:
set( two_dee_array
apple cat
orange dog
banana elephant
)
array2d_begin_loop( advanced ${two_dee_array} 2 fruit;animal )
while( advanced )
message( Fruit: ${fruit} )
message( Animal: ${animal} )
array2d_advance()
endwhile()
-
Robert Dailey
Just some spontaneous questions/remarks:
- Why do you use macros instead of functions?
- What's about cleaning up the numerous helper variables,
e.g. by an additional array2d_cleanup() function or the like?
- In array2d_begin_loop(), couldn't you rearrange the parameters,
array2d_begin_loop(advanced fruit;animal ${two_dee_array}), use
LIST(LENGTH var_names _array2d_width) and take ARGN as the array?
Regards,
Michael
On Mon, Nov 28, 2011 at 2:31 PM, Robert Dailey rcdai...@gmail.com wrote:
Is it possible to have 2D arrays in CMake? As far as the core syntax is
concerned, it seems like only 1D arrays are supported. So far I've had to
work around this issue by using a flat array and skipping over elements
using foreach() with a range and step.
Any ideas? Thanks.
-
Robert Dailey
--
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] FindDCMTK Not setting up DCMTK_INCLUDE_DIRECTORIES Correctly?
On 11/29/2011 08:49 PM, Thomas Sondergaard wrote:
On 2011-11-29 18:19, kent williams wrote:
I actually install DCMTK in a subdirectory of my top-level build, and
then my program that uses DCMTK is configured with DCMTK_DIR.
What is DCMTK_DIR pointing at? The installation dir or the source dir?
As you can see in the description of the string it is meant to point at
the root of the source directory.
A source tree beneath /usr/include? That's a very strange default, IMO.
The problem isnt MY source, the problem is that the DCMTK headers use
the dcmtk/x/y.h path form to include OTHER DCMTK headers.
That shouldn't be a problem as long as the headers are actually
available in a directory structure that matches that.
AFAICS, the problem isn't the subpath in the #include directives, but
the fact that FIND_PATH() in FindDCMTK.cmake doesn't return suitable
paths. E.g., if osconfig.h is included via dcmtk/config/osconfig.h,
FIND_PATH() must return the path up to but *excluding* dcmtk/config;
however, FindDCMTK.cmake has FIND_PATH() search for osconfig.h, so
it'll yield the header's full path *including* dcmtk/config. If this
is passed to INCLUDE_DIRECTORIES(), one will end up with -I.../dcmtk/
config, and beneath this path, dcmtk/config/osconfig.h can't be found,
i.e. the headers' inclusions among each other can't work in this way
unless the root of DCMTK's header tree is found by other means. The
DCMTK_dcmtk_INCLUDE_DIR variable nearly adds the crucial path to
DCMTK_INCLUDE_DIRS, but seems to keep one directory too much.
@Kent: Including headers by use of subpaths is not bad, IMO;
instead, it's rather clever, e.g. for the following reasons:
(1) It has an additional documentation effect because the #include
directive indicates which module the included header stems from.
(2) It separates the namespaces of the package's modules, so multiple
modules might have headers of the same name. In fact, this applies
to DCMTK as the djdecode.h header appears twice; how would you use
dcmtk/dcmjpls/djdecode.h and dcmtk/dcmjpeg/djdecode.h
within the same compilation unit without specifying their
respective subpath in the #include directive? You'd need to use
further measures like configured pseudo headers to accomplish this.
(3) It reduces the number of necessary -I switches, i.e. arguments to
INCLUDE_DIRECTORIES(), and that's particularly true for DCMTK. If
all of the package's headers and all client code consistently use
subpaths in the #include directives, you need just one single -I
switch per installed header tree, and DCMTK has only one, so it
would actually suffice to have DCMTK_INSTALL_PREFIX/include
in DCMTK_INCLUDE_DIRS.
Due to the latter point, and as long as client code uses subpaths
for header inclusion, the FIND_PATH() command in FindDCMTK.cmake
for the population of DCMTK_INCLUDE_DIRS might be simplified to
FIND_PATH(DCMTK_DCMTK_INCLUDE_DIR dcmtk PATHS ${DCMTK_ROOT}/include)
MARK_AS_ADVANCED(DCMTK_DCMTK_INCLUDE_DIR)
IF(DCMTK_DCMTK_INCLUDE_DIR)
SET(DCMTK_INCLUDE_DIRS ${DCMTK_DCMTK_INCLUDE_DIR})
ENDIF()
with DCMTK_ROOT pointing at a DCMTK installation tree. If one wants to
still have individual DCMTK_*_INCLUDE_DIR variables, e.g. as indicators
if the installation is complete, one could retain the loop and possibly
invoke LIST(REMOVE_DUPLICATES DCMTK_INCLUDE_DIRS). In either case, the
headers should be denoted with subpaths. In order to have this work if
FindDCMTK.cmake is searching for a source tree, the PATHS need to be
modified a bit, but is there a special reason why this find module
should work with source trees, too? AFAIK, that's quite unusual.
I am doing exactly what you're doing, and if you don't have this
problem I'm interested in how you got it to work.
What does your DCMTK_INCLUDE_DIRS variable contain?
If directed against a DCMTK installation tree via CMAKE_PREFIX_PATH,
FindDCMTK.cmake leaves this variable empty whereas DCMTK_LIBRARIES is
correctly populated with the package's libraries. IMO, this indicates
that the find module doesn't work properly. One has to point DCMTK_DIR
- against its documented meaning - at the installation tree to get the
headers' full paths, but as already mentioned, this is unsuitable for
the inter-header inclusions. As a possible workaround, one might add
FIND_PATH(DCMTK_DCMTK_INCLUDE_DIR dcmtk PATHS ${DCMTK_ROOT}/include)
MARK_AS_ADVANCED(DCMTK_DCMTK_INCLUDE_DIR)
IF(DCMTK_DCMTK_INCLUDE_DIR)
LIST(APPEND DCMTK_INCLUDE_DIRS ${DCMTK_DCMTK_INCLUDE_DIR})
ENDIF()
to FindDCMTK.cmake, with or without a DCMTK_ROOT. In addition, one
would need to drop any other DCMTK_*_INCLUDE_DIR variable from the
FPHSA() call. In this manner, FIND_PACKAGE() would return the path
to the DCMTK installation's header tree, so that the inter-header
inclusions work after INCLUDE_DIRECTORIES(${DCMTK_INCLUDE_DIRS}).
Regards,
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Re: [CMake] Finding PythonLibs using PythonInterp
On 11/28/2011 03:54 PM, Felipe Lema wrote:
Hello, everyone
I was trying to use cmake to build python c++ extensions in win7, but
couldn't get cmake to detect PythonLibs. At least, not without editing the
windows registry. Since it could detect PythonInterp, I got it working
using the directories provided from methods inside the interpreter.
-- code snippet --
execute_process(COMMAND ${PYTHON_EXECUTABLE} -c import sys;from
distutils.sysconfig import
get_python_inc;sys.stdout.write(get_python_inc())
OUTPUT_VARIABLE PYTHON_INCLUDE_DIRS
ERROR_VARIABLE ERROR_FINDING_INCLUDES)
execute_process(COMMAND ${PYTHON_EXECUTABLE} -c import sys;from
numpy.distutils.numpy_distribution import NumpyDistribution;from
numpy.distutils.command.build_ext import
build_ext;a=build_ext(NumpyDistribution());a.ensure_finalized();sys.stdout.write(';'.join(a.library_dirs))
OUTPUT_VARIABLE PYTHON_LIBRARIES_DIR
ERROR_VARIABLE ERROR_FINDING_LIBRARIES)
-- /code snippet --
These directories can be used later for finding the python .lib files and
version number, as cmake currently does (although using the directories
from the windows registry)
The only setback (at least for finding the python lib files) is that the
user must have numpy correctly installed with the found interpreter.
Haven't tried it, but there should be a way to get it to work without numpy
installed.
In spite of the latest, I still think that this code is very useful.
PS=Just in case, the python script embedded in the execute_process args
should be a single line
The main drawback of your approach is that one has to invoke the Python
interpreter which is probably not acceptable in certain cross-compiling
scenarios. There've been several discussions about improvements of the
FindPython*.cmake modules, see [1,2], and the consensus is, IIRC, that
there should be one comprehensive and component-aware FindPython.cmake
module, knowing at least the components interpreter and libraries
and ensuring that both are consistent w.r.t. their version. Moreover,
the said module should allow the user to specify the desired version
via FIND_PACKAGE()'s respective interface, but the prevalent obstacle
in this regard is the FIND_*() commands' current inability to look for
patterns, e.g. FIND_PROGRAM() cannot search for python[0-9]+\.[0-9]+.
IMO, addressing these issues should be preferred to pouring resources
into those rather outmoded FindPython{Interp,Libs}.cmake find modules.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg30086.html
[2] http://www.mail-archive.com/cmake@cmake.org/msg29487.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] BUILD_COMMAND having a hard time getting usable command lines
On 11/28/2011 08:43 PM, J Decker wrote:
So the idea was, to make the build process a single click (or couple)
or at least a single application to build. Since CMake knows how to
build a project, it became easier to maintain a cmakelists.txt which
does the build than a batch file...
So my top most level project now is a series of targets which do a
build and an install and possibly additional commands between each
target. (Some project have deploy commands that build other scripts
that get used later in the build).
By adding some options to do the build command at the end of the
script (especially if those options default as off) I figured I could
trigger a build.
Yes; If I do 'cmake -G 'SomeGenerator' -DGENERATOR_BUILD_ALL_NOW=1'
then in a clean directory, this fails to actually to the build,
repeating this command allows the project build to commence.
If I don't use the command line with the custom knowledge that things
exist in a cmakelists; and I use 'cmake-gui' then point it at the
sources, click 'configure' and the options are read, and hmm I guess I
could still just configure and not generate and set the build now
option; then the build can happen automatically from just knowing
cmake, not the environment specific mingw32-make.exe or wmake or
devenv or whatever
(1) Build the following project from the VS command prompt:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BUILD C)
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES
COMPILE_DEFINITIONS NUMBER=1)
/* main.c: */
#include stdio.h
int main(void)
{
printf(%d\n,NUMBER); return 0;
}
Now, set NUMBER to 2 in the CMakeLists.txt file and rebuild with
cmake --build, so in the end, you do the same as the command line
returned by BUILD_COMMAND() would do. You'll see that the project is
reconfigured but not rebuilt although the modified COMPILE_DEFINITIONS
effect the executable. That's because a touched .vcproj file obviously
doesn't have VC rebuild the associated targets. Of course, this isn't
caused by your building-while-configuring approach, but the latter
makes it harder to account for inconveniences of that kind.
(2) Configure the following project from the CMake GUI:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(THREETIMES C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
OPTION(OPTION_X Option X OFF)
IF(OPTION_X)
OPTION(OPTION_Y Option Y OFF)
ENDIF()
IF(OPTION_Y)
OPTION(OPTION_Z Option Z OFF)
ENDIF()
After the second run, when there are no more red entries in the cache
window, check the OPTION_X box, reconfigure and the OPTION_Y box will
appear. Check it and reconfigure to see the OPTION_Z box. In order to
enable OPTION_{X,Y,Z}, you have to reconfigure three times, see [1,2]
for more information. In general, you must be prepared to reconfigure
an arbitrary number of times till you reach the desired configuration.
You would definitely not want to rebuild the project each time.
(3) It's even possible to cause a, say, configuration loop:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(LOOP C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
OPTION(LOOP Option LOOP OFF)
IF(LOOP)
UNSET(LOOP CACHE)
ELSE()
SET(LOOP ON CACHE BOOL Option LOOP FORCE)
ENDIF()
Configure the project multiple times from the CMake GUI and you will
see that the cache doesn't stabilize; instead, it oscillates between
two states. Of course, this example is pathological but proves that
the cache might generally traverse a cycle of states - one step per
reconfiguration - and only the user can know which state is the
desired one. You would definitely not want... see above.
The essence is: Even if your approach worked from within the CMake GUI,
it might have serious conceptional drawbacks, depending on the project,
so you should heed David's counsel and simply not pursue it, IMO.
Regards,
Michael
[1] http://www.cmake.org/cmake/help/runningcmake.html
[2] http://www.mail-archive.com/cmake@cmake.org/msg31287.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] Capturing matches in regex groups
On 11/28/2011 11:35 PM, Robert Dailey wrote:
I haven't really seen a way to get a list of group matches in a regex. For
example, string( REGEX MATCH ) only returns the whole string matched, not
just what was in the capture groups. If I do this:
(\\w+)\\,(\\w+)\\,(\\w+)
and I match that regex against this string:
hello,world,today
I should get a list with:
hello;world;today
How can I do this?
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(REGEXREPLACE NONE)
STRING(REGEX REPLACE
([A-Za-z0-9_]+),([A-Za-z0-9_]+),([A-Za-z0-9_]+)
\\1;\\2;\\3 RESULT hello,world,today)
LIST(LENGTH RESULT n)
MESSAGE(n=${n})
FOREACH(i IN LISTS RESULT)
MESSAGE(${i})
ENDFOREACH()
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] BUILD_COMMAND having a hard time getting usable command lines
On 11/26/2011 07:14 PM, J Decker wrote:
Earlier I wondered if there was a way to stop recusive invocation of a
build command in a cmake script - I found something like a solution;
when I run the command, set an environment variable and don't run the
command if that environment variable is set... But...
If I specify 'TARGET' in BUILD_COMMAND, then it gets extra quotes
around it, which make it impossible to pass to execute_process. Also
why doesn't cmake-gui run certain commands?
--example - probably incomplete ---
PROJECT( whatever )
build_command( GENERATOR_BUILD_COMMAND CONFIGURATION
${CMAKE_BUILD_TYPE} PROJECT_NAME ${PROJECT_NAME} TARGET all )
message( build command:${GENERATOR_BUILD_COMMAND} )
- output ---
build command:e:/tools/unix/mingw/bin/mingw32-make.exe -i all
mingw32-make.exe: *** No rule to make target `all'. Stop.
What happens if you omit the TARGET clause in BUILD_COMMAND()?
Target all should be the default when nothing is specified.
---end output, begin explanation
In order to get BUILD_COMMAND output to work at all I have to
STRING( REPLACE \ ; GENERATOR_BUILD_COMMAND
${GENERATOR_BUILD_COMMAND} )
AFAIK, that's exactly the job of SEPARATE_ARGUMENTS().
which replaces the spaces in the command with semicolons, so it looks
like seperate commands for
EXECUTE_PROCESS(COMMAND ${GENERATOR_BUILD_COMMAND}
WORKING_DIRECTORY ${CMAKE_BINARY_DIR} )
and in cmake-gui the output looks something like
---
build command:e:/tools/unix/mingw/bin/mingw32-make.exe -i all
Executing command... (output just before Execute_process)
Configuring done
---
but the command is never actually executed? I go out to a command
line and type cmake . and the build goes.
I can confirm this, but if I understand correctly, you are trying
to build the project while it still undergoes its configuration, in
particular before the generation step has finished. If so, wouldn't
you expect quite strange behaviors? Could you provide a small and
self-contained example which demonstrates what you intend to do?
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] parallel build using cmake --build?
On 11/27/2011 05:21 PM, Steve M. Robbins wrote: On Sat, Nov 26, 2011 at 10:46:10AM -0500, John Drescher wrote: On Fri, Nov 25, 2011 at 10:16 PM, Steve M. Robbins st...@sumost.ca wrote: Hi, To build VTK on our windows build server, I wrote a small batch script that invokes cmake --build. My developer machine is multicore; is there a way to get cmake --build to run multiple jobs? On windows, I use the following tool http://www.codeproject.com/KB/cpp/runjobs.aspx to build each configuration (Debug, Release, RelWithDebInfo ...) in parallel using separate calls to cmake --build. Thanks -- that's great tip. In my present case, however, I'm building just the Release configuration and was hoping to parallelize that with the equivalent of make -jN. IIRC, cmake --build once invoked MSBuild in a VS environment, and MSBuild has the /maxcpucount option, see [1]. Have you already tried to achieve something similar with the VS2010 devenv-based mechanism? To Michael Hertling's comment: cmake --build is just a front-end for the native build tool CMake generates input for. If this tool can be invoked via the command line with options for parallel building, you can provide them after the -- in the cmake --build command, e.g. cmake --build bindir -- -j 4 for parallel building with Makefiles. I would do this if I were using makefiles. In the present case, I'm using Microsoft VS2010. I was kind of hoping that cmake had abstracted the parallelism so that I could stay ignorant of the Visual Studio command line details and possibly in future write build scripts that are cross-platform. Are configured build scripts an option? As a project knows for which build tool it is configured, it should be able to generate a build- tool-independent build script for itself. Regards, Michael [1] http://msdn.microsoft.com/en-us/library/ms164311.aspx -- 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] parallel build using cmake --build?
On 11/26/2011 04:16 AM, Steve M. Robbins wrote: Hi, To build VTK on our windows build server, I wrote a small batch script that invokes cmake --build. My developer machine is multicore; is there a way to get cmake --build to run multiple jobs? Thanks, -Steve cmake --build is just a front-end for the native build tool CMake generates input for. If this tool can be invoked via the command line with options for parallel building, you can provide them after the -- in the cmake --build command, e.g. cmake --build bindir -- -j 4 for parallel building with Makefiles. 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] Do not build/install import library
On 11/25/2011 10:22 AM, Matthias Gehre wrote:
2011/11/25 Michael Hertling mhertl...@online.de:
On 11/24/2011 07:53 PM, Mathias Gaunard wrote:
On 11/23/2011 10:14 PM, Matthias Gehre wrote:
Hi,
thanks for this very nice cmake. I switched just recently to get
lightspark (lightspark.github.com)
crossplatform, and it worked really smooth.
One question, though: I cannot seem to find a way to _not_
build/install the import libraries (foobar.dll.a) on win32.
I do not need them, because I'm using MinGW's direct linking feature.
All I found was ways to
rename it, but not to keep it from building.
Use the MODULE type of library
CMake does not allow to link against a library of type MODULE.
ATM, I don't know if one can prevent the import libraries from being
built without modifying the platform files or rewriting the affected
rule variables; it seems as if --out-implib is present anywhere. In
order to prevent them from being installed, it should be sufficient
to drop the ARCHIVE DESTINATION clause from the INSTALL() command
for the concerned targets.
Thanks!
I'm now using the following snippet to install the *.so on linux and just the
dll on win32. Looks a bit hackish, though.
ADD_LIBRARY(spark SHARED ${LIBSPARK_SOURCES})
...
#We have to use LIBRARY on linux, but that installs the import library on
win32
No, the .so is indeed a LIBRARY on *nix, but the .dll is a RUNTIME on
Windows, and the import library is an ARCHIVE, so it's sufficient to
just drop the ARCHIVE DESTINATION to prevent the latter from being
installed.
IF(WIN32)
INSTALL(TARGETS spark RUNTIME DESTINATION ${PRIVATELIBDIR})
ELSE()
INSTALL(TARGETS spark LIBRARY DESTINATION ${PRIVATELIBDIR})
ENDIF()
Try
INSTALL(TARGETS spark
RUNTIME DESTINATION ...
LIBRARY DESTINATION ...
)
without an ARCHIVE DESTINATION; it's less hackish and should work, 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] Checking for empty list
On 11/25/2011 03:15 PM, Michael Wild wrote:
On 11/25/2011 02:52 PM, Daniel Dekkers wrote:
Hi,
I know it should be out there somewhere in the documentation, but can’t
find it.
How do I check for an empty list?
I can use LIST(LENGTH MYLIST LISTCOUNT) with an extra variable LISTCOUNT
but isn’t there a single command?
Thanks,
Daniel
An empty list is an empty variable, and evaluates to FALSE. So you can use
if(NOT MYLIST)
message(Either MYLIST is empty or otherwise FALSE)
endif()
...or otherwise FALSE: Exactly, and due to this, it's not bullet-proof:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(EMPTY NONE)
SET(MYLIST FALSE)
LIST(LENGTH MYLIST n)
MESSAGE(Length of MYLIST: ${n})
IF(MYLIST)
MESSAGE(IF() says MYLIST is not empty.)
ELSE()
MESSAGE(IF() says MYLIST is empty.)
ENDIF()
Because of non-empty strings - constituting non-empty lists - which
evaluate to FALSE in the IF() command, the only really safe way to
check whether a list is empty is using LIST(LENGTH ...), AFAICS.
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] Why does CMake use relative linking when I replace a shared object?
On 11/25/2011 12:28 PM, Mathias Gaunard wrote:
There is some strange CMake behaviour I don't quite understand.
In the project attached, I build a shared library for which I want to
specify a custom build command; to do this I generate a dummy library
which I then replace by another file in a POST_BUILD command
(alternatives involving imported libraries do not work properly across
different scopes).
If I do not replace the library, then the executable correctly links
against libtest.so.
If I do, it links instead with ../baz/libtest.so (sic), which of course,
fails when trying to run the program.
Why is it putting a relative path into my executable? Why is it
different depending on whether I replace the .so by another one or not?
Thank you very much for any insight on what's happening.
That's caused by the absence of an SONAME in your baz/libtest.so. If
there's no DT_SONAME tag in a shared library you are linking against,
the linker will write a DT_NEEDED tag to the resulting binary which
points to the library as it has been specified in the linker command
line, i.e. ../baz/libtest.so in your case; examine with readelf -d.
Then, of course, libtest.so can be found only if the search starts in
the appropriate directories, e.g. in bar since it's a sibling of baz:
cd bar ./foo works. If there is an DT_SONAME tag in the library,
the linker uses this to set the DT_NEEDED tag in the resulting binary,
and CMake places an SONAME in each shared library by default, even if
the VERSION/SOVERSION property isn't specified. See [1] for a related
discussion. If you really want to create a shared library by yourself,
do it right, e.g. with
COMMAND g++ -shared ${CMAKE_CURRENT_SOURCE_DIR}/dummy.cpp
-o ${CMAKE_CURRENT_BINARY_DIR}/test.so
-Wl,-soname,libtest.so
-fPIC
and note that PRE_BUILD is actually PRE_LINK for Makefiles,
LIBRARY_OUTPUT_PATH has been obsolete for a long time, and
the LINK_DIRECTORIES() command means asking for trouble.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg33482.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] Why does CMake use relative linking when I replace a shared object?
On 11/25/2011 08:42 PM, Mathias Gaunard wrote: On 11/25/2011 07:19 PM, Michael Hertling wrote: That's caused by the absence of an SONAME in your baz/libtest.so. If there's no DT_SONAME tag in a shared library you are linking against, the linker will write a DT_NEEDED tag to the resulting binary which points to the library as it has been specified in the linker command line, i.e. ../baz/libtest.so in your case; examine with readelf -d. Then, of course, libtest.so can be found only if the search starts in the appropriate directories, e.g. in bar since it's a sibling of baz: cd bar ./foo works. If there is an DT_SONAME tag in the library, the linker uses this to set the DT_NEEDED tag in the resulting binary, and CMake places an SONAME in each shared library by default, even if the VERSION/SOVERSION property isn't specified. See [1] for a related discussion. If you really want to create a shared library by yourself, do it right, e.g. with Thank you very much for the information. I had no idea shared objects had that kind of behaviour. and note that PRE_BUILD is actually PRE_LINK for Makefiles, I know, just using PRE_BUILD because it looks better when compared to POST_BUILD. LIBRARY_OUTPUT_PATH has been obsolete for a long time, and the LINK_DIRECTORIES() command means asking for trouble. I was wondering if those variables could be affecting the base directory used in the RPATH or other so-related things. They do, but for DT_NEEDED tags containing a /, the runtime linker ignores rpath settings - i.e. the DT_RPATH tags generated by -rpath options when the binary has been created. Therefore, the DT_NEEDED tag ../baz/libtest.so is used immediately without referring to any DT_RPATH tags incorporated in the same binary. [1] http://www.mail-archive.com/cmake-wChDC6UyXvPYtjvyW6yDsg@public.gmane.org/msg33482.html Doesn't seem to work :( Strange, the ML archives have it right. One more try: http://www.mail-archive.com/cmake@cmake.org/msg33482.html 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] XCode: Detect debug build to enable /D_Debug or similar?
On 11/24/2011 07:08 PM, g...@novadsp.com wrote:
How can I do this? Specifically generating for XCode.
My cmakefile has this:
if (${CMAKE_CFG_INTDIR} STREQUAL Debug)
Message(We are generating/building debug code for ${this_target})
ADD_DEFINITIONS(/D_DEBUG)
endif()
But _DEBUG is never defined.
This question comes up twice on StackOverflow. Both answers are
endlessly mutually referential ...
Thx++
SET_DIRECTORY_PROPERTIES(PROPERTIES COMPILE_DEFINITIONS_DEBUG _DEBUG)
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] Bad documentation of the LINK_INTERFACE_LIBRARIES property and other transitive linking topics
On 11/24/2011 08:20 AM, Hendrik Sattler wrote: BTW: linking plugins against an executable is really not good style. Put the common part into a library and link the executable and the plugin against that library. Ignore the necessity or desire to load the plugin at run time for a moment. Then, if the plugin or the common part in the executable are candidates for being designed as ordinary shared libraries anyway, I would agree. However, if both criteria do not apply, i.e. neither the plugin nor the common part would be realized as a shared library with- out the requirement to load the plugin at run time, I'd consider both as integral parts of the executable and, thus, export the symbols of the common part and link the shared object of the plugin against the executable. Of course, that's just my personal opinion, and it's no technically or otherwise coercive reason. 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] Do not build/install import library
On 11/24/2011 07:53 PM, Mathias Gaunard wrote: On 11/23/2011 10:14 PM, Matthias Gehre wrote: Hi, thanks for this very nice cmake. I switched just recently to get lightspark (lightspark.github.com) crossplatform, and it worked really smooth. One question, though: I cannot seem to find a way to _not_ build/install the import libraries (foobar.dll.a) on win32. I do not need them, because I'm using MinGW's direct linking feature. All I found was ways to rename it, but not to keep it from building. Use the MODULE type of library CMake does not allow to link against a library of type MODULE. ATM, I don't know if one can prevent the import libraries from being built without modifying the platform files or rewriting the affected rule variables; it seems as if --out-implib is present anywhere. In order to prevent them from being installed, it should be sufficient to drop the ARCHIVE DESTINATION clause from the INSTALL() command for the concerned 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] link_directories issue, cmake 2.8.5
On 11/23/2011 05:39 PM, Vladimir Chebotarev wrote: Hello. I've just found an issue with link_directories and cmake 2.8.5. If I give an absolute but not normalized path like c:/bla-bla-bla/../bla/bla as its argument (with default CMP0015), cmake thinks it is relative path and shows a warning about explicitly undefined policy. Also it normalizes path making it relative and actually makes a mistake during that, so the final VC project can't find the path to library. Take that path, use it to fully specify the library's location and eliminate LINK_DIRECTORIES() from your project, cf. [1]. Then, if things still don't work, report anew on the persisting problems. Regards, Michael [1] http://www.mail-archive.com/cmake@cmake.org/msg39264.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] Bad documentation of the LINK_INTERFACE_LIBRARIES property and other transitive linking topics
On 11/23/2011 10:25 AM, Alan W. Irwin wrote:
cmake-2.8.6 has the following documentation of the
LINK_INTERFACE_LIBRARIES property for targets:
LINK_INTERFACE_LIBRARIES
List public interface libraries for a shared library or executable.
By default linking to a shared library target transitively links to
targets with which the library itself was linked. For an executable
with exports (see the ENABLE_EXPORTS property) no default transitive
link dependencies are used. This property replaces the default
transitive link dependencies with an explicit list. When the target
is linked into another target the libraries listed (and recursively
their link interface libraries) will be provided to the other target
also. If the list is empty then no transitive link dependencies will
be incorporated when this target is linked into another target even if
the default set is non-empty. This property is ignored for STATIC
libraries.
I believe the reference to executables above is just plain
wrong/misleading. For example, the FAQ states that
LINK_INTERFACE_LIBRARIES simply lists the libraries that should be
transitively included in the link by CMake with the clear implication
(also confirmed by experiment below) that this target property affects
_everything that links to the target whose property is being set_.
But nothing links to an executable so why are executables mentioned at
all?
Michael has already mentioned the ENABLE_EXPORTS property; see the
following project for a typical example regarding plugins on *nix:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(EXPORTS C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS )
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c
#include dlfcn.h
#include stdio.h
void internal(void){printf(\internal()\\n\);}
int main(void)
{
void *p=dlopen(\./libplugin.so\,RTLD_NOW);
void (*f)(void)=dlsym(p,\external\);
f();
}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main dl)
SET_TARGET_PROPERTIES(main PROPERTIES
ENABLE_EXPORTS TRUE)
FILE(WRITE ${CMAKE_BINARY_DIR}/plugin.c
void external(void){internal();}\n)
ADD_LIBRARY(plugin MODULE plugin.c)
TARGET_LINK_LIBRARIES(plugin main)
The plugin provides the function external() that calls the function
internal() which is in turn defined in the main executable. If the
latter is linked without the -Wl,--export-dynamic switch - enabled
by ENABLE_EXPORTS - it simply won't run because internal()'s symbol
can not be found by the plugin. However, on ELF platforms, linking
against executables doesn't require to change the link command, but
the TARGET_LINK_LIBRARIES() command constrains the activation of the
ENABLE_EXPORTS property on the executable, so you can't accidentally
forget to export symbols from an executable when a plugin needs them.
Disable TARGET_LINK_LIBRARIES(plugin ...) and SET_TARGET_PROPERTIES()
to see it fail. Thus, one can very well link against an executable -
possibly only, say, formally - so it's not pointless to mention an
executable in a target's LINK_INTERFACE_LIBRARIES property.
Note the following remarks:
(1) For GCC on Linux, CMake adds -rdynamic a.k.a. -Wl,--export-dynamic
to an executable's link command line automatically, cf. the comment in
Modules/Platform/Linux-GNU.cmake, so CMAKE_SHARED_LIBRARY_LINK_C_FLAGS
must be emptied in the above-noted example to see the related effects.
(2) For the ENABLE_EXPORTS property, CMake's documentation states: On
all platforms a target-level dependency on the executable is created
for targets that link to it. AFAICS, this is not true for ELF plat-
forms: If one touches main.c and rebuilds, only the main target is
rebuilt but not the plugin. That's no harm because rebuilding the
executable wouldn't have any effect on the plugin, but perhaps,
the documentation should be fixed in this regard.
Here is the background for why I am looking into using this property:
I am told by Orion Poplawski (the guy who packages PLplot for Fedora)
that rpmlint warns whenever Linux libraries are overlinked
(presumably because that overlinking brings in unneeded rpm library
dependencies). I have confirmed for one PLplot library where he gave
the detailed warning messages, that ldd -u lists exactly the same
unused direct dependencies as rpmlint. These rpmlint and ldd -u
warnings are the direct result of the default transitive linking for
shared libraries used in CMake.
So I have been investigating how to avoid transitive linking for
shared libraries by consulting the CMake FAQ, cmake man page, and
previous threads on this list that have transitive in the subject
line. Apparently you are supposed to create an empty
LINK_INTERFACE_LIBRARIES target property. However, it is not clear
anywhere which target(s) in a chain of direct dependencies should have
an empty LINK_INTERFACE_LIBRARIES property.
Here is a test
Re: [CMake] Transitive linking
On 11/19/2011 08:02 AM, James Bigler wrote:
On Fri, Nov 18, 2011 at 5:51 PM, Michael Hertling mhertl...@online.dewrote:
On 11/18/2011 10:03 PM, James Bigler wrote:
2011/11/18 Alexander Neundorf a.neundorf-w...@gmx.net
On Friday 18 November 2011, James Bigler wrote:
I thought CMake knew how to not drag all the dependent libraries once
you
linked an executable module.
add_library(A STATIC a.cpp)
add_library(B SHARED b.cpp)
target_link_libraries(B A)
add_library(C SHARED c.cpp)
target_link_libraries(C B)
add_executable(run run.cpp)
target_link_libraries(run C)
At this point I'm seeing that C links against B and A when I think it
should only link against B since A shouldn't be needed to link against
B.
In addition when compiling run, it links against B and A.
/usr/bin/c++ -dynamiclib -Wl,-headerpad_max_install_names -o
libC.dylib
-install_name
/Users/jbigler/tmp/code/cmake/translinking/build/libC.dylib
CMakeFiles/C.dir/c.cpp.o libB.dylib libA.a
/usr/bin/c++-Wl,-search_paths_first
-Wl,-headerpad_max_install_names
CMakeFiles/run.dir/run.cpp.o -o run libC.dylib libB.dylib libA.a
Is this the expected behavior?
Yes.
If you want to limit this, use target_link_libraries( C
LINK_INTERFACE_LIBRARIES ... ), with this you can specify the
transitively
linked libraries when linking against C.
Alex
OK, so propagating the libraries is the default behavior. I tried to use
LINK_INTERFACE_LIBRARIES, but it only seemed to work for static
libraries:
add_library(A STATIC a.cpp)
add_library(B SHARED b.cpp)
target_link_libraries(B A)
target_link_libraries(B LINK_INTERFACE_LIBRARIES)
add_library(C SHARED c.cpp)
target_link_libraries(C B)
target_link_libraries(C LINK_INTERFACE_LIBRARIES)
add_executable(run run.cpp)
target_link_libraries(run C)
During build:
Build B (this is fine)
/usr/bin/c++ -dynamiclib -o libB.dylib CMakeFiles/B.dir/b.cpp.o libA.a
Build C (this is fine too, no A in the list)
/usr/bin/c++ -dynamiclib -o libC.dylib CMakeFiles/C.dir/c.cpp.o
libB.dylib
Build run (this is weird, it linked both B and C)
/usr/bin/c++CMakeFiles/run.dir/run.cpp.o -o run libC.dylib
libB.dylib
Did I specify something wrong or does this property only consider static
libraries?
On *nix, I can't confirm this:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(TRANSLINK CXX)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/a.cxx void a(){}\n)
ADD_LIBRARY(A STATIC a.cxx)
FILE(WRITE ${CMAKE_BINARY_DIR}/b.cxx void b(){}\n)
ADD_LIBRARY(B SHARED b.cxx)
TARGET_LINK_LIBRARIES(B A)
TARGET_LINK_LIBRARIES(B LINK_INTERFACE_LIBRARIES)
FILE(WRITE ${CMAKE_BINARY_DIR}/c.cxx void c(){}\n)
ADD_LIBRARY(C SHARED c.cxx)
TARGET_LINK_LIBRARIES(C B)
TARGET_LINK_LIBRARIES(C LINK_INTERFACE_LIBRARIES)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.cxx int main(){}\n)
ADD_EXECUTABLE(main main.cxx)
TARGET_LINK_LIBRARIES(main C)
The main target's link command line reads:
.../c++ .../main.cxx.o -o main ... libC.so ... # No libB.so!
Do you actually get different results with the above-noted project?
In general, CMake's transitive handling of target dependencies causes
no harm since no library is loaded unnecessarily, although there may be
libraries which are specified unnecessarily. E.g., main would be linked
against libB.so without immediately referring to the latter, i.e. it is
formally overlinked, but whether libB.so is loaded on behalf of main or
on behalf of libC.so does not matter, and overlinking w.r.t. a static
library is not possible. Do you have particular requirements why you
want to reduce a target's references to the immediate dependencies?
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
I tried your script, and it seems to exhibit the same behavior as my script:
/usr/bin/c++-Wl,-search_paths_first -Wl,-headerpad_max_install_names
CMakeFiles/main.dir/main.cxx.o -o main libC.dylib libB.dylib
Perhaps this is some Mac specific behavior that isn't showing up on other
systems.
The main reason I wanted it was to prevent build failures. I specified a
library path (-L) in one subdirectory to correctly link in the set of
external static libraries. CMake tried to drag those libraries on to the
next project which didn't have the library path and link failed. This is
why I started to look into why those static libraries were linked in the
first place. As far as I'm concerned once you link an executable module,
you don't need its dependencies anymore. Those dependencies should be
satisfied within the library itself. I'm not exactly sure why CMake
implements this behavior by default, since it seems to go against
Re: [CMake] One project, one platform, 2 compilers
On 11/18/2011 06:17 PM, Paul Hansen wrote:
Thank you very much for the answers, David and Michael.
I am trying to get a QNX compiler to work with CMake. My host comp runs
Ubuntu.
I did:
cmake -G Unix Makefiles -D CMAKE_C_COMPILER=qcc -D CMAKE_CXX_COMPILER=QCC
..
but get
dpkg-architecture: warning: Couldn't determine gcc system type, falling
back to default (native compilation)
cc: unknown option: '-dumpmachine'
I have of course google'd and found out that I probably have to make a new
toolchain file.
Does that seem correct?
Yes, it does.
qcc is basicly gcc with modifications and other libraries.
Is there an example toolchain file I can use as basis?
Is there any documentation about what should be set up in a toolchain file?
http://www.cmake.org/Wiki/CMake_Cross_Compiling and the ML, of course.
Regards,
Michael
On Fri, Nov 18, 2011 at 2:26 PM, Michael Hertling mhertl...@online.dewrote:
On 11/17/2011 05:18 PM, Paul Hansen wrote:
Hi
I have a project that has to be compiled with two different compilers on
the same computer.
Can I do that from the same CMakeLists.txt file?
What do you mean exactly?
(1) Compile the project twice, each time completely with a different
compiler? If so, use two different build trees, as already outlined
in the meantime.
(2) A part of your project must be compiled with a different compiler
than the remaining parts? Difficult - besides a custom-command-based
approach, you might outsource the concerned part and reintegrate it
as an external project which can be configured independently with a
different toolchain. Look at the following example:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(MAIN C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(SUBCC ${CMAKE_C_COMPILER} CACHE FILEPATH Subproject C compiler)
INCLUDE(ExternalProject)
ExternalProject_Add(sub
SOURCE_DIR ${CMAKE_SOURCE_DIR}/sub
CMAKE_CACHE_ARGS
-DCMAKE_C_COMPILER:FILEPATH=${SUBCC}
-DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}/sub)
ADD_LIBRARY(f SHARED IMPORTED)
SET_TARGET_PROPERTIES(f PROPERTIES
IMPORTED_LOCATION ${CMAKE_BINARY_DIR}/sub/lib/libf.so)
ADD_DEPENDENCIES(f sub)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main f)
ADD_DEPENDENCIES(main f)
sub/CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(SUB C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(f SHARED f.c)
INSTALL(TARGETS f LIBRARY DESTINATION lib)
Configure with the desired SUBCC to see the subproject being built with
that instead of the overall project's C compiler. The downside is that
you can't use FIND_*() on the subproject's targets since they're built
after the overall project is already configured, so you must predict
their locations. Additionally, there may be issues w.r.t. the correct
handling of dependencies. Moreover, if the subproject is to share the
overall project's cache, you need to pass the concerned variables to
ExternalProject_Add() individually, or do some trickery with LOAD_
CACHE(). Alternatively, you might use the so-called super-build
approach, but be prepared for other issues then, cf. [1].
Specifically I am wondering:
- CMake finds a compiler and makes a test. A colleague has tried to
change
the compiler variables but CMake made the test and overwrote his settings
(from the CMakeLists.txt file) in CMakeCache.txt
The toolchain can't be changed without a complete reconfiguration, and
during the latter, CMake even forgets the cache settings specified on
the command line, cf. [2].
- With target_link_directories I can point out specifically which
libraries
should be used with each executable. But what about header files?
include_directories() is not specified for each executable. Is there
anyway
to control what is in the include path at different points in the
CMakeLists.txt. I have tried to use set_directory_properties(PROPERTIES
INCLUDE_DIRECTORIES ) to reset include path at one point. The deletion
works but just not at that specific point on CMakeLists.txt.
The INCLUDE_DIRECTORIES directory property is read-only.
- If split up into compiler1.cmake and compiler2.cmake I still get the
include_directories() problem since values are inherited
In general, I'd recommend to invoke INCLUDE_DIRECTORIES() sufficiently
deep within the CMakeLists.txt files' hierarchy to limit the scope of
its impact. Possibly, you even need to reorganize your project a bit,
i.e. split one CMakeLists.txt in two and have INCLUDE_DIRECTORIES()
called for the latters with the correct directories separately.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg36170.html
[2] http://www.mail-archive.com/cmake@cmake.org/msg37060.html
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource
Re: [CMake] One project, one platform, 2 compilers
On 11/17/2011 05:18 PM, Paul Hansen wrote:
Hi
I have a project that has to be compiled with two different compilers on
the same computer.
Can I do that from the same CMakeLists.txt file?
What do you mean exactly?
(1) Compile the project twice, each time completely with a different
compiler? If so, use two different build trees, as already outlined
in the meantime.
(2) A part of your project must be compiled with a different compiler
than the remaining parts? Difficult - besides a custom-command-based
approach, you might outsource the concerned part and reintegrate it
as an external project which can be configured independently with a
different toolchain. Look at the following example:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(MAIN C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(SUBCC ${CMAKE_C_COMPILER} CACHE FILEPATH Subproject C compiler)
INCLUDE(ExternalProject)
ExternalProject_Add(sub
SOURCE_DIR ${CMAKE_SOURCE_DIR}/sub
CMAKE_CACHE_ARGS
-DCMAKE_C_COMPILER:FILEPATH=${SUBCC}
-DCMAKE_INSTALL_PREFIX:PATH=${CMAKE_BINARY_DIR}/sub)
ADD_LIBRARY(f SHARED IMPORTED)
SET_TARGET_PROPERTIES(f PROPERTIES
IMPORTED_LOCATION ${CMAKE_BINARY_DIR}/sub/lib/libf.so)
ADD_DEPENDENCIES(f sub)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main f)
ADD_DEPENDENCIES(main f)
sub/CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(SUB C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(f SHARED f.c)
INSTALL(TARGETS f LIBRARY DESTINATION lib)
Configure with the desired SUBCC to see the subproject being built with
that instead of the overall project's C compiler. The downside is that
you can't use FIND_*() on the subproject's targets since they're built
after the overall project is already configured, so you must predict
their locations. Additionally, there may be issues w.r.t. the correct
handling of dependencies. Moreover, if the subproject is to share the
overall project's cache, you need to pass the concerned variables to
ExternalProject_Add() individually, or do some trickery with LOAD_
CACHE(). Alternatively, you might use the so-called super-build
approach, but be prepared for other issues then, cf. [1].
Specifically I am wondering:
- CMake finds a compiler and makes a test. A colleague has tried to change
the compiler variables but CMake made the test and overwrote his settings
(from the CMakeLists.txt file) in CMakeCache.txt
The toolchain can't be changed without a complete reconfiguration, and
during the latter, CMake even forgets the cache settings specified on
the command line, cf. [2].
- With target_link_directories I can point out specifically which libraries
should be used with each executable. But what about header files?
include_directories() is not specified for each executable. Is there anyway
to control what is in the include path at different points in the
CMakeLists.txt. I have tried to use set_directory_properties(PROPERTIES
INCLUDE_DIRECTORIES ) to reset include path at one point. The deletion
works but just not at that specific point on CMakeLists.txt.
The INCLUDE_DIRECTORIES directory property is read-only.
- If split up into compiler1.cmake and compiler2.cmake I still get the
include_directories() problem since values are inherited
In general, I'd recommend to invoke INCLUDE_DIRECTORIES() sufficiently
deep within the CMakeLists.txt files' hierarchy to limit the scope of
its impact. Possibly, you even need to reorganize your project a bit,
i.e. split one CMakeLists.txt in two and have INCLUDE_DIRECTORIES()
called for the latters with the correct directories separately.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg36170.html
[2] http://www.mail-archive.com/cmake@cmake.org/msg37060.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] TCL modules
On 11/17/2011 05:53 PM, Joe Brandt wrote:
I totally agree with your #2. I was thinking that it would be easier to
try and update the existing ones, rather than create new ones, at least
from the perspective of getting something done more quickly. The main
issue with that is that a new FindTclTk doesn't need to deal with backwards
compatibility. My other thought was it might be easier to become familiar
with maintaining modules by starting with existing ones, become familiar
with the whole process, and then move on to replacing the existing ones
with a new one. Ultimately a new one should be created.
If you think about a multi-component FindTclTk.cmake, note that there
are some questions which do not matter for single-component modules:
- Should the typical result variables like XXX_LIBRARIES accumulate
results from previous invocations, like {Find,Use}Qt4.cmake do?
- Meaning of REQUIRED and QUIET flags w.r.t. a single component
and its - possibly - automatically enabled prerequisite ones.
- Definedness of XXX_YY_FOUND variable if the component YY wasn't
requested explicitly; should always all components be searched?
- Unique handling of each component with FPHSA() or by other means?
- Meaning of XXX_FOUND if a requested/prerequisite component is absent?
BTW, how did you implement the search for a certain version without
version- or pattern-aware find functions in your improved modules?
Regards,
Michael
On Thu, Nov 17, 2011 at 6:27 AM, Michael Hertling mhertl...@online.dewrote:
On 11/17/2011 12:28 AM, Joe Brandt wrote:
I have a couple issues, that I'd like to help fix, with the current
FindTCL.cmake, FindTclsh.cmake, FindWish.cmake, and FindTclStub.cmake
that
make them unusable for me. The first is they do not always find the
various components from the same Tcl installation on the system. The
second being that you cannot specify the version of Tcl that you want to
find via the find_package command. I have systems that have multiple
installations of Tcl and have programs that require different versions of
Tcl.
I have modified the current Tcl modules to solve these two issues. My
changes at this point were geared around changing as little as possible
from the originals to get these two items to work. I really needed to
just
get it working for my environment, but after thinking about it I would
rather try and get these changes/ideas pushed upstream rather than have
to
maintain my own Tcl modules.
I do not see a maintainer for these modules. I also saw there was
discussions around the Tcl modules a year ago, but don't know if that
panned out into anything. If there is no maintainer I am certainly
willing
to maintain these if it means these changes, in some form or another, can
get incorporated back upstream.
Joe
Two remarks:
(1) IIRC, the main obstacle w.r.t. version selection in the TCL modules
- as well as the Python and certainly further ones, BTW - is the find
functions' current inability to search for patterns, e.g. you can't
have FIND_LIBRARY() to search for libtcl\.[0-9]+\.[0-9]+\.so. Thus,
IMO, the key for a reasonable support of version selection by find
modules in general is the addition of pattern matching abilities
to the FIND_{LIBRARY,PROGRAM,PATH,FILE}() commands, cf. [1].
(2) IMO, the TCL-related stuff - as well as the Python one, BTW - is a
perfect candidate for a comprehensive and component-aware find module
FindTclTk.cmake, providing components tcl, tk, wish etc., so why not
pouring the time, work and brainpower into the development of such a
module instead of bothering about a bunch of separate modules which
actually belong together? Moreover, having the seach for libraries,
headers and executables centralized in one module only would make it
*much* easier to ensure a consistency w.r.t. the components' versions.
Regards,
Michael
[1] http://public.kitware.com/Bug/view.php?id=8396
--
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] Transitive linking
On 11/18/2011 10:03 PM, James Bigler wrote:
2011/11/18 Alexander Neundorf a.neundorf-w...@gmx.net
On Friday 18 November 2011, James Bigler wrote:
I thought CMake knew how to not drag all the dependent libraries once you
linked an executable module.
add_library(A STATIC a.cpp)
add_library(B SHARED b.cpp)
target_link_libraries(B A)
add_library(C SHARED c.cpp)
target_link_libraries(C B)
add_executable(run run.cpp)
target_link_libraries(run C)
At this point I'm seeing that C links against B and A when I think it
should only link against B since A shouldn't be needed to link against B.
In addition when compiling run, it links against B and A.
/usr/bin/c++ -dynamiclib -Wl,-headerpad_max_install_names -o
libC.dylib
-install_name /Users/jbigler/tmp/code/cmake/translinking/build/libC.dylib
CMakeFiles/C.dir/c.cpp.o libB.dylib libA.a
/usr/bin/c++-Wl,-search_paths_first -Wl,-headerpad_max_install_names
CMakeFiles/run.dir/run.cpp.o -o run libC.dylib libB.dylib libA.a
Is this the expected behavior?
Yes.
If you want to limit this, use target_link_libraries( C
LINK_INTERFACE_LIBRARIES ... ), with this you can specify the transitively
linked libraries when linking against C.
Alex
OK, so propagating the libraries is the default behavior. I tried to use
LINK_INTERFACE_LIBRARIES, but it only seemed to work for static libraries:
add_library(A STATIC a.cpp)
add_library(B SHARED b.cpp)
target_link_libraries(B A)
target_link_libraries(B LINK_INTERFACE_LIBRARIES)
add_library(C SHARED c.cpp)
target_link_libraries(C B)
target_link_libraries(C LINK_INTERFACE_LIBRARIES)
add_executable(run run.cpp)
target_link_libraries(run C)
During build:
Build B (this is fine)
/usr/bin/c++ -dynamiclib -o libB.dylib CMakeFiles/B.dir/b.cpp.o libA.a
Build C (this is fine too, no A in the list)
/usr/bin/c++ -dynamiclib -o libC.dylib CMakeFiles/C.dir/c.cpp.o libB.dylib
Build run (this is weird, it linked both B and C)
/usr/bin/c++CMakeFiles/run.dir/run.cpp.o -o run libC.dylib libB.dylib
Did I specify something wrong or does this property only consider static
libraries?
On *nix, I can't confirm this:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(TRANSLINK CXX)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/a.cxx void a(){}\n)
ADD_LIBRARY(A STATIC a.cxx)
FILE(WRITE ${CMAKE_BINARY_DIR}/b.cxx void b(){}\n)
ADD_LIBRARY(B SHARED b.cxx)
TARGET_LINK_LIBRARIES(B A)
TARGET_LINK_LIBRARIES(B LINK_INTERFACE_LIBRARIES)
FILE(WRITE ${CMAKE_BINARY_DIR}/c.cxx void c(){}\n)
ADD_LIBRARY(C SHARED c.cxx)
TARGET_LINK_LIBRARIES(C B)
TARGET_LINK_LIBRARIES(C LINK_INTERFACE_LIBRARIES)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.cxx int main(){}\n)
ADD_EXECUTABLE(main main.cxx)
TARGET_LINK_LIBRARIES(main C)
The main target's link command line reads:
.../c++ .../main.cxx.o -o main ... libC.so ... # No libB.so!
Do you actually get different results with the above-noted project?
In general, CMake's transitive handling of target dependencies causes
no harm since no library is loaded unnecessarily, although there may be
libraries which are specified unnecessarily. E.g., main would be linked
against libB.so without immediately referring to the latter, i.e. it is
formally overlinked, but whether libB.so is loaded on behalf of main or
on behalf of libC.so does not matter, and overlinking w.r.t. a static
library is not possible. Do you have particular requirements why you
want to reduce a target's references to the immediate dependencies?
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 static library
On 11/17/2011 10:28 AM, Romain LEGUAY wrote: Hello everyone! I found in previous message there is none option to specify to find_library function to search just static library. It was for CMake 2.6. Has it got any change with the new version of CMake? AFAIK, it hasn't, since the root of this issue is still that there's no generally accepted naming convention for actual static libraries and the DLL-accompanying import libraries on Windows. However, on *nix, you might make FIND_LIBRARY() prefer static libaries by manipulating the CMAKE_FIND_LIBRARY_SUFFIXES variable. I try to specify the name of the library like this: find_library(MY_STATIC_LIB NAMES libmylib.a PATHS /path/to/mylib) but it doesn't work. I don't understand the reason why it doesn't work. If anyone have some ideas... Usually, specifying the library's full name should work. Could you provide a minimal but complete counter-example for investigation? 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] TCL modules
On 11/17/2011 12:28 AM, Joe Brandt wrote:
I have a couple issues, that I'd like to help fix, with the current
FindTCL.cmake, FindTclsh.cmake, FindWish.cmake, and FindTclStub.cmake that
make them unusable for me. The first is they do not always find the
various components from the same Tcl installation on the system. The
second being that you cannot specify the version of Tcl that you want to
find via the find_package command. I have systems that have multiple
installations of Tcl and have programs that require different versions of
Tcl.
I have modified the current Tcl modules to solve these two issues. My
changes at this point were geared around changing as little as possible
from the originals to get these two items to work. I really needed to just
get it working for my environment, but after thinking about it I would
rather try and get these changes/ideas pushed upstream rather than have to
maintain my own Tcl modules.
I do not see a maintainer for these modules. I also saw there was
discussions around the Tcl modules a year ago, but don't know if that
panned out into anything. If there is no maintainer I am certainly willing
to maintain these if it means these changes, in some form or another, can
get incorporated back upstream.
Joe
Two remarks:
(1) IIRC, the main obstacle w.r.t. version selection in the TCL modules
- as well as the Python and certainly further ones, BTW - is the find
functions' current inability to search for patterns, e.g. you can't
have FIND_LIBRARY() to search for libtcl\.[0-9]+\.[0-9]+\.so. Thus,
IMO, the key for a reasonable support of version selection by find
modules in general is the addition of pattern matching abilities
to the FIND_{LIBRARY,PROGRAM,PATH,FILE}() commands, cf. [1].
(2) IMO, the TCL-related stuff - as well as the Python one, BTW - is a
perfect candidate for a comprehensive and component-aware find module
FindTclTk.cmake, providing components tcl, tk, wish etc., so why not
pouring the time, work and brainpower into the development of such a
module instead of bothering about a bunch of separate modules which
actually belong together? Moreover, having the seach for libraries,
headers and executables centralized in one module only would make it
*much* easier to ensure a consistency w.r.t. the components' versions.
Regards,
Michael
[1] http://public.kitware.com/Bug/view.php?id=8396
--
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] Circular dependencies because of file names?
On 11/16/2011 06:36 PM, Jookia wrote:
I've actually used that workaround, but it seems dirty as it shows up in
IDE targets like Visual Studio or other IDEs or makefiles. In fact, I
kind of like the 'generating /docs' part of the makefile.
Would it just be smarter to rename the target to 'documentation'?
Of course, that's also possible, but then, the documentation target and
the documentation directory would not be named the same. Alternatively,
you might leave out the WORKING_DIRECTORY clause, add another COMMAND
cmake -E make_directory to the target and use cmake -E chdir:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(DOCS NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ADD_CUSTOM_TARGET(docs
COMMAND ${CMAKE_COMMAND} -E
make_directory ${CMAKE_BINARY_DIR}/docs
COMMAND ${CMAKE_COMMAND} -E
chdir ${CMAKE_BINARY_DIR}/docs pwd)
Presumably, the directory's additional creations carries no weight.
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] shell level access to values of cmake variables
On 11/10/2011 06:48 PM, vagn scott wrote:
in my CMakeLists.txt file I have a statement
project(hello_foo_baz)
This defines PROJECT_NAME among other things.
is there something like
cmake --dump-var PROJECT_NAME
that would output the string
hello_foo_baz
TIA,
vagn
PROJECT_NAME is a CMake variable, i.e. it exists while the CMake
process is running, and it's visible in the CMakeLists.txt files
by the usual ${} dereferencer. It is *not* a member of the CMake
process' environment, although it can be written to the latter:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(ENVVAR NONE)
MESSAGE(BEFORE:)
EXECUTE_PROCESS(COMMAND env COMMAND grep PROJECT_NAME)
SET(ENV{PROJECT_NAME} ${PROJECT_NAME})
MESSAGE(AFTER:)
EXECUTE_PROCESS(COMMAND env COMMAND grep PROJECT_NAME)
In no case it is written to the environment of the CMake process'
parent, e.g. the shell, i.e. you can not access a PROJECT_NAME
environment variable after the CMake process has terminated.
If you need to access PROJECT_NAME after the configuration
has finished, the CMakeLists.txt must preserve it, e.g.
CONFIGURE_FILE(project_name.txt.in project_name.txt @ONLY)
with a project_name.txt.in like @PROJECT_NAME@.
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 new language
On 11/16/2011 04:13 AM, Stefan Monnier wrote: I'd still like to know how to explain to cmake that the command produces 2 files, but at least I can get rid of my hack. That (assuming just a simple object file is produced by compilation) is one of several general limitations with CMake language support. For example, my understanding is this issue has been taken care of for Fortran 95 (where compilation produces both object and module files) with Fortran-95 specific changes to the C++ cmake code. But I would far prefer to see a generic mechanism for this to not only to deal with the Fortran 95 module issue, but also the compilation-generated Ada library identification (*.ali) files, and also the similar issue for OCaml compiler generated files that you have described. Hmm... Because of this and other struggles I had trying to implement Ada language support for CMake, I didn't even consider implementing CMake language support for OCaml for the PLplot OCaml bindings. Instead we currently use (many!) custom commands and targets for that case, but I would be happy to change to your CMake OCaml language support if/when that works. I'm trying to use CMake for a new project here. This project (a new programming language, whose first implementation is in OCaml) is currently in the very first stages (I have barely more than the lexer written) and doesn't require anything sophisticated (there's only 1 OCaml file for now ;-). So my language support is very primitive and rather than fight CMake, I'll probably just switch to something else :-( In addition to custom commands/targets, as suggested meanwhile by Alan and Bill, you might also use the diverse RULE_LAUNCH properties. These allow to take arbitrary actions at build time, and you may grant them access to the placeholders used in rule variables, like SOURCE and OBJECT, so it should be well possible to address the OCaml-related issues you have reported on. Search the ML's archive for examples of these properties' usage. However, they are currently restricted to Makefiles, but your CMAKE_OCaml_COMPILE_OBJECT rule is too, AFAIK. 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 2.8.6 On Linux , link error and added
On 11/15/2011 06:26 PM, david_bjorn...@agilent.com wrote: The issue has been resolved http://public.kitware.com/Bug/view.php?id=12575 ++David-Bjornbak; OK, thanks for the hint. Regards, Michael PS: Please drop the ML a line if there's an outside progress in a topic you initiated - not everyone is monitoring the bug tracker. -- 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 2.8.6 On Linux , link error and added headers to ..._EXTERNAL_OBJECTS for executables
On 11/15/2011 06:04 PM, Bill Hoffman wrote: On 11/15/2011 11:52 AM, Michael Hertling wrote: Could you boild down this issue to a minimal and self-sufficient example - i.e. a project working with 2.6 (quite old) but failing with 2.8 - and post it here for further investigation? There was a bug created for this, and the problem found. The cmake code was marking the .h file as an object file. Must have been a bug fix in CMake that allowed the .h to be treated as an object file. See here for information: http://public.kitware.com/Bug/view.php?id=12575 Hi Bill, many thanks for this hint. Perhaps, I might take the opportunity and ask a related question. In [1], I noted that a file declared as EXTERNAL_OBJECT is delivered to the linker only if it has a name extension mentioned in CMAKE_LANG_IGNORE_EXTENSIONS, and this variable isn't accessible to the user. IMO, this is wrong; instead, EXTERNAL_OBJECT files should be supplied to the linker regardless of their name extensions, i.e. the relevant blocks within cmMakefileTargetGenerator::WriteTargetBuildRules() from Source/cmMakefileTargetGenerator.cxx should be swapped. That's also what the user expects from the EXTERNAL_OBJECT property's documention, as the limitation to the ignored extensions isn't mentioned. Is there a reason why this restriction is applied? Regards, Michael [1] http://www.mail-archive.com/cmake@cmake.org/msg37231.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] Using cpack for custom/local deployment
On 11/16/2011 02:11 PM, Alexander Broekhuis wrote: Hi all, I have some questions regarding the use of CPack and CMake. What I'd like to do is have the a target execute multiple cpack configurations (additionally, have a possibility to execute only one configuration). The cpack config can use a component to do filtering on the artifacts needed for one target. The set of artifacts needs to end up in a directory in the project. For example, I have three libraries/targets: - A - B - C Then I have 2 deployment targets (CPack configs): - Deploy1 - Deploy2 The result has to be something like: - Deploy1: A and B in a directory named Deploy1 - Deploy2: A and C in a directory named Deploy2 I currently have a solution which uses a macro and copies the artifacts to the correct directory, but custom targets always assume out-of-date. Is it possible to introduce a target which depends on several others targets and uses their out-of-date state? You might use custom targets in conjunction with custom commands: An OUTPUT-style custom command, i.e. ADD_CUSTOM_COMMAND(OUTPUT ...), is run only if its OUTPUTs don't exist or if they are're older than the prerequisites, i.e. the files/directories mentioned in the DEPENDS clause. So, you can do the following: ADD_CUSTOM_COMMAND(OUTPUT y COMMAND ... DEPENDS x) ADD_CUSTOM_TARGET(z DEPENDS y) The custom target z is always out-of-date, so the prerequisite custom command is always checked, but the latter's COMMAND is run only if y doesn't exist or is older than x. Thus, use custom commands for the actual operations, and custom targets to set up these operations' dependencies. Regards, Michael Also, can CPack be used to deploy to an exploded directory? There doesn't seem to be a Directory Generator. TiA! -- 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 2.8.6 On Linux , link error and added headers to ..._EXTERNAL_OBJECTS for executables
On 11/16/2011 06:05 PM, Bill Hoffman wrote:
On 11/16/2011 4:43 AM, Michael Hertling wrote:
On 11/15/2011 06:04 PM, Bill Hoffman wrote:
On 11/15/2011 11:52 AM, Michael Hertling wrote:
Could you boild down this issue to a minimal and self-sufficient example
- i.e. a project working with 2.6 (quite old) but failing with 2.8 - and
post it here for further investigation?
There was a bug created for this, and the problem found. The cmake code
was marking the .h file as an object file. Must have been a bug fix in
CMake that allowed the .h to be treated as an object file.
See here for information:
http://public.kitware.com/Bug/view.php?id=12575
Hi Bill,
many thanks for this hint. Perhaps, I might take the opportunity
and ask a related question. In [1], I noted that a file declared
as EXTERNAL_OBJECT is delivered to the linker only if it has a
name extension mentioned in CMAKE_LANG_IGNORE_EXTENSIONS, and
this variable isn't accessible to the user. IMO, this is wrong;
instead, EXTERNAL_OBJECT files should be supplied to the linker
regardless of their name extensions, i.e. the relevant blocks
within cmMakefileTargetGenerator::WriteTargetBuildRules() from
Source/cmMakefileTargetGenerator.cxx should be swapped. That's
also what the user expects from the EXTERNAL_OBJECT property's
documention, as the limitation to the ignored extensions isn't
mentioned. Is there a reason why this restriction is applied?
If someone explicitly sets a property on a file, then CMake should honor
that property. They should be able to have files that end in .foobar
that have object code in them. It is not quite the same thing as adding
something to a source list that needs to be there just so it will show
up in an IDE. The ignore stuff is only directed at the source lists.
That sounds absolutely reasonable, but look at the following example:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(EXTOBJ C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/g.c void g(void){}\n)
EXECUTE_PROCESS(COMMAND gcc -c f.c -o f.fb)
EXECUTE_PROCESS(COMMAND gcc -c g.c -o g.rc)
SET_SOURCE_FILES_PROPERTIES(f.fb PROPERTIES EXTERNAL_OBJECT TRUE)
SET_SOURCE_FILES_PROPERTIES(g.rc PROPERTIES EXTERNAL_OBJECT TRUE)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c f.fb g.rc)
f.fb and g.rc are both object files marked as EXTERNAL_OBJECT. While
g.rc appears in the linker command as expected, f.fb does not since
fb isn't among the extensions to be ignored, so it's never tested
for an EXTERNAL_OBJECT property. It seems as if the latter can take
effect only for files with ignored extensions, so how can one pass
a file ending in .foobar, e.g., to the linker command? Of course,
one can use TARGET_LINK_LIBRARIES(), but for this, EXTERNAL_OBJECT
is not necessary. Perhaps, you could once more shed some light on
this issue, or have I completely misunderstood your point?
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 with LINK_DIRECTORIES
On 11/14/2011 09:15 PM, Robert Dailey wrote:
On Mon, Nov 14, 2011 at 1:59 PM, Michael Hertling mhertl...@online.dewrote:
On 11/14/2011 06:17 PM, Robert Dailey wrote:
Well maybe you can tell me I'm doing this wrong then, but based on how I
am
currently setting up my third party libraries, it is required.
So basically all third party libraries we use are not installed
individually, instead we have a server on our intranet that contains
precompiled versions of all libraries in a specific and consistent
hierarchy. For this reason, it doesn't make sense to use find_library(),
which would normally always give you absolute paths to your library files
and thus link_directories() would not be needed.
Instead I have a script in CMake that iterates each third party library
and
adds its lib link directory to a list. When done I take this whole list
of
link directories and pass it to link_directories() in my top level
CMakeLists file, this way each and every project will include all of the
third party library lib directories to have access to them.
Instead of populating a list with the libraries' directories, you might
set up one variable for each library containing the latter's full path,
e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level
CMakeLists.txt, these variables propagate to subordinate CMakeLists.txt
files and, thus, will be known wherever they are needed in your project.
For each target I simply create a list of my libs, like so:
set( libraries zlib libbdb47 )
SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
I pass each one of these to target_link_libraries() and I leave it up to
the compiler to search for where to find the file in the provided link
directories.
An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
especially with numerous directories, there's a growing probability
that the -L option will lure the linker into a wrong directory some
day. There're even situations which can't be resolved with -L/-l at
all: Suppose you have a directory x with liba.so and libb.so, and a
directory y with different versions of lib{a,b}.so. Suppose further
you want to link against x/liba.so and y/libb.so. How do you achieve
this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
insisting on the use of LINK_DIRECTORIES() limits the possibilities
how to organize the libraries on your intranet server. IMO, these
are actual drawbacks. OTOH, you must know the libaries' locations
to use LINK_DIRECTORIES(), and the libraries must be known anyway,
so why not join the locations to the libraries and use full paths?
Problem is, if I end up using find_library(), I will have to provide hint
search directories for each and every single library, and there are about
20 of them. This to me is the same as just generating a list of directories
and including those directly, and a lot less trouble.
As David has outlined in the meantime, the advice is not about using
FIND_LIBRARY() - which has not been mentioned a single time - but to
assemble full paths from the libraries' directories and the libraries
themselves, instead of collecting the directories and passing them to
LINK_DIRECTORIES(). I doubt that the latter really means less trouble.
find_library() is great and I really wanted to use it for this, but to me
the benefits of using it diminish when we are not using third party
libraries installed in a non deterministic location. If a user installs the
third party libraries in different locations on each of their machines, and
different versions, it makes more sense to use it in that case.
Even if your third-party libraries' organization isn't subject to
change, so you don't need to use FIND_LIBARRY(), you might set up
variables with the libraries' full paths in the cache, i.e. using
SET(... CACHE FILEPATH ...), and preferably initialize them with
a separate file and the -C option. In this way, you do not need
to hard-code any paths in your project, and the user gains the
chance to manipulate each path on the command line or the GUI.
Why should I let CMake search find a library when I already know where it
is? Simply to get absolute paths to those libraries? If I want absolute
paths I can think of much better ways to do it, preferably through string
concatenation.
Exactly; do this to get full paths to your libraries, use these paths
in TARGET_LINK_LIBRARIES() and eliminate LINK_DIRECTORIES() from your
project. Besides, knowing where it is means an assumption of your
project on your system's administrational/organizational setup, and
relying on such an assumption means that you can't change this setup
without risking your project's breakage. Finally, LINK_DIRECTORIES()
dramatically increases this risk because it makes your project subtly
vunerable to changes in the third-party libraries' directory hierarchy.
Another issue is that 80% of the libraries we use do not have a
pre-packaged Find module provided
Re: [CMake] Circular dependencies because of file names?
On 11/14/2011 09:31 PM, Jookia wrote:
I have the following code:
# -- DOXYGEN
find_package(Doxygen)
set(docsDir ${CMAKE_BINARY_DIR}/docs/)
add_custom_command(OUTPUT ${docsDir}
COMMAND ${CMAKE_COMMAND} -E make_directory
${docsDir} VERBATIM)
add_custom_target(docs
COMMAND ${DOXYGEN_EXECUTABLE}
${CMAKE_SOURCE_DIR}/../doxygen/doxyfile
WORKING_DIRECTORY ${docsDir}
DEPENDS ${docsDir})
set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES
${docsDir})
Which causes a circular conflict. But when I change the docsDir to
${CMAKE_BINARY_DIR}/docs2/, I no longer get the error.
Is there a way to fix this?
The docs custom command is integrated in the docs custom target's
Makefile with a relative path, so there are dependencies of the type
docs (custom target) on docs (custom command's output) which are
ignored by Make. Thus, the docs directory is not created, and the
custom target fails. In general, it's a bad idea to have targets
with the same name as files/directories they depend on.
In order to solve this issue, add another custom target, say, docdir
which depends on the custom command's output; this will decouple the
docs custom target from the custom command. Finally, establish the
dependency of docs on docdir by ADD_DEPENDENCIES():
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(DOCS NONE)
SET(CMAKE_VERBOSE_MAKEFILE ON)
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/docs
COMMAND ${CMAKE_COMMAND} -E make_directory ${CMAKE_BINARY_DIR}/docs)
ADD_CUSTOM_TARGET(docdir DEPENDS ${CMAKE_BINARY_DIR}/docs)
ADD_CUSTOM_TARGET(docs
COMMAND ${CMAKE_COMMAND} -E echo custom target docs
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/docs)
ADD_DEPENDENCIES(docs docdir)
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] Libraries with custom build command
On 11/14/2011 08:11 PM, Mathias Gaunard wrote:
What is the recommended way to define libraries with custom build commands?
This trick seems to be the only way:
if(NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp)
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp)
endif()
add_library(foo dummy.cpp)
add_custom_command(TARGET foo POST_BUILD
COMMAND my command to replace the dummy libfoo
)
Is it normal that kind of thing is not possible with IMPORTED libraries?
IMO, no: ;-)
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(CUSTOMLIBRARIES C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_BINARY_DIR}/libf.so
COMMAND gcc -fPIC -c f.c
COMMAND gcc -fPIC -shared -o libf.so f.o
DEPENDS ${CMAKE_BINARY_DIR}/f.c)
ADD_CUSTOM_TARGET(libf DEPENDS ${CMAKE_BINARY_DIR}/libf.so)
ADD_LIBRARY(f SHARED IMPORTED)
SET_TARGET_PROPERTIES(f PROPERTIES
IMPORTED_LOCATION ${CMAKE_BINARY_DIR}/libf.so)
ADD_DEPENDENCIES(f libf)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main f)
Does this suit 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] cmake 2.8.6 On Linux , link error and added headers to ..._EXTERNAL_OBJECTS for executables
On 11/12/2011 12:41 AM, david_bjorn...@agilent.com wrote: I'm getting a Link error on Linux when I use CMake 2.8.6 or 2.8.5. If use CMake 2.6.3, with the exact same configuration, the link works. I did a diff on the build.make from 2.8.6 and 2.6.3 and found when I use cmake 2.8.6 On Linux adding headers to ..._EXTERNAL_OBJECTS for executables under the build.make. The following is the link error I get, it looks for a header but, the link.txt does need it and the diff on build.make that looks like is causing this. Link Error Message nux_x86_64/lib/libeemdump.so /hped/builds/tools/google-breakpad/784/lib.linux_x86_64/release/libbreakpad.a /hped/builds/tools/google-breakpad/78 4/lib.linux_x86_64/release/libbreakpad_client.a /hped/builds/tools/google-breakpad/784/lib.linux_x86_64/release/libbreakpad_server.a /gfs/sr/blu efin/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease/linux_x86_64/lib/libplugin_manager.so /hped/builds/tools/qt/4.7.4/linux_x86_6 4/lib/libQtCore.so /hped/builds/tools/cryptopp/5.6.0_0/linux_x86_64/release/libcryptopp.a /hped/builds/tools/boost/boost_1_45_0/lib.linux_x86_64 /release/libboost_date_time.a /hped/builds/tools/boost/boost_1_45_0/lib.linux_x86_64/release/libboost_filesystem.a /hped/builds/tools/boost/boos t_1_45_0/lib.linux_x86_64/release/libboost_program_options.a /hped/builds/tools/boost/boost_1_45_0/lib.linux_x86_64/release/libboost_system.a /h ped/builds/tools/boost/boost_1_45_0/lib.linux_x86_64/release/libboost_thread.a /hped/builds/tools/stl/5.2.1/lib.linux_x86_64/libstlport_gcc.so - Wl,-rpath,/hped/builds/tools/qt/4.7.4/linux_x86_64/lib:/hped/builds/tools/stl/5.2.1/lib.linux_x86_64:/gfs/sr/bluefin/d1/build/hped/builds/sr/dev XXX/rcupgrd_int/build/64bitrelease/linux_x86_64/lib:/release: msgs_eesofpvm_multitool.h:4:19: fatal error: Diag.h: No such file or directory compilation terminated. make[3]: *** [/gfs/sr/bluefin/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease/linux_x86_64/bin/eesofpvm_multitool] Error 1 make[3]: Leaving directory `/hfs/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease' make[2]: *** [projects/simsys/source/eesofpvm_multitool/CMakeFiles/eesofpvm_multitool.dir/all] Error 2 Diff with the build.make file, notice the file msgs_eesofpvm_multitool.h eesofpvm_multitool_EXTERNAL_OBJECTS = --- eesofpvm_multitool_EXTERNAL_OBJECTS = \ /hfs/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease/projects/simsys/source/eesofpvm_multitool/msgs_eesofpvm_multitool.h 498d482 /gfs/sr/bluefin/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease/linux_x86_64/bin/eesofpvm_multitool: /hped/builds/tools/qt/4.7.4 /linux_x86_64/lib/libQtCLucene.so 500,502d483 /gfs/sr/bluefin/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease/linux_x86_64/bin/eesofpvm_multitool: /usr/X11R6/lib64/libXext.so /gfs/sr/bluefin/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease/linux_x86_64/bin/eesofpvm_multitool: /usr/X11R6/lib64/libX11.so /gfs/sr/bluefin/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease/linux_x86_64/bin/eesofpvm_multitool: /usr/lib64/libm.so 519a501 /gfs/sr/bluefin/d1/build/hped/builds/sr/devXXX/rcupgrd_int/build/64bitrelease/linux_x86_64/bin/eesofpvm_multitool: projects/simsys/source/eeso fpvm_multitool/msgs_eesofpvm_multitool.h ++David-Bjornbak; Could you boild down this issue to a minimal and self-sufficient example - i.e. a project working with 2.6 (quite old) but failing with 2.8 - and post it here for further investigation? 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] Workflow of a collaborative project in Visual Studio+CMake
On 11/12/2011 01:39 PM, David Cole wrote: For reference, the bug Mike refers to is this one: http://public.kitware.com/Bug/view.php?id=11258 I always use the manual technique of shutting down VS, running CMake, and then re-opening VS. It's really not that bad, once you get used to it. David C. Is it possibly an alternative to use cmake --build within an already configured build tree, provided the VS IDE is not strictly necessary? E.g., when porting a project from *nix to Windows, I usually open the VS shell, run CMake on the project's source tree from within a build directory and finally cmake --build .. For last-minute changes, I use the editor of my choice and invoke cmake --build . again. With Makefiles on *nix, this approach works as expected, but with VS, I noticed the following issue: The project is correctly rebuilt after a change in a source file, but a change in a CMakeLists.txt file only results in a regeneration of the solution and project files *without* recompiling or relinking anything, i.e. it is solely the ZERO_CHECK project which is rebuilt. In order to rebuild the actual targets, I need to specify the --clean-first option to cmake --build .. It seems as if a changed VS project file doesn't make VS recompile the affected source files, even if this is clearly necessary, e.g. due to changed preprocessor definitions. Is this behavior intended or VS-immanent, or should it be taken for buggy? Perhaps, a VS expert could shed some light on this matter; it'd be greatly appreciated. Regards, Michael On Fri, Nov 11, 2011 at 5:48 PM, Michael Jackson mike.jack...@bluequartz.net wrote: It is worse and better. 1: CMake will generate the VS projects and solutions every time it needs to run. DO NOT EDIT the generated VS projects and solutions. Add the requirements to the CMake files. 2: If you are on VS2007/VS2008 and you do a git pull and then switch to VS and click build a cmake check is run FIRST. If anything is different the new solution and project files are generated and then the build continues. You will get a dialog asking if you want to reload all of the projects. Things are pretty nice. 3: If you are on VS2010 there is now a long standing bug that seems to have no solution where you basically have to do the following: Close the VS solution git pull run cmake to regenerate the solution and projects Open the Solution and Compile. Yep. Sucks. Purchased VS2010 last year and have yet to use it because of that bug. If we (the cmake community**) were to actually figure out how to solve the problem then VS2010 would be as seamless as VS2008. Here is hoping for the future. ** I have kept track of the bug. Kitware and others have put a lot of time into trying to fix the bug. It just seams to be one of those elusive fixes that there just may not be a solution to. -- Mike Jackson www.bluequartz.net On Nov 11, 2011, at 5:30 PM, David Doria wrote: I typically work in KDevelop which has CMake support, so if another developer pushes some new files and changes to the CMakeLists.txt of my project, I simply 'git pull' the project and then click Build and it knows exactly what to do - it runs CMake and then builds the project. However, when working with Visual Studio, do I have to 'git pull', then go open cmake-gui from the VS2010E terminal, re-configure and re-generate the project, then reimport the VS2010E project, then build? This seems horribly awkward. And the reverse appears to have the same problem - if working inside VS I add a file to the VS project, how do I 'export' this addition back to the git repo? Thanks, David -- 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 single-configuration makefiles
On 11/13/2011 11:30 PM, Eric Noulard wrote:
2011/11/13 Robert Dailey rcdai...@gmail.com:
I understand that currently Makefiles generated by CMake are
single-configuration by-design. In other words, you can't issue a debug or
release command to make, you have to regenerate for a different
configuration.
For this purpose you can use 2 build trees that use the same source tree
cd /path/to/source
mkdir dbuild
cd dbuild
cmake -DCMAKE_BUILD_TYPE=Debug ..
cd ..
mkdir rbuild
cd rbuild
cmake -DCMAKE_BUILD_TYPE=Release ..
now to build debug
cd dbuild; make
and to build release
cd rbuild; make
Can someone explain the reason for this design?
Don't know in the past I used makefile that can deal with multiple config,
everytime it was a re-entrant makefile scheme. May be this should be
avoided in order to produce 'portable' makefiles?
Are there any plans to change it?
Don't know.
But may be it would be nice to have a way to create
several build trees at one time for that and produce a unifying
top level makefile that drive them all.
One can nearly achieve this by now; see the following example:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(MULTICONFIG C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
# --
IF(CMAKE_CONFIGURATION_TYPES)
ADD_CUSTOM_TARGET(configs)
ADD_CUSTOM_TARGET(builds)
FOREACH(i IN LISTS CMAKE_CONFIGURATION_TYPES)
FILE(MAKE_DIRECTORY ${PROJECT_BINARY_DIR}/${i})
ADD_CUSTOM_TARGET(config-${i}
COMMAND ${CMAKE_COMMAND} ${PROJECT_SOURCE_DIR}
-DCMAKE_BUILD_TYPE=${i}
-DCACHE_DIR=${PROJECT_BINARY_DIR}
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/${i})
ADD_DEPENDENCIES(configs config-${i})
ADD_CUSTOM_TARGET(build-${i}
COMMAND ${CMAKE_COMMAND} --build ${PROJECT_BINARY_DIR}/${i})
ADD_DEPENDENCIES(builds build-${i})
ENDFOREACH()
FOREACH(i IN LISTS FORWARD)
ADD_CUSTOM_TARGET(${i}
COMMAND ${CMAKE_COMMAND} --build \${CONFIG} --target ${i})
ENDFOREACH()
ADD_CUSTOM_TARGET(world ALL
COMMAND ${CMAKE_COMMAND} --build \${CONFIG})
RETURN()
ENDIF()
IF(DEFINED CACHE_DIR)
LOAD_CACHE(${CACHE_DIR}
EXCLUDE CMAKE_BUILD_TYPE CMAKE_CONFIGURATION_TYPES)
ENDIF()
# --
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES
COMPILE_DEFINITIONS_DEBUG DEBUG
COMPILE_DEFINITIONS_RELEASE RELEASE)
/* main.c: */
int main(void){return 0;}
The part to add in order to enable multiple build trees is between
-- and --. The basic idea is: If CMAKE_CONFIGURATION_TYPES is
defined, create a build tree for each entry along with a custom target
which configures that tree with the correct CMAKE_BUILD_TYPE. Also, add
a custom target which builds that tree via cmake --build. These build
trees' configurations must be a separate step - therefore, driven by a
custom target - because the top-level configuration has to be finished
to enable the several build trees to load the cache via LOAD_CACHE();
otherwise, the initial -D settings would not be forwarded. For these
reasons, we need the CACHE_DIR variable, and the RETURN() statement
disables the actual part of the CMakeLists.txt file in the top-level
configuration. Obviously, CMAKE_BUILD_TYPE/CMAKE_CONFIGURATION_TYPES
must not be loaded from the cache to the build trees. A downside is
that you must implement your own, say, target forwarding if you
want to be able to say main TARGET CONFIG=debug; the FORWARD
variable with a list of targets to be forwarded is used for this
purpose. To see the project in action, go to an empty top-level
build directory and issue, e.g.:
cmake srcdir \
-DCMAKE_CONFIGURATION_TYPES=debug;release;custom \
-DCMAKE_C_FLAGS_CUSTOM=-DCUSTOM \
-DFORWARD=main
This will create the subdirectories {debug,release,custom}; now
make configs
to configure the different build trees and load the cache from the
top-level configuration. Subsequently, you can say make builds to
build all configurations, or cmake --build config to build only
one, or make main CONFIG=CONFIG or even make CONFIG=CONFIG.
Anyway, although the addition to mimic the behavior of a real multi-
configuration generator to the Makefiles ones is no big deal, I'm
in doubt if it's worth the effort. Personally, I'm fine with the
Makefiles generators' single-configuration limitation.
Regards,
Michael
I'm new to Makefiles so I'm curious to learn as much as possible
about it.
If you are new to makefile may be you can have a look at
the chapter 4 of this book
http://www.informit.com/store/product.aspx?isbn=0130091154
it is about GNU make but it contains valuable introduction to makefile
and the book may downloaded:
http://ptgmedia.pearsoncmg.com/images/0130091154/downloads/0130091154.zip
--
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:
Re: [CMake] Problem with LINK_DIRECTORIES
On 11/14/2011 06:17 PM, Robert Dailey wrote:
On Mon, Nov 14, 2011 at 11:00 AM, David Cole david.c...@kitware.com wrote:
On Mon, Nov 14, 2011 at 9:36 AM, Robert Dailey rcdai...@gmail.com wrote:
On Mon, Nov 14, 2011 at 6:42 AM, Michael Wild them...@gmail.com wrote:
Hi Arun
Consider LINK_DIRECTORIES to be obsolete and to be avoided at all cost.
I don't really agree with this advice. There are circumstances where
link_directories() is absolutely necessary, so advocating to completely
avoid it isn't really a one size fits all scenario.
I agree with the advice entirely. link_directories is completely
*un*necessary if you follow the other advice which is to always use
full path names to library files (or CMake target names) when calling
target_link_libraries.
I never use link_directories.
Well maybe you can tell me I'm doing this wrong then, but based on how I am
currently setting up my third party libraries, it is required.
So basically all third party libraries we use are not installed
individually, instead we have a server on our intranet that contains
precompiled versions of all libraries in a specific and consistent
hierarchy. For this reason, it doesn't make sense to use find_library(),
which would normally always give you absolute paths to your library files
and thus link_directories() would not be needed.
Instead I have a script in CMake that iterates each third party library and
adds its lib link directory to a list. When done I take this whole list of
link directories and pass it to link_directories() in my top level
CMakeLists file, this way each and every project will include all of the
third party library lib directories to have access to them.
Instead of populating a list with the libraries' directories, you might
set up one variable for each library containing the latter's full path,
e.g. ZLIB_LIBRARY or BDB47_LIBRARY. Since you do this in the top-level
CMakeLists.txt, these variables propagate to subordinate CMakeLists.txt
files and, thus, will be known wherever they are needed in your project.
For each target I simply create a list of my libs, like so:
set( libraries zlib libbdb47 )
SET(libraries ${ZLIB_LIBRARY} ${BDB47_LIBRARY})
I pass each one of these to target_link_libraries() and I leave it up to
the compiler to search for where to find the file in the provided link
directories.
An unrestricted use of LINK_DIRECTORIES() means asking for trouble;
especially with numerous directories, there's a growing probability
that the -L option will lure the linker into a wrong directory some
day. There're even situations which can't be resolved with -L/-l at
all: Suppose you have a directory x with liba.so and libb.so, and a
directory y with different versions of lib{a,b}.so. Suppose further
you want to link against x/liba.so and y/libb.so. How do you achieve
this with LINK_DIRECTORIES() and TARGET_LINK_LIBRARIES()? Reversely,
insisting on the use of LINK_DIRECTORIES() limits the possibilities
how to organize the libraries on your intranet server. IMO, these
are actual drawbacks. OTOH, you must know the libaries' locations
to use LINK_DIRECTORIES(), and the libraries must be known anyway,
so why not join the locations to the libraries and use full paths?
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] Static Library output problem
On 11/11/2011 03:42 PM, Romain LEGUAY wrote: Ok thanks for your quick answers! It works perfectly now! Why don't we have just one variables for the library? With set_target_properties, we can define for each library the path. Because (1) ADD_LIBRARY() might lack the SHARED/STATIC keyword, and the user can decide which type of library is built via the BUILD_SHARED_LIBS variable, so an ADD_LIBRARY() command can be unalteredly used to build a shared library as well as a static one, and (2) on *nix, the outcome of ADD_LIBRARY(... SHARED ...) is a LIBRARY target whereas on Windows, the DLL part is a RUNTIME target, and the accompanying import library is an ARCHIVE target. For these reasons, the same ADD_LIBRARY() command - i.e., the same target - might generate different types of libraries, so there is a need to specify the respective *_OUTPUT_DIRECTORY individually. Regards, Michael Le 11/11/2011 15:38, Andreas Pakulat a écrit : On 11.11.11 15:18:05, Romain LEGUAY wrote: Hello everyone! First, I need to thank you all the CMake developers for their awesome work!!! I try to build a static and a shared libraries. I set the LIBRARY_OUTPUT_DIRECTORY for each library target like this: See the documentation for the LIBRARY_OUTPUT_DIRECTORY, it only applies to shared libraries on non-dll platforms (*nix usually). For a static library you need to set ARCHIVE_OUTPUT_DIRECTORY. Andreas -- 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] /usr/bin/gcc -o tcl2c++ -rdynamic \n gcc: fatal error: no input files
On 11/12/2011 02:48 PM, YunQiang Su wrote:
I do an cmake program, but encount an stranger problem.
1. mkdir tmp; cd tmp
2. tar -zxvf ../cmake-test.tar.gz
3. mkdir build; cd build
4. cmake ..; make
I got an error:
/usr/bin/gcc-o tcl2c++ -rdynamic
gcc: fatal error: no input files
Then
1. cd ..
1. head -51 CMakeLists.txt CMakeLists.txt.tmp
2. mv CMakeLists.txt.tmp CMakeLists.txt
3. cd build
4. rm -fr *
5. cmake ..; make
It works now.
Why?
Because of the MAIN_DEPENDENCY clause in the custom command; it's just
meant as a hint for Visual Studio, but not to establish a dependency,
and apparently, the Makefile generators are tangled when seeing this
clause. Actually, you don't need to explicitly declare a dependency
on the tcl2c++ executable at all; using the target name suffices.
The attached patch makes your project build on my system.
Regards,
Michael
--- CMakeLists.txt.bak 2011-11-13 01:51:16.981958217 +0100
+++ CMakeLists.txt 2011-11-13 01:51:55.492364967 +0100
@@ -95,16 +95,13 @@
set(CONSOLE_FILES ${LIBRARY_TK}/console.tcl)
-set(TCL2CPP ${CMAKE_CURRENT_BINARY_DIR}/tcl2c++)
-
add_custom_command(OUTPUT embedded-tcl.cc embedded-tk.cc embedded-tclobj.cc
- COMMAND ${TCL2CPP} ARGS et_tcl ${TCL_LIBRARY_FILES} embedded-tcl.cc
+ COMMAND tcl2c++ et_tcl ${TCL_LIBRARY_FILES} embedded-tcl.cc
COMMAND sed -i -e 's/package require -exact T/package require T/g' embedded-tcl.cc
- COMMAND ${TCL2CPP} ARGS et_tk ${TK_LIBRARY_FILES} embedded-tk.cc
+ COMMAND tcl2c++ et_tk ${TK_LIBRARY_FILES} embedded-tk.cc
COMMAND sed -i -e 's/package require -exact T/package require T/g' embedded-tk.cc
- COMMAND ${TCL2CPP} ARGS et_tclobject tcl-object.tcl tcl-import.tcl tcl-http.tcl embedded-tclobj.cc
- COMMAND ${TCL2CPP} ARGS et_console ${CONSOLE_FILES} embedded-console.cc
- MAIN_DEPENDENCY tcl2c++
+ COMMAND tcl2c++ et_tclobject tcl-object.tcl tcl-import.tcl tcl-http.tcl embedded-tclobj.cc
+ COMMAND tcl2c++ et_console ${CONSOLE_FILES} embedded-console.cc
)
#pkg_check_modules(OTCL REQUIRED otcl)
--
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] Issue with check_include_file() and GL/glxproto.h
On 11/11/2011 12:42 PM, GOUJON Alexandre wrote:
On 11/11/2011 04:13 AM, Michael Hertling wrote:
On 11/10/2011 11:22 PM, Eric Noulard wrote:
If this is the case then it is a GL/glxproto.h design mistake
not CMake mistake.
Absolutely, try to compile the following program by hand; it's
the same the CHECK_INCLUDE_FILE() macro tries to compile, too:
#includeGL/glxproto.h
int main(void){return 0;}
It will fail with the same error message, i.e. the GL/glxproto.h header
is not self-sufficient; if intentionally or accidentally, I don't know.
It's this failure that makes CHECK_INCLUDE_FILE() report the header as
non-existent, or better as not compilable.
I just sent them an e-mail so that they will be aware of the issue.
Is the GL/glxproto.h header a public one or is it private, i.e. is it
meant to be included explicitly by client code or not? In the latter
case, by convention, it usually needs not to be self-sufficient.
This is true but the documentation tells you more about the macro
cmake --help-module CheckIncludeFile
says
an optional third argument is the CFlags to add to the compile line or
you can use CMAKE_REQUIRED_FLAGS
which clearly states that it does a compilation.
Indeed, CHECK_INCLUDE_FILE() means: Check if a header is *functional*.
Ok, will use find_file instead.
The thing you want is probably
if(DEFINED VARIABLE)
message(FATAL_ERROR VARIABLE already defined :${VARIABLE} aborting)
endif()
Yeah, thanks.
I think it's not the responsability of check_include_file to do such job
but you can do that in your CMakeLists.txt
With FIND_FILE/PATH() looking for a header, the user must have the
possibility to make them no-ops by presetting the result variable,
so these functions must not overwrite a valid path. However, with
CHECK_INCLUDE_FILE(), the user can't define a header as working;
thus, there is no need to protect an already defined variable from
being overwritten, IMO. Moreover, the user must have the chance to
reuse the same variable for this purpose again without having the
configuration terminate. OTOH, one usually uses an individually
named variable for each header, e.g. HAVE_GL_GLXPROTO_H, as you
do, which is most certainly not reused for anything at all.
Ok but as I didn't understand why check_include_file was failing, I
tried many things like simple then double quoting GL/glxproto.h and also
tried a different variable name. I took HAVE_UNISTDE_H because I knew
HAVE_UNISTD_H was working. With HAVE_UNISTDE_H, check_include_file
seemed to work (it wasn't true, this variable name was simply defined
before elsewhere) so in the end, I believed some variable names were
allowed and others not. So to avoid the same mistake, I thought a
message (at least a STATUS one) wouldn't hurt.
IF(${VARIABLE} MATCHES ^${VARIABLE}$) fails : is it intended ?
I do not understand
In which case does it fail?
Actually, every time.
Here is the beginning of my modified CheckIncludeFile.cmake :
MACRO(CHECK_INCLUDE_FILE INCLUDE VARIABLE)
message(STATUS ${VARIABLE})
IF(${VARIABLE} MATCHES ^${VARIABLE}$)
message(STATUS ${VARIABLE} matches ^${VARIABLE}$)
and I only have the following output
-- HAVE_SYS_TIME_H
-- HAVE_SYS_TYPES_H
-- HAVE_SYS_RESOURCE_H
-- HAVE_SYS_STAT_H
-- HAVE_UNISTD_H
-- HAVE_FCNTL_H
-- HAVE_GL_GLXPROTO_H
CMake Error at CMakeLists.txt:117 (message):
[..]
So the first IF is failing, skipping the whole macro.
If I add a # before this IF (and the corresponding ENDIF),
check_include_file does its jobs and even finds the other headers :
[...]
-- HAVE_FCNTL_H
-- HAVE_FCNTL_H matches ^HAVE_FCNTL_H$
-- Looking for fcntl.h
-- Looking for fcntl.h - found
-- HAVE_GL_GLXPROTO_H
-- HAVE_GL_GLXPROTO_H matches ^HAVE_GL_GLXPROTO_H$
-- Looking for GL/glxproto.h
-- Looking for GL/glxproto.h - not found
Any idea ?
Sorry, I talked nonsense in my previous reply. Obviously, the line
IF(${VARIABLE} MATCHES ^${VARIABLE}$)
serves to prevent the macro's re-execution if the result variable is
already defined, i.e. if the macro has most certainly been called
before with the same parameters. E.g., with VARIABLE equaling
HAVE_XYZ_H, this line expands to
IF(HAVE_XYZ_H MATCHES ^HAVE_XYZ_H$)
and due to the implicit evaluation of variables on the left-hand
side of the IF() command's MATCHES clause, it finally looks like
IF(TRUE MATCHES ^HAVE_XYZ_H$)
or
IF(FALSE MATCHES ^HAVE_XYZ_H$)
provided the macro has been called before, i.e. HAVE_XYZ_H is either
TRUE or FALSE. Of course, these latter conditions are false, so the
macro isn't executed again. OTOH, if the variable HAVE_XYZ_H is un-
defined, i.e. the macro has not been called yet, the line remains
IF(HAVE_XYZ_H MATCHES ^HAVE_XYZ_H$)
which is true, so the macro is executed. Therefore, the macro is
skipped if the result variable indicates that there is already a
result. Thus, in contrast to what I erroneously said before, one
can indeed define a header as working
Re: [CMake] ifort,icc,icpc: ld: cannot find -lcilkrts
On 11/12/2011 08:48 AM, Ilias Miroslav wrote: Dear experts, our problem is that cmake sets automatically linking libraries for C,C++ and with Intel compilers (Fortran,C,C++) we are getting these problems ( first observed here https://repo.ctcc.no/CDash/viewBuildError.php?buildid=5283 ) : . . . Linking Fortran executable dirac.x /people/disk2/ilias/bin/cmake_install/bin/cmake -E cmake_link_script CMakeFiles/dirac.x.dir/link.txt --verbose=1 /people/disk2/magnus/intel/composerxe-2011.2.137/bin/intel64/ifort-static -Wl,-E -w -assume byterecl -DVAR_IFORT -g -traceback -static-libgcc -static-intel -i8 -O0 CMakeFiles/dirac.x.dir/main/main.F90.o -o dirac.x -i_dynamic lib/libdirac.a lib/libxcfun.a -ldecimal -lcilkrts -lstdc++ -lirc ld: cannot find -lcilkrts make[3]: *** [dirac.x] Error 1 . Manual linking without the -lcilkrts flag works: il...@fe6.dcsc.sdu.dk:~/QCH_Work/qch_progs/dirac_git/trunk/build_ompi_ifort_icc_ilp64_static/./people/disk2/magnus/intel/composerxe-2011.2.137/bin/intel64/ifort -static -Wl,-E -w -assume byterecl -DVAR_IFORT -g -traceback -static-libgcc -static-intel -i8 -O0 CMakeFiles/dirac.x.dir/main/main.F90.o -o dirac.x -i_dynamic lib/libdirac.a lib/libxcfun.a -ldecimal -lstdc++ -lirc il...@fe6.dcsc.sdu.dk:~/QCH_Work/qch_progs/dirac_git/trunk/build_ompi_ifort_icc_ilp64_static/. The problematic cilkrts library is set automatically within CMAKE_C_IMPLICIT_LINK_LIBRARIES CMAKE_CXX_IMPLICIT_LINK_LIBRARIES variables, as found: il...@fe6.dcsc.sdu.dk:~/QCH_Work/qch_progs/dirac_git/trunk/build_ompi_ifort_icc_ilp64_static/.grep cilkrts * */* . CMakeFiles/CMakeCCompiler.cmake:SET(CMAKE_C_IMPLICIT_LINK_LIBRARIES imf;svml;m;ipgo;decimal;cilkrts;stdc++;irc;c;irc_s;dl;c) CMakeFiles/CMakeCXXCompiler.cmake:SET(CMAKE_CXX_IMPLICIT_LINK_LIBRARIES imf;svml;m;ipgo;decimal;cilkrts;stdc++;irc;c;irc_s;dl;c) . . Please how to remove cilkrts or any other parameter from CMAKE_LANG_IMPLICIT_LINK_LIBRARIES, http://www.cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_LANG_IMPLICIT_LINK_LIBRARIES ? We have cmake version 2.8.4 and Intel is Intel(R) 64, Version 12.0.2.137 Build 20110112. Yours, M.Ilias Perhaps, you might check how the offending library makes it into the CMAKE_LANG_IMPLICIT_LINK_LIBRARIES variables. IIRC, these libraries are determined by building a small test program and analyzing the link command line, so linking against the cilkrts library should basically work if it appears among the implicit link libraries. The results of the analysis are reported in CMakeFiles/CMakeOutput.log; could you post it, or the relevant part thereof, for further investigation? 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] Using CTest with a different dashboard
On 11/09/2011 06:06 PM, EXT-York, Gantry wrote:
I'm looking for suggestions from someone who has used CTest to report results
to a dashboard other than CDash.
I'd like to be able to simply type
gmake test TESTOPTS=-report
then have CTest traverse all the directories and run the defined tests. Not
only would I like it to run these tests, but I'd like it to run it through a
wrapper script that I use to report the results to a different dashboard.
I've tried this with
set( TEST_WRAPPER /full/path/to/test_wrapper )
...
add_test( unit_test1 )
# syntax 1
add_test( /full/path/to/test_wrapper --report unit_test2 )# syntax 2
add_test( ${TEST_WRAPPER} ${TESTOPTS} unit_test3 )# syntax 3
There are several problems I've noticed with this:
Syntax 1 works fine. It knows where the name unit_test1 is located and runs,
but since it isn't run through the wrapper script, nothing is reported to our
dashboard.
Actually, this can't work as it misses the test's name. Moreover, you
should use the more powerful ADD_TEST(NAME ... COMMAND ...) signature.
Syntax 2 works does not work. All the arguments are quoted. -report fails
as an option because of the quotes, and unit_test2 is treated as a string
not as a name of a CMake object with a location.
Use generator expressions to refer to a target as a parameter for a test:
ADD_TEST(... COMMAND path/to/wrapper --report $TARGET_FILE:unit_test2)
AFAIK, CMake recognizes a target only as the command's first argument.
Syntax 3 is just a variation of syntax 2 and also fails, but it is preferable
to define the wrapper script in the highest level CMakeLists.txt file and
have that value carried through to sub directories.
Absolutely, and if the script is not contained in or generated by your
project, use FIND_PROGRAM() to locate it and to populate the variable.
So I tried this
set( TEST_WRAPPER /full/path/to/test_wrapper_report )
...
add_test( ${TEST_WRAPPER_REPORT} ${CURRENT_DIR}/ unit_test4 )
# syntax 4
I modified the test wrapper to report without having to specify the -report
option.
In this case, everything seemed to work, but the return/exit value coming
back from the wrapper script was wrong. It seems that something is going on
in the CTest framework that changes this value. Instead of getting a value
like -1, 0, 1, I was getting a value like 32844. I verified that unit_test4
returned the correct return status to the wrapper script and the wrapper
script returned the correct return status when run outside of the CTest
framework.
Usually, it should be possible to specify any arguments to a test
driver as arguments behind ADD_TEST()'s COMMAND clause, and there
should also be no issues w.r.t. quotes. Thus, you might try anew
with generator expressions and correctly set up ADD_TEST()
commands, and report if it still doesn't work.
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] Issue with check_include_file() and GL/glxproto.h
On 11/10/2011 11:22 PM, Eric Noulard wrote:
2011/11/10 GOUJON Alexandre ale.gou...@gmail.com:
Hi,
It all started when I tried compiling Piglit [1] : cmake checked all the
dependencies, didn't complain and generated Makefiles but doing 'make'
caused an error because a header was missing.
So I proposed myself to write a patch and add the check.
But the following didn't work :
check_include_file(GL/glxproto.h HAVE_GL_GLXPROTO_H)
if (NOT HAVE_GL_GLXPROTO_H)
message(FATAL_ERROR GL/glxproto.h required. On Ubuntu, you need the
x11proto-gl-dev package.)
endif (NOT HAVE_GL_GLXPROTO_H)
[...]
I'm not really familiar with CMake so I may have missed something.
What I understand is that check_include_file() tries to compile a test which
includes GL/glxproto.h.
It seems another header is needed prior to using GL/glxproto.h.
If this is the case then it is a GL/glxproto.h design mistake
not CMake mistake.
Absolutely, try to compile the following program by hand; it's
the same the CHECK_INCLUDE_FILE() macro tries to compile, too:
#include GL/glxproto.h
int main(void){return 0;}
It will fail with the same error message, i.e. the GL/glxproto.h header
is not self-sufficient; if intentionally or accidentally, I don't know.
It's this failure that makes CHECK_INCLUDE_FILE() report the header as
non-existent, or better as not compilable.
Until now I did never cross a public C or C++ header that needs
a previous include.
A public include file should always include its needed dependencies, right?
Yes, and the #include directives should always be ordered from most-to-
least dependent, as this helps to reveal hidden non-self-sufficiencies
of the included headers.
Or may be I'm missing some particular use case?
There might be rare exceptions, e.g. a header X.h which needs either
A.h or B.h but cannot decide by itself, so the user must decide if
A.h or B.h has to be included before X.h. Anyway, I don't know an
example, but any occurrence of this kind should be documented.
From my user point of view, this approach is quite strange because the
header is present but not found.
If you want to check the usability of the file, I think a comment or a
better macro name would help.
This is true but the documentation tells you more about the macro
cmake --help-module CheckIncludeFile
says
an optional third argument is the CFlags to add to the compile line or
you can use CMAKE_REQUIRED_FLAGS
which clearly states that it does a compilation.
Indeed, CHECK_INCLUDE_FILE() means: Check if a header is *functional*.
If you just want to find a file then may be,
find_file
cmake command would be a better choice.
And, could you add a check like
IF(${VARIABLE}) message(FATAL_ERROR ${VARIABLE} already defined :
aborting) ENDIF(${VARIABLE})
?
The thing you want is probably
if(DEFINED VARIABLE)
message(FATAL_ERROR VARIABLE already defined : ${VARIABLE} aborting)
endif()
That is, explicitly abort the macro instead of letting the user testing a
variable previously defined and not modified by check_include_file.
I think it's not the responsability of check_include_file to do such job
but you can do that in your CMakeLists.txt
With FIND_FILE/PATH() looking for a header, the user must have the
possibility to make them no-ops by presetting the result variable,
so these functions must not overwrite a valid path. However, with
CHECK_INCLUDE_FILE(), the user can't define a header as working;
thus, there is no need to protect an already defined variable from
being overwritten, IMO. Moreover, the user must have the chance to
reuse the same variable for this purpose again without having the
configuration terminate. OTOH, one usually uses an individually
named variable for each header, e.g. HAVE_GL_GLXPROTO_H, as you
do, which is most certainly not reused for anything at all.
Regards,
Michael
IF(${VARIABLE} MATCHES ^${VARIABLE}$) fails : is it intended ?
I do not understand
In which case does it fail?
--
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] Generated CMakeLists.txt
- model.xml - imput for model, - genfiles.py - simpledummy generaor testcase is: mkdir test cp generator.tar test tar xvf generator.tar mkdir obj cd obj cmake ../cmake_issue make -j then add new structure in model.xml e.g test.abc make -j #linking error will occurs since configuration is make -j # cmake phase will fix configuration and linking will be fine. Please remind that dummy model.xml in most cases is changed because of internal structure changes. I think you got my question about attaching to cmake --check-build-system commnad genfiles.py --cmake-only ... thanks in advance Lukasz 2011/11/8 Michael Hertling mhertl...@online.de: On 11/08/2011 03:30 PM, Łukasz Tasz wrote: Hi All, I have one issue connected with generated code. What is recommended way to proceed with generators which provides source which is dynamic? The setup looks like: generator has some input, and depending on this input files are generated. From cmake point of view I need only this list of source files to create library. Generator is providing simple command to generate such a list. During cmake phase, I'm calling generator to generate list.cmake with list of source file, then such a list is included, and configuration is generated. Source file are marked as generated, and appropriate ADD_CUSTOM_COMMAND(OUTPUT list) is registerd. In lifecycle cmake - make - edit-input_files - make - edit ... make everything works smooth with one remark, If you will edit input files in a way that new source file will be introduced, then regeneration is not enough, I need to regenerate configuration, with current approach it looks like: edit-input-adding-new-file - make-step1-generate: will regenerate the code + regenerate cmakelist - since new file is there make-step2-compile-sources: make-step3-linking - will fail since new file is not added to configuration, with next run of make, cmake --check-build-system will recognize changes in cmakelist and configuration will be regenerated, and build will be successfull (if code changes was smart enough:) ) The question is if there are some hooks to cmake --check-build-system that also additionaly my generate --cmake action will be called? (to regenerate cmakelist which holds list of files) Or maybe my approach is wrong? thanks in advance Lukasz If I understand correctly, you need to establish a dependency of the CMakeLists.txt file on the input for the code generator. You might use a CONFIGURE_FILE() command for this purpose, e.g. CONFIGURE_FILE(input.txt input.txt.bak COPYONLY) with input.txt being the code generator's input file. In this way, a change of input.txt outdates the CMakeLists.txt file, and the entire project is reconfigured and rebuilt the next time Make is called. If the machinery works by now when you reconfigure the project by hand, this should do the trick. If not, please come up with a minimal but complete example to show exactly what you are doing at the moment, what does not work and what you'd like to see instead. 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] Custom targets that traverse subdirectories
On 11/10/2011 12:25 AM, EXT-York, Gantry wrote:
And the command specialtest is executed out of the build tree?
This is what I'm doing now
CMakeLists.txt
add_custom_target(aggr_target)
add_subdirectory(a)
add_subdirectory(b)
a/CMakeLists.txt
add_executable( specialtest1 IMPORTED )
add_custom_target(a_special_test COMMAND specialtest1)
add_dependencies(aggr_target a_special_test)
b/CMakeLists.txt
add_executable( specialtest2 IMPORTED )
add_custom_target(b_special_test COMMAND specialtest2)
add_dependencies(aggr_target b_special_test)
It can't seem to find specialtest1 or specialtest2 to execute.
That's because specialtest{1,2} don't denote anything which could be
run; set their IMPORTED_LOCATION properties to an executable, or use
FIND_PROGRAM(SPECIALTEST specialtest) and COMMAND ${SPECIALTEST}
in the ADD_CUSTOM_TARGET() commands.
Regards,
Michael
Gantry York
Chandler, Arizona
-Original Message-
From: Łukasz Tasz [mailto:luk...@tasz.eu]
Sent: Wednesday, November 09, 2011 3:52 PM
To: EXT-York, Gantry
Cc: cmake@cmake.org
Subject: Re: [CMake] Custom targets that traverse subdirectories
Hi
As far as I understood your problem correctly:
in main cmakelists create target that will agregate subtargets:
main_cmake:
add_custom_target(aggr_target)
add_subdirectory(a)
add_subdirectory(b)
a/CMakeLists.txt
add_custom_target(a_special_test COMMAND specialtest)
add_dependencies(aggr_target a_special_test)
b/CMakeLists.txt
add_custom_target(b_special_test COMMAND specialtest)
add_dependencies(aggr_target b_special_test)
after generation when you will call:
make aggr_target
both special tests for a and b dir will be executed.
br
L.
2011/11/9 EXT-York, Gantry gantry.y...@boeing.com:
How do I define a custom target and have it traverse the source tree?
I'm using
add_custom_target(
specialtest
COMMAND rel/path/to/test_script
)
However, I need to add other commands to this target that come from scripts
in subdirectories.
Gantry York
Chandler, Arizona
--
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] Globally Set Target Properties
On 11/08/2011 01:36 PM, Schuchard, Matthew wrote: Thanks, I think I must be doing something wrong elsewhere then, because I follow the same syntax as what you wrote. However, it is not working for me which means my error must be somewhere else. Could you provide a minimal but complete exemplary project in order to show what does not work and what you would like to see instead? Regards, Michael I had thought, based on a stack overflow link, that CMAKE_STATIC_LIBRARY_PREFIX was only for linking to libraries, but I see now it is also for linking built libraries. -Original Message- From: Michael Wild [mailto:them...@gmail.com] Sent: Tuesday, November 08, 2011 12:34 AM To: Schuchard, Matthew Cc: cmake@cmake.org Subject: Re: Globally Set Target Properties Sorry, I misread your message. The following works for me: 8-- cmake_minimum_required(VERSION 2.8) project(static) set(CMAKE_STATIC_LIBRARY_PREFIX) add_library(a STATIC a.c) add_library(b STATIC b.c) 8-- Michael On 11/07/2011 05:14 PM, Schuchard, Matthew wrote: Thanks for the response. Actually, that is what I want to do: Specifically, I need to remove the prefix lib from all statically linked libraries I build. Also, I do not have to specify full paths to libraries I link to because of the CMAKE_STATIC_LIBRARY_PREFIX command I had mentioned in the initial message. Do you know if is possible to set global properties of targets like I am trying to? *From:*Schuchard, Matthew *Sent:* Monday, November 07, 2011 11:06 AM *To:* Schuchard, Matthew *Subject:* Globally Set Target Properties On 11/07/2011 04:15 PM, Schuchard, Matthew wrote: /I am trying to globally set target properties for an entire configuration. / // /Specifically, I need to remove the prefix lib from all statically / /linked libraries I build. / // / / // /I already used CMAKE_STATIC_LIBRARY_PREFIX such that all libraries I / /explicitly link to will not have CMake search for libraries of format / /libfoo.a but rather foo.a when I specify foo. / // / / // /However, I cannot seem to globally specify that all target libraries / /which are statically linked which I build have the prefix removed. / // / / // /I have tried set_target_properties with Unix wildcards to no avail. / // /I have also tried set_property(GLOBAL PROPERTY PREFIX ) and / /set_property(TARGET PROPERTY PREFIX ) which were both unsuccessful (or / /maybe I needed to force the cache, but cache was already an argument in / /the usage statement providing other functionality so I assumed its / /normal functionality as an argument was unavailable). / // /Could not find any help on Google either. / // / / // /There is also the possibility this is impossible to do with CMake, so if / /someone can verify that I would also be appreciative. / // *From:**Michael Wild* themiwi at gmail.com mailto:cmake%40cmake.org?Subject=Re%3A%20%5BCMake%5D%20Globally%20Set %20Target%20PropertiesIn-Reply-To=%3C4EB7F7A2.50903%40gmail.com%3E *Sent:* Monday, November 07, 2011 10:56 AM *To:* Schuchard, Matthew *Subject:* Globally Set Target Properties These properties apply to targets *create* by CMake, that's not what you want. In your case, simply specify the absolute path to the library file. E.g. target_link_libraries(bar /usr/lib/foo.a) If you want to use find_library to find these libraries, have a look at CMAKE_FIND_LIBRARY_PREFIXES. HTH Michael -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Generated CMakeLists.txt
On 11/08/2011 03:30 PM, Łukasz Tasz wrote: Hi All, I have one issue connected with generated code. What is recommended way to proceed with generators which provides source which is dynamic? The setup looks like: generator has some input, and depending on this input files are generated. From cmake point of view I need only this list of source files to create library. Generator is providing simple command to generate such a list. During cmake phase, I'm calling generator to generate list.cmake with list of source file, then such a list is included, and configuration is generated. Source file are marked as generated, and appropriate ADD_CUSTOM_COMMAND(OUTPUT list) is registerd. In lifecycle cmake - make - edit-input_files - make - edit ... make everything works smooth with one remark, If you will edit input files in a way that new source file will be introduced, then regeneration is not enough, I need to regenerate configuration, with current approach it looks like: edit-input-adding-new-file - make-step1-generate: will regenerate the code + regenerate cmakelist - since new file is there make-step2-compile-sources: make-step3-linking - will fail since new file is not added to configuration, with next run of make, cmake --check-build-system will recognize changes in cmakelist and configuration will be regenerated, and build will be successfull (if code changes was smart enough:) ) The question is if there are some hooks to cmake --check-build-system that also additionaly my generate --cmake action will be called? (to regenerate cmakelist which holds list of files) Or maybe my approach is wrong? thanks in advance Lukasz If I understand correctly, you need to establish a dependency of the CMakeLists.txt file on the input for the code generator. You might use a CONFIGURE_FILE() command for this purpose, e.g. CONFIGURE_FILE(input.txt input.txt.bak COPYONLY) with input.txt being the code generator's input file. In this way, a change of input.txt outdates the CMakeLists.txt file, and the entire project is reconfigured and rebuilt the next time Make is called. If the machinery works by now when you reconfigure the project by hand, this should do the trick. If not, please come up with a minimal but complete example to show exactly what you are doing at the moment, what does not work and what you'd like to see instead. 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] Multiple platforms/configurations
On 11/08/2011 09:08 PM, Tom Deblauwe wrote: Hello, I have 2 build configurations for the same source code and I am generating visual studio 2005 projects. So for the first configuration I need different defines than for the second configuration. So I do like this: mkdir build1 cd build1 cmake -DPORT=bla ../source mkdir build2 cd build2 cmake -DPORT=foo ../source This generates 2 visual studio 2005 solutions, one in build1 and one in build2. Now there are two project files and two solutions and each has one configuration. However I am porting existing code and the old habit was that the two build configurations were in the same .vcproj and .sln file so you could easily switch between the two configurations in visual studio. Are there any cmake ways to make this happen, so to have one project with all the configs? Best regards, Tom, What exactly do you do with that PORT variable in your CMakeLists.txt file? Perhaps, you might simply map different values to configuration- specific properties like COMPILE_DEFINITIONS_CONFIG. If you do more complicated things based on the PORT variable's value, please provide more information, at best a small but complete example, so we can see whether there is a possibility to set up any comprehensive solution. 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, source_group, and non-existant files with the VS 2010 generator
On 11/08/2011 10:56 PM, Matthew LeRoy wrote:
I've got a question related to the way CMake handles files that are
non-existant
at CMake-time, but which are listed as OUTPUTs of an add_custom_command, and
are
included in a source_group. I'm using CMake 2.8.5 and the Visual Studio 2010
generator.
I have a Python script which reads a .resx file and writes a C header file
containing string constants for each of the resources in the .resx file. I've
implemented this using a custom command in CMake:
find_package(PythonInterp REQUIRED)
add_custom_command(OUTPUT
${CMAKE_CURRENT_BINARY_DIRECTORY}/PropertyNames.h
COMMAND ${PYTHON_EXECUTABLE} ${TableMaker_SOURCE_DIR}/ResXtoCHeader.py
${CMAKE_CURRENT_SOURCE_DIRECTORY}/PropertyMapResources.resx
${CMAKE_CURRENT_BINARY_DIRECTORY}/PropertyNames.h
DEPENDS ${CMAKE_CURRENT_SOURCE_DIRECTORY}/PropertyMapResources.resx
COMMENT Generating PropertyNames.h from PropertyMapResources.resx...)
Then, I've got the file that is generated by the command (PropertyNames.h)
listed in a variable, which is then added to a source_group and included
in the list of sources for a shared library target:
set(Generated_RESOURCES
${CMAKE_CURRENT_BINARY_DIRECTORY}/PropertyNames.h
)
...
source_group(Resource FilesGenerated FILES ${Generated_RESOURCES})
...
add_library(MyLibrary SHARED
${SOURCES}
${HEADERS}
${RESOURCES}
${Generated_RESOURCES}
${Generated_HEADERS}
${Generated_SOURCES}
)
I'm having two problems with this:
1.
When written as above, the .vcxproj file that is generated for the MyLibrary
target references the generated file as:
ClInclude Include=\\PropertyNames.h /
whereas all the other files included in the target are referenced using
absolute
paths on my filesystem. This causes Visual Studio to fail to load the project
at
all, with the following error message:
The item metadata %(FullPath) cannot be applied to the path
\\PropertyNames.h. The UNC path should be of the form \\server\share.
2.
If I change the references to PropertyNames.h in CMakeLists.txt to relative
paths
(i.e. remove ${CMAKE_CURRENT_BINARY_DIRECTORY}), the generated .vcxproj then
references the file using an absolute path, and the project loads
successfully.
The variables referring to the current source/binary directory are
named CMAKE_CURRENT_{SOURCE,BINARY}_DIR, i.e. they do not end in
*_DIRECTORY. Probably, this is the cause for the file's empty
path. Thus, correct it and report if it works.
HOWEVER, even though I've added PropertyNames.h to a source_group, it doesn't
get
placed in the correct folder within the solution explorer; it just shows up
in the automatic Header Files folder in the root of the MyLibrary project.
But, if I build the library (causing the tool the run and actually generate
the
file), then re-run CMake with the generated file actually existing, the file
is
then placed in the correct folder in the project according the source_group.
With VS2008, I recently observed that changes in CMakeLists.txt files
do *not* take effect after cmake --build ., although the build log
mentions that CMake is re-run automatically before the project is
actually rebuilt. In order to enable the changes, I need to run
cmake . first, i.e. reconfigure by hand, as you do. Perhaps, your
issue is related, but I have not made any further investigations yet.
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] debug/optimized include directories
On 11/06/2011 09:27 AM, Michael Wild wrote:
On 11/05/2011 09:59 PM, Michael Hertling wrote:
On 11/02/2011 05:36 PM, Michael Wild wrote:
Thanks ;-)
Michael
Just an additional remark: Instead of generating the proxy headers
in CMakeLists.txt, i.e. at configuration time, one might also have
them generated by a custom command, i.e. at build time, which has
the $CONFIGURATION expression available. E.g., one might use a
CMake script invoked by the custom command via -P with -DCONFIG=
$CONFIGURATION, and within this script, one could do arbitrary
things based on the CONFIG parameter, i.e. linking/copying real
headers, generating proxy headers with or without #ifdefs etc.
In this way, one can gather the entire machinery in the script
and does not need to do the case differentiation in the header
itself, triggered via COMPILE_DEFINITIONS_CONFIG properties.
Besides, with the custom command's DEPENDS clause, the actions
can be set up to re-take place if any prerequisite has changed.
Regards,
Michael
Indeed, that would be a more sophisticated way of doing it, but it
requires maintaining a separate CMake script. Some might consider this
to be a drawback, other an advantage as it declutters the CMakeLists.txt
file.
IMO, the premier advantage of a CMake script handling configuration-
specific tasks at build time is that one can do what can be done in
CMakeLists.txt files only for single-configuration generators:
IF(CONFIG STREQUAL ...)
...
ELSEIF(CONFIG STREQUAL ...)
...
ELSE()
...
ENDIF()
In particular, the ELSE() clause can easily catch configurations - also
custom ones - one doesn't want to handle specifically. In order to do
the same in a CMakeLists.txt file and in a generator-independent way,
one would need to do
FOREACH(i IN LISTS CMAKE_CONFIGURATION_TYPES ITEMS ${CMAKE_BUILD_TYPE})
IF(i STREQUAL ...)
...
ELSEIF(i STREQUAL ...)
...
ELSE()
...
ENDIF()
ENDFOREACH()
and w.r.t. properties like COMPILE_DEFINITIONS_CONFIG, one would need
an additional STRING(TOUPPER ...) because the configurations are named
Debug, e.g., while the property must be named *_DEBUG. Moreover, for
proxy headers, one must essentially still do the case differentiation
again in the header itself, e.g.
#if defined(CONFIG_DEBUG)
#include ...
#elif defined (CONFIG_RELEASE)
#include ...
#else
#include ...
#endif
using additional definitions CONFIG_*, instead of simply saying
#include @...@
in conjunction with CONFIGURE_FILE(... @ONLY) in the CMake script. For
these reasons, I think that CMake scripts triggered by custom commands
are generally more expressive in this regard, but of course, the main
point is that one has the choice.
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 location
On 11/07/2011 05:51 PM, Tomasz Grobelny wrote:
I have a project which is configured in several CMakeLists.txt files. The
problem is that add_custom_command works or doesn't work depending on where
the command is located. If I put add_custom_command just after add_library
then it works fine. Like this:
add_library(mylib SHARED ${SOURCES} ${PRIVATE_HEADERS}
${PUBLIC_HEADERS})
add_custom_command(TARGET mylib POST_BUILD
COMMAND cmd
)
But when I try to do something like this:
CMakeLists.txt
add_directory(src)
add_custom_command(TARGET mylib POST_BUILD
COMMAND cmd
)
src/CMakeLists.txt
add_library(mylib SHARED ${SOURCES} ${PRIVATE_HEADERS}
${PUBLIC_HEADERS})
Then it doesn't work (no error, just cmd is not executed). Why is that?
And what can I do about it? If this is due to target mylib not being
visible in root CMakeLists.txt then is there a way to forward declare it?
And either way: if the command is not going to work anyway then an error
would be expected IMHO.
Custom commands must be defined in the *same* CMakeLists.txt file as
the target(s) they're associated with. This is explicitly documented
for ADD_CUSTOM_COMMAND(OUTPUT ...) but holds for the TARGET flavor,
too. Otherwise, the custom commands are silently ignored. Possibly,
the latter case should indeed issue a warning -- feature request?
If you need to have a custom command in another CMakeLists.txt as
the concerned target(s), you must use a custom target to trigger
the custom command and ADD_DEPENDENCIES() to establish the
targets' correct build 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] get name of .lib file
On 11/07/2011 05:55 PM, Tomasz Grobelny wrote:
Thanks. But it still means that I have to construct the .lib file name
sort of manually. And possibly put some IF(WIN32)'s in my CMakeLists.txt. I
would much prefer to have a list of all files that were produced by given
target.
Getting such a list at configuration time is particularly difficult,
and the LOCATION property is considered obsolete, AFAIK, and might
have subtle side effects, see [1].
If it's sufficient for you to get that list at build time, I could
offer the following approach: Set the concerned target's diverse
*_OUTPUT_DIRECTORY properties to a target-specific directory; the
latter can be accessed via the $TARGET_FILE_DIR:target generator
expression within a custom command that passes this directory to a
CMake script which collects all files by FILE(GLOB ...) and writes
the resulting list to a file. Alternatively, you could treat these
files in the custom command immediately as you will. See here:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(FILELIST C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/files)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(f STATIC f.c)
SET_TARGET_PROPERTIES(f PROPERTIES
ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/files/f
RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/files/f
LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/files/f)
ADD_CUSTOM_COMMAND(TARGET f POST_BUILD
COMMAND ${CMAKE_COMMAND}
-DDIR=$TARGET_FILE_DIR:f
-DFILE=${CMAKE_BINARY_DIR}/f.txt
-P ${CMAKE_SOURCE_DIR}/filelist.cmake
COMMENT Writing file list for f)
FILE(WRITE ${CMAKE_BINARY_DIR}/g.c void g(void){}\n)
ADD_LIBRARY(g SHARED g.c)
SET_TARGET_PROPERTIES(g PROPERTIES
ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/files/g
RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/files/g
LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/files/g)
ADD_CUSTOM_COMMAND(TARGET g POST_BUILD
COMMAND ${CMAKE_COMMAND}
-DDIR=$TARGET_FILE_DIR:g
-DFILE=${CMAKE_BINARY_DIR}/g.txt
-P ${CMAKE_SOURCE_DIR}/filelist.cmake
COMMENT Writing file list for g)
# filelist.cmake:
FILE(GLOB FILES ${DIR}/*)
FILE(WRITE ${FILE})
FOREACH(i IN LISTS FILES)
FILE(APPEND ${FILE} ${i}\n)
ENDFOREACH()
After configuring and building, there're {f,g}.txt with the file lists.
'hope that helps.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg33669.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] Globally Set Target Properties
On 11/07/2011 05:14 PM, Schuchard, Matthew wrote:
Thanks for the response.
Actually, that is what I want to do:
Specifically, I need to remove the prefix lib from all statically
linked libraries I build.
Also, I do not have to specify full paths to libraries I link to because of
the CMAKE_STATIC_LIBRARY_PREFIX command I had mentioned in the initial
message.
Do you know if is possible to set global properties of targets like I am
trying to?
AFAIK, that's not possible, but you might use a tailored version of
ADD_LIBRARY(), e.g. ADD_STATIC_LIBRARY(), that cares about PREFIX:
FUNCTION(ADD_STATIC_LIBARY TARGET)
ADD_LIBRARY(${TARGET} STATIC ${ARGN})
SET_TARGET_PROPERTIES(${TARGET} PROPERTIES PREFIX )
ENDFUNCTION()
You might even overwrite the ADD_LIBRARY() command itself:
FUNCTION(ADD_LIBRARY)
_ADD_LIBRARY(${ARGN})
IF(ARGV1 STREQUAL STATIC)
SET_TARGET_PROPERTIES(${ARGV0} PROPERTIES PREFIX )
ENDIF()
ENDFUNCTION()
If you use the latter, note than one can build a static library without
passing the STATIC flag to ADD_LIBRARY(), refer to BUILD_SHARED_LIBS.
Furthermore, overwriting a CMake built-in function only works once.
'hope that helps.
Regards,
Michael
From: Schuchard, Matthew
Sent: Monday, November 07, 2011 11:06 AM
To: Schuchard, Matthew
Subject: Globally Set Target Properties
On 11/07/2011 04:15 PM, Schuchard, Matthew wrote:
I am trying to globally set target properties for an entire configuration.
Specifically, I need to remove the prefix lib from all statically
linked libraries I build.
I already used CMAKE_STATIC_LIBRARY_PREFIX such that all libraries I
explicitly link to will not have CMake search for libraries of format
libfoo.a but rather foo.a when I specify foo.
However, I cannot seem to globally specify that all target libraries
which are statically linked which I build have the prefix removed.
I have tried set_target_properties with Unix wildcards to no avail.
I have also tried set_property(GLOBAL PROPERTY PREFIX ) and
set_property(TARGET PROPERTY PREFIX ) which were both unsuccessful (or
maybe I needed to force the cache, but cache was already an argument in
the usage statement providing other functionality so I assumed its
normal functionality as an argument was unavailable).
Could not find any help on Google either.
There is also the possibility this is impossible to do with CMake, so if
someone can verify that I would also be appreciative.
From: Michael Wild themiwi at gmail.com
mailto:cmake%40cmake.org?Subject=Re%3A%20%5BCMake%5D%20Globally%20Set%20Target%20PropertiesIn-Reply-To=%3C4EB7F7A2.50903%40gmail.com%3E
Sent: Monday, November 07, 2011 10:56 AM
To: Schuchard, Matthew
Subject: Globally Set Target Properties
These properties apply to targets *create* by CMake, that's not what you
want. In your case, simply specify the absolute path to the library
file. E.g.
target_link_libraries(bar /usr/lib/foo.a)
If you want to use find_library to find these libraries, have a look at
CMAKE_FIND_LIBRARY_PREFIXES.
HTH
Michael
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] find_package(), sources only
On 11/07/2011 03:26 PM, Hendrik Sattler wrote:
Am 07.11.2011 14:49, schrieb Daniel Dekkers:
Hi Hendrik,
Could you write a few more lines. I want to understand,... but I
don't. ;-)
We only have one copy of Bullet as a bundle present on the system.
Let's
say you just downloaded Bullet.
With BULLET_ROOT, we set the root path to that copy and do a
find_package(BULLET), it returns with:
[...]
MESSAGE( STATUS Looking for Bullet... )
SET(BULLET_ROOT ${DEVELOPMENT_ROOT}/bullet CACHE PATH Root directory
for
Bullet)
FIND_PACKAGE( BULLET REQUIRED )
So you link to Bullet libraries but build the libraries yourself? Then
use external_project.
You list the Bullet source files as sources in add_executable or
add_library? Then don't use find_package but instead just check for the
include file yourself using find_path.
The find_package() stuff is mostly targetted for externally built
packages.
Absolutely. Note there're packages with header trees looking quite
differently in the source distribution and after the installation.
There're even packages without any header tree at all, since the
latter is assembled immediately before the compilation, i.e.
after the configuration.
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() twice = Policy CMP0013 is not set: Duplicate binary directories are not allowed
On 11/04/2011 06:39 PM, Paul Hansen wrote: Hi I have several small projects. Some of them may include another project. I have one big project that includes all small projects. File structure: projects - p1.cmake (add_subdirectory(dir_project1)) - p2.cmake (add_subdirectory(dir_project2)) - dir_project1 - dir_project2 Some of these pX.cmake may be called twice meaning that add_subdirectory(dir_projectX) is called twice. And the above warning appears. Is there a way to handle this. E.g - with guards like in C header files (tried something like that but did not work) - checking if the resulting library exists, if yes: don't add:subdirectory() Just wandering if there is a defacto or smart way to handle that a subproject may be included several times Thanks Paul Recently, there has been an interesting discussion about some related topics that affects this particular one, too; see [1]. Regards, Michael [1] http://www.mail-archive.com/cmake@cmake.org/msg38990.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] install export : ignore imported_link_interface_libraries and imported_link_dependents_libraries
On 11/02/2011 04:19 PM, Jaonary Rabarisoa wrote:
Hi all,
I'm using the command install(EXPORT ) to create a configuration file for
my project. This works great but by default
cmake fills the IMPORTED_LINK_INTERFACE_LIBRARIES and
IMPORTED_LINK_DEPENDENTS_LIBRARIES. I'd like cmake
to ignore these properties because it introduces a hard link to my build
machine. For example, it output a hard to boost libraries, which
are in fact use in may project.
So is there a way to tell cmake to ignore these properties while exporting
a target ?
Best regards,
Jaonary
You might empty the LINK_INTERFACE_LIBRARIES target property:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(LINKLIBS CXX)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FIND_PACKAGE(Boost COMPONENTS date_time)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.cxx void f(void){}\n)
ADD_LIBRARY(f SHARED f.cxx)
TARGET_LINK_LIBRARIES(f ${Boost_LIBRARIES})
SET_TARGET_PROPERTIES(f PROPERTIES LINK_INTERFACE_LIBRARIES )
INSTALL(TARGETS f EXPORT f DESTINATION lib)
INSTALL(EXPORT f DESTINATION share)
This installs an export file f-noconfig.cmake containing
SET_TARGET_PROPERTIES(f PROPERTIES
IMPORTED_LOCATION_NOCONFIG ${_IMPORT_PREFIX}/lib/libf.so
IMPORTED_SONAME_NOCONFIG libf.so
)
without any IMPORTED_LINK_{INTERFACE,DEPENDENT}_LIBRARIES properties.
Note that Boost won't be transitively respected anymore for targets
linked against f, neither in your project nor in others importing
the export file.
This approach works for shared libraries only. If you need to do the
same for a static library, you might use a trick with reimportation:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(LINKLIBS CXX)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FIND_PACKAGE(Boost COMPONENTS date_time)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.cxx void f(void){}\n)
ADD_LIBRARY(f STATIC f.cxx)
EXPORT(TARGETS f FILE reimportedf.cmake NAMESPACE reimported)
INCLUDE(${CMAKE_BINARY_DIR}/reimportedf.cmake)
SET_TARGET_PROPERTIES(reimportedf PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES ${Boost_LIBRARIES})
INSTALL(TARGETS f EXPORT f DESTINATION lib)
INSTALL(EXPORT f DESTINATION share)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.cxx int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.cxx)
TARGET_LINK_LIBRARIES(main reimportedf)
The target f is the static library which has a dependency on Boost
you don't want to appear in the export file; thus, you mustn't link f
against Boost. In order to have that dependency resolved for binaries
linking against f within your project, f is effectively duplicated as
a (re)imported target reimportedf with the necessary dependency set
in its IMPORTED_LINK_INTERFACE_LIBRARIES property, and it is that re-
importedf library your project's binaries need to be linked against.
You can see this with the main target linking against libf.a and
Boost, whereas the installed f-noconfig.cmake export file doesn't
contain any references to Boost anymore. Possibly, the same could
be done to address the above-mentioned issue with the transitive
inner-project dependency on Boost with shared libraries.
Just an additional remark: The files installed by INSTALL(EXPORT ...)
describe the installed targets' dependencies on the system where the
installation has taken place; using these files on another system
within a different environment is usually a rather bad idea.
'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] transitive link flags
On 11/06/2011 07:04 PM, Luke Dalessandro wrote:
Hi everyone,
I have a static library target that has some sources that rely on link-time
symbol interposition.
Is there an existing way to set transitive link flags of the
-Wl,--wrap,symbol variety on the library target so that executables that
depend on the library are automatically linked correctly?
Thanks,
Luke
AFAIK, there's currently no immediate possibility to achieve this goal
- a target property or the like - but you can use the trick with a
reimported empty static library; see the following example:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(WRAP C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/empty.c )
ADD_LIBRARY(empty STATIC empty.c)
EXPORT(TARGETS empty NAMESPACE imported FILE importedempty.cmake)
INCLUDE(${CMAKE_BINARY_DIR}/importedempty.cmake)
SET_TARGET_PROPERTIES(importedempty PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES -Wl,--wrap,malloc)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c
#include stdio.h
#include stdlib.h
void *__wrap_malloc(size_t n)
{
printf(\malloc()\\n\); return __real_malloc(n);
}\n)
ADD_LIBRARY(f STATIC f.c)
TARGET_LINK_LIBRARIES(f importedempty)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c
int main(void){void *p=malloc(1); return 0;}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main f)
The library f with the symbol(s) to be wrapped is linked against a
reimported empty static library which pulls in the required --wrap
flag(s) via its IMPORTED_LINK_INTERFACE_LIBRARIES target property.
The latter does not exists for ordinary static libraries, but
linking against an empty one doesn't do any harm.
Perhaps, this is worth a feature request, e.g. a new target property,
say, TRANSITIVE_LINK_FLAGS[_CONFIG] which are added to the linker
command if a binary is linked against the respective library.
'hope that helps.
Regards,
Michael
@Łukasz: Please don't drop the ML.
--
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() with a higher level directory
On 11/06/2011 07:49 PM, J Decker wrote: Of course, the CMakeLists.txt in examples (or example0 and example1) depends on the actual library, so, from that level, we would like to call ADD_SUBDIRECTORY() to the *higher level* library directory... which is unacceptable for ADD_SUBDIRECTORY() (and probably conflicts with the whole CMake structure). If we would move examples up the hierarchy there wouldn't be a problem, but that doesn't give a nice distribution package. Any hints on a proper way to do this? I include higher level projects all over; you just have to specify an additional directory which is where that is built in the final output so you can do add_subdirectory( ../../whatever/example __/__/whatever/example) which builds into the __/__ path in the build directory... The explicit build directory for ADD_SUBDIRECTORY() is not the actual problem; the problems which arise with this practice are rather, IMO: (1) Without a top-level CMakeLists.txt, you've usually no bullet-proof information about the other project's location, e.g. you can not refer to CMAKE_SOURCE_DIR or the like. Instead, you must use a relative path upwards from CMAKE_CURRENT_SOURCE_DIR like ../../whatever/example, and the ../.. is a hard-coded assumption on the other project's relative location w.r.t. the current project one's. If the latter or the other project is once moved, this assumption proves wrong, and you will have to edit possibly quite numerous ADD_SUBDIRECTORY() commands to fix up things. Alternatively, you might provide the other project's location via a cached variable, preferably with a reasonable default value. (2) If you additionally have an overall project as an entry point for the configuration, the other project's CMakeLists.txt file might have already been processed via an ADD_SUBDIRECTORY() command on behalf of the overall project, so you must ensure that your current project's CMakeLists.txt file doesn't invoke ADD_SUBDIRECTORY() on the other one's source tree again. Both problems can be easily avoided if one does strictly organize the projects in a top-down manner with a top-level CMakeLists.txt as the sole entry point for the configuration. So, each CMakeLists.txt file except for the top-level one is processed by one ADD_SUBDIRECTORY() only, and you don't have to process any higher-level CMakeLists.txt file because the superordinate one takes care of the correct order. In other words: If a project uses ADD_SUBDIRECTORY() on a project's directory other than a descendent one, this usually indicates that these projects are tightly coupled parts of an overall project, so it should be the job of the overall project's CMakeLists.txt to call - or have call - the sub-projects' CMakeLists.txt files in a correct order. Hence, each sub-project can be sure that all its prerequisite projects have been configured before. OTOH, if two projects are not tightly coupled parts of the same overall project, the one should not invoke ADD_SUBDIRECTORY() on the other, but FIND_PACKAGE(). Note that the above-mentioned points are just my personal liking; certainly, there are different opinions, and there might very well be setups which require a different approach. 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() with a higher level directory
On 11/06/2011 04:47 PM, Dan Kegel wrote:
On Sun, Nov 6, 2011 at 7:27 AM, Daniel Dekkers d.dekk...@cthrough.nl wrote:
This template stuff should really be in the documentation, it would have
helped me a lot.
More than http://www.cmake.org/cmake/help/examples.html. A library called
Hello, really?
FWIW, I'm gathering more examples at
http://code.google.com/p/winezeug/source/browse/#svn/trunk/cmake_examples
I'm also facing questions of how to organize cmake builds for
existing software, but haven't added any examples about that yet;
the examples I have are simple things (how to use gtest, how
to use eclipse, etc.)
In my case, the existing software consists of a bunch of
libraries and programs currently living in their own versioned svn
directories, e.g.
libfoo/releases/1.1/src/...
libbar/trunk/src/...
baz/releases/1.0/src/...
and all the developers check those directories out into unversioned
directories on local disk, e.g.
libfoo/src/...
libbar/src/...
baz/src/...
There's simply no top level directory where one could put an enclosing
CMakeLists.txt!
I can't reorganize the source tree on the developers,
so I'm making do by putting the enclosing CMakeLists.txt next to all
the projects:
toplevel/trunk/CMakeLists.txt
which is checked out to
toplevel/CMakeLists.txt
It does
add_subdirectory(../libfoo libfoo)
add_subdirectory(../libbar libbar)
add_subdirectory(../baz baz)
This has the possible advantage that one can have multiple
top levels (say, one for server code, and one for client).
I don't know how many shops suffer from this svn layout, but I'll probably
add an example covering it anyway for completeness once I'm sure
it doesn't explode in practice.
- Dan
If I understand correctly, your overall project comprises several sub-
projects with source trees not residing beneath the overall project's
PROJECT_SOURCE_DIR, but scattered across the file system instead, as
they stem from different repositories; additionally, this possibly
varies from user to user, right? If so, I'd advise the following:
Provide a top-level project - as you do - with the regular top-down
hierarchy, e.g. core, core/src, examples, examples/examplen etc.,
use ADD_SUBDIRECTORY() to traverse the hierarchy as usual, and when
you'd enter a sub-project's source tree - which is not present - use
a cached variable pointing at the source tree's location and a local
build directory. E.g., the following overall project X comprises the
sub-projects A and B with B depending on A; suppose that A and B are
*no* descendants of X, thus X/CMakeLists.txt can not process {A,B}/
CMakeLists.txt with ADD_SUBDIRECTORY({A,B}). Additionally, X has an
actual subdirectory util with an executable which depends on B:
# A/CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(A C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${PROJECT_BINARY_DIR}/a.c void a(void){}\n)
ADD_LIBRARY(a SHARED a.c)
# B/CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(B C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${PROJECT_BINARY_DIR}/b.c void b(void){}\n)
ADD_LIBRARY(b SHARED b.c)
TARGET_LINK_LIBRARIES(b a)
# X/util/CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(UTIL C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${PROJECT_BINARY_DIR}/util.c int main(void){return 0;}\n)
ADD_EXECUTABLE(util util.c)
TARGET_LINK_LIBRARIES(util b)
# X/CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(X C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(A_EXTERNAL_SOURCE_DIR ${PROJECT_SOURCE_DIR}/A CACHE PATH A)
SET(B_EXTERNAL_SOURCE_DIR ${PROJECT_SOURCE_DIR}/B CACHE PATH B)
ADD_SUBDIRECTORY(${A_EXTERNAL_SOURCE_DIR} A)
ADD_SUBDIRECTORY(${B_EXTERNAL_SOURCE_DIR} B)
ADD_SUBDIRECTORY(util)
The A and B projects' locations are provided by the cached variables
{A,B}_EXTERNAL_SOURCE_DIR that are preset as if A,B reside beneath X,
i.e. the, say, regular case. In order to build the project, the user
must just configure it with {A,B}_EXTERNAL_SOURCE_DIR set correctly
on the command line or the GUI, and everything else works as usual.
Note that the overall project X's logical organization is *exactly*
the same as in the regular case with A,B underneath X. Particularly,
there is no need for B to configure A with ADD_SUBDIRECTORY(../A) in
B/CMakeLists.txt or the like, no need to start the configuration with
anything else than the top-level CMakeLists.txt, no need to protect an
ADD_SUBDIRECTORY() command from being processed more than once, and...
no hard-coded assumptions on any part's location. The downside is that
you must provide the external locations, but this could be done rather
easily, e.g. via the -C option, and it could even be done individually
for each developer and also for multiple checked-out working copies of
the same sub-project. IMO, this is a somewhat appropriate solution for
an overall project - call it logical - with non-treelike code base.
Re: [CMake] ADD_SUBDIRECTORY() with a higher level directory
On 11/07/2011 04:55 AM, J Decker wrote: On Sun, Nov 6, 2011 at 5:23 PM, Michael Hertling mhertl...@online.de wrote: On 11/06/2011 07:49 PM, J Decker wrote: Of course, the CMakeLists.txt in examples (or example0 and example1) depends on the actual library, so, from that level, we would like to call ADD_SUBDIRECTORY() to the *higher level* library directory... which is unacceptable for ADD_SUBDIRECTORY() (and probably conflicts with the whole CMake structure). If we would move examples up the hierarchy there wouldn't be a problem, but that doesn't give a nice distribution package. Any hints on a proper way to do this? I include higher level projects all over; you just have to specify an additional directory which is where that is built in the final output so you can do add_subdirectory( ../../whatever/example __/__/whatever/example) which builds into the __/__ path in the build directory... The explicit build directory for ADD_SUBDIRECTORY() is not the actual problem; the problems which arise with this practice are rather, IMO: (1) Without a top-level CMakeLists.txt, you've usually no bullet-proof information about the other project's location, e.g. you can not refer to CMAKE_SOURCE_DIR or the like. Instead, you must use a relative path upwards from CMAKE_CURRENT_SOURCE_DIR like ../../whatever/example, and the ../.. is a hard-coded assumption on the other project's relative location w.r.t. the current project one's. If the latter or the other project is once moved, this assumption proves wrong, and you will have to edit possibly quite numerous ADD_SUBDIRECTORY() commands to fix up things. Alternatively, you might provide the other project's location via a cached variable, preferably with a reasonable default value. Thats true even if you change where a project is in a forward going direction. Suppose your project consists of a library and n sub-projects which refer to the library by ADD_SUBDIRECTORY(path/to/library), cf. the OP's original concern. If the library is moved within the overall project, you need to edit n ADD_SUBDIRECTORY() commands, whereas in the strict top-down case with exactly one ADD_SUBDIRECTORY() command for each CMakeLists.txt file except for the top-level one, you usually need to edit at most two CMakeLists.txt files; this is what I've meant. (2) If you additionally have an overall project as an entry point for the configuration, the other project's CMakeLists.txt file might have already been processed via an ADD_SUBDIRECTORY() command on behalf of the overall project, so you must ensure that your current project's CMakeLists.txt file doesn't invoke ADD_SUBDIRECTORY() on the other one's source tree again. Both problems can be easily avoided if one does strictly organize the projects in a top-down manner with a top-level CMakeLists.txt as the sole entry point for the configuration. So, each CMakeLists.txt file except for the top-level one is processed by one ADD_SUBDIRECTORY() only, and you don't have to process any higher-level CMakeLists.txt file because the superordinate one takes care of the correct order. So, by not having the problem in the first place, is your solution? Do you mean the best solution of a problem is its avoidance? ;-) But seriously, I am not sure if I got your objection correctly. In short, my point is the following: If X calls ADD_SUBDIRECTORY(path/to/Y) and Y isn't a sub-project of X, they're sibling projects within an overall project; perhaps, one could say they share the same target space. Then, no one should configure the other by ADD_SUBDIRECTORY(). Rather, there should be a superordinate CMakeLists.txt calling ADD_SUBDIRECTORY() on X and Y in the correct order, so that X can be sure that Y is already configured. In this way, there is only one ADD_SUBDIRECTORY() command for each CMakeLists.txt file, except for the top-level one, and each ADD_SUBDIRECTORY() does actually enter a *sub*directory - no problem with a sibling project's location, and none with multiply processed CMakeLists.txt files. However, there might be exceptions, see [1]. Regards, Michael [1] http://www.mail-archive.com/cmake@cmake.org/msg39062.html In other words: If a project uses ADD_SUBDIRECTORY() on a project's directory other than a descendent one, this usually indicates that these projects are tightly coupled parts of an overall project, so it should be the job of the overall project's CMakeLists.txt to call - or have call - the sub-projects' CMakeLists.txt files in a correct order. Hence, each sub-project can be sure that all its prerequisite projects have been configured before. OTOH, if two projects are not tightly coupled parts of the same overall project, the one should not invoke ADD_SUBDIRECTORY() on the other, but FIND_PACKAGE(). Note that the above-mentioned points are just my personal liking; certainly, there are different opinions, and there might very well be setups which require a different
Re: [CMake] NOT operator gotchas for newbies
On 11/05/2011 03:24 AM, Dan Kegel wrote:
On Fri, Nov 4, 2011 at 6:09 PM, Michael Hertling mhertl...@online.de wrote:
NOT isn't a constant but a boolean operator like AND/OR/EXISTS etc.,
and none of the latters is case-sensitive at the moment, so why
should NOT be the sole exception?
Right, I meant to suggest the other operators should be
case insensitive, too. Isn't that the general direction cmake
has been going?
Not that I know of; the commands are case-insensitive, but the sub-
commands/clauses/switches/flags or however they're to name must be
uppercase with only a few exceptions, e.g. debug/optimzed/general
in TARGET_LINK_LIBRARIES(). However, the latters are obsolete in
favor of imported targets anyway.
Also, people who mistakenly use !foo instead of NOT foo
get a surprise: the result is always silently false.
It might be nice to catch this possibly common error
and output an error message.
!foo seems to be a valid indentifier for a variable ...
Besides the fact that you can not refer to it via ${!foo}, it's highly
inadvisable to name a variable in this way, of course. Anyway, if one
considers to introduce ! as an equivalent for NOT,
I was proposing instead to output a good error message
in this case, not to support ! as a synonym for NOT.
Even then, you'd need to be consistent and warn about the other
C-style operators like or ||, too, which might also be
used accidentally.
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] debug/optimized include directories
On 11/02/2011 05:36 PM, Michael Wild wrote:
Thanks ;-)
Michael
Just an additional remark: Instead of generating the proxy headers
in CMakeLists.txt, i.e. at configuration time, one might also have
them generated by a custom command, i.e. at build time, which has
the $CONFIGURATION expression available. E.g., one might use a
CMake script invoked by the custom command via -P with -DCONFIG=
$CONFIGURATION, and within this script, one could do arbitrary
things based on the CONFIG parameter, i.e. linking/copying real
headers, generating proxy headers with or without #ifdefs etc.
In this way, one can gather the entire machinery in the script
and does not need to do the case differentiation in the header
itself, triggered via COMPILE_DEFINITIONS_CONFIG properties.
Besides, with the custom command's DEPENDS clause, the actions
can be set up to re-take place if any prerequisite has changed.
Regards,
Michael
On 11/02/2011 05:33 PM, Robert Dailey wrote:
Awesome idea, +1
This is probably the best work-around until includes get a target property.
-
Robert Dailey
On Wed, Nov 2, 2011 at 2:43 AM, Michael Wild them...@gmail.com
mailto:them...@gmail.com wrote:
On 11/01/2011 09:49 PM, Robert Dailey wrote:
Well if you need any help coding the feature let me know. I'm already
liking the idea of adding features I want myself into CMake :)
Thanks!
-
Robert Dailey
On Tue, Nov 1, 2011 at 3:47 PM, David Cole david.c...@kitware.com
mailto:david.c...@kitware.com
mailto:david.c...@kitware.com mailto:david.c...@kitware.com
wrote:
On Tue, Nov 1, 2011 at 4:33 PM, Robert Dailey
rcdai...@gmail.com mailto:rcdai...@gmail.com
mailto:rcdai...@gmail.com mailto:rcdai...@gmail.com wrote:
On Tue, Nov 1, 2011 at 3:32 PM, David Cole
david.c...@kitware.com mailto:david.c...@kitware.com
mailto:david.c...@kitware.com
mailto:david.c...@kitware.com wrote:
Not yet
Meaning there are plans in the works to add such
functionality in
the near
future?
For now I guess I could actually hard code VS environment
variables in my
include directory strings, such as $(Configuration).
There is a feature planned to add per-target include
directories (as a
target property). As part of that work, we will probably naturally
also add per-configuration values of that new target property.
It is
not yet added as a feature request in the bug tracker, but
there are
related ones that I may borrow for the purpose. Stay tuned
for more
info, but it is not coming in the next week or two. Hopefully,
in time
for 2.8.7, but it depends on timing at this point so no
promises.
For now, your $(Configuration) idea is probably your best bet.
(And
would continue to work even after we implement this feature...)
HTH,
David
Alternatively, if you want to keep it cross-platform and generator
independent, you could use a proxy header which #include's the correct
header using relative or absolute paths using #ifdef's. Probably that
proxy header would need to be generated by configure_file(). You then
would pass the configuration name by setting the
COMPILE_DEFINITIONS_CONFIG property on the directory, target or source
file affected.
Say you have the following layout:
project/
|-- CMakeLists.txt
|-- src/
| |-- frobnicate.c
`-- include/
|-- Debug/
| |-- foo.h
| `-- bar.h
`-- Optimized/
|-- foo.h
`-- bar.h
Now, you want to include the configuration dependent foo.h and bar.h in
frobnicate.c without having to change frobnicate.c itself and might look
like this:
frobnicate.c
#include foo.h
#include bar.h
int main(int argc, char** argv)
{
foo();
bar();
return 0;
}
To get around the issue of needing a configuration-dependent include
path, you could do the following in your CMakeLists.txt file:
CMakeLists.txt:
cmake_minimum_required(VERSION 2.6)
project(frobnicate C)
# loads of stuff
# generate wrapper headers for foo.h and bar.h
foreach(hdr foo.h bar.h)
# find a good include guard name
string(TOUPPER ${hdr} incguard)
string(REGEX REPLACE [^a-zA-Z0-9_] _ incguard
PROXY_HDR_${incguard})
# write the proxy header
file(WRITE ${PROJECT_BINARY_DIR}/include/${hdr}
/* AUTOMATICALLY GENERATED BY CMAKE -- DO NOT EDIT! */
#pragma once
#ifndef ${incguard}
#define ${incguard}
/* if building debug configuration, include Debug/${hdr},
otherwise
Re: [CMake] ADD_SUBDIRECTORY() with a higher level directory
...@cmake.org] Namens Michael Hertling Verzonden: vrijdag 4 november 2011 1:03 Aan: cmake@cmake.org Onderwerp: Re: [CMake] ADD_SUBDIRECTORY() with a higher level directory On 11/03/2011 09:10 PM, Daniel Dekkers wrote: Hi, We are creating a directory structure for distribution of an open-source library with examples included. It looks something like this: + library - the root directory CMakeLists.txt - create context for building (only) the library + src - contains the sources of the library CMakeLists.txt - actually add sources for (only) the library + examples CMakeLists.txt - create context for building all the examples (and the library, once) + example0 CMakeLists.txt - create context for building example0 (and the library) + src CMakeLists.txt - add sources for example0 + rsrc + example1 CMakeLists.txt - create context for building example1 (and the library) + src CMakeLists.txt - add sources for example1 + rsrc + ... The CMakeLists.txt in library, library/examples and library/examples/example0 and library/examples/example1 should all be possible entry points for a build. Maybe you want to build only the library, maybe you want to build the whole example suite, or maybe an individual example. Of course, the CMakeLists.txt in examples (or example0 and example1) depends on the actual library, so, from that level, we would like to call ADD_SUBDIRECTORY() to the *higher level* library directory... which is unacceptable for ADD_SUBDIRECTORY() (and probably conflicts with the whole CMake structure). If we would move examples up the hierarchy there wouldn't be a problem, but that doesn't give a nice distribution package. Any hints on a proper way to do this? Kind Regards, Daniel Dekkers IMO, you should set up your overall project roughly as usual, i.e.: library/CMakeLists.txt: ADD_SUBDIRECTORY(src) ADD_SUBDIRECTORY(examples) library/examples/CMakeLists.txt: SET_DIRECTORY_PROPERTIES(PROPERTIES EXCLUDE_FROM_ALL TRUE) ADD_SUBDIRECTORY(example0) ADD_SUBDIRECTORY(example1) ... ADD_CUSTOM_TARGET(examples) ADD_DEPENDENCIES(examples example0 example1 ...) library/examples/example0/CMakeLists.txt: TARGET_LINK_LIBRARIES(example0 library) In this way, you will have all dependencies set up correctly, and the examples are not built on behalf of make or make all. In order to build them, you might trigger the examples target or any individual examplei target, or you can jump into a target's directory under- neath CMAKE_BINARY_DIR and issue make from within there. However, you don't have an automatic target anymore to build everything, so you would need to provide one on your own, e.g.: library/CMakeLists.txt: ADD_CUSTOM_TARGET(world) ADD_DEPENDENCIES(world library examples) If you want to exclude unwanted parts of your project already from the configuration, you can use appropriate OPTION() commands and surround the ADD_SUBDIRECTORY() commands by IF(option)...ENDIF(). Note that you will have to handle the dependencies of your project's parts by yourself in this case, i.e. you can't disable ADD_SUBDIRECTORY(src) while enabling ADD_SUBDIRECTORY(examples) in library/CMakeLists.txt. 'hope that helps. Regards, Michael PS: Please don't hijack foreign threads. -- 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 can I run tests using a wrapper script
On 11/04/2011 10:13 PM, EXT-York, Gantry wrote: I'm new to cmake. I'm trying to define some unit tests in CMakeLists.txt.I need to run utest1, utest2, utest3 and so forth, but I need to run them through a wrapper script called run_utest. run_utest is used to intercept some output and report it to a website. We do not use cdash. I'm trying to do this with the add_executable( utest1 ) add_test( NAME utest1 COMMAND /fully/qualified/path/run_utest --report utest1 ) The problem is that the add_test command treats run_utest as the command but the following arguments are treated as arguments. ctest -V even shows that they are quoted. utest1 does not get treated as if it is an executable. So what I get is /fully/qualified/path/run_utest -report utest1 instead of /fully/qualified/path/run_utest -report /path/to/utuest1 Needless to say it won't run. ADD_TEST() expands only the actual COMMAND w.r.t. an executable's full path but not the COMMAND's arguments. However, you might use generator expressions for this purpose: ADD_EXECUTABLE(utest1) ADD_TEST(NAME utest1 COMMAND /fully/qualified/path/run_utest --report $TARGET_FILE:utest1) '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] Undefined reference
On 11/04/2011 12:50 AM, Dan Kegel wrote:
On Thu, Nov 3, 2011 at 4:16 PM, Michael Hertling mhertl...@online.de wrote:
Static linking of glibc is not really supported; IIRC glibc's
DNS and localization support use shared libraries under
the hood, even when you ask for static linking
[statically linked utilities are essential for disaster recovery and during
boot]
During boot, I think it's common practice to link against klibc,
which totally supports static linking.
And I agree, a statically linked busybox is a wonderful thing.
AFAIK, klibc is even targeted at the Linux early user space; OTOH,
the FAQ of BusyBox states that it is not suitable for the latter.
Instead, uClibc is preferred as a replacement for glibc, but I
have tried neither the one nor the other yet.
So, what do you mean when saying static linking
against glibc is not really supported? Do you refer to particular
systems or special setups? Could you provide an example?
No special system or setup. See
http://www.akkadia.org/drepper/no_static_linking.html
http://stackoverflow.com/questions/3430400/linux-static-linking-is-dead
http://sourceware.org/bugzilla/show_bug.cgi?id=631
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1044
glibc decided many years ago to focus only on systems that
supported dynamic linking, and to require its use.
Now, I see what you mean with under the hood. ;) You're absolutely
right that for non-trivial programs not written with static linking
against glibc in mind, the latter is quite impossible. Indeed, this
might be the cause of the OP's problems. Nevertheless, if you don't
refer to any of the affected symbols - most notably the NSS stuff -
or do provide drop-in replacements for them, a self-contained static
linking against glibc should still be feasible. E.g., mdadm's static
target compiles the additional file pwgr.c with an implementation of
get{pw,gr}nam(), two critical functions. However, I have not tried
static linking against glibc for some time, and at the moment, I
can't perform a rigorous test since I've no glibc-based system
at hand which I could endanger, so correct me if I'm wrong.
Not a popular decision, but the glibc maintainer has some rather strong
opinions.
Yes, but UD's opinions have inspired the development of related
projects, so we've a wider choice of C libraries nowadays. ;-)
@Mauricio: Could you build your project statically with a somewhat
recent gcc as the latter warns when you use critical functions, i.e.
functions that require a dl_open'ing of shared libraries by libc.a?
If this turns out to be the issue, you might try to use a different
C library like the already mentioned klibc or uClibc, but note that
exchanging binaries among *unices won't work unless the systems are
sufficiently compatible, e.g. Linux 2.4 -- 2.6 will probably fail.
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] NOT operator gotchas for newbies
On 11/04/2011 11:22 PM, Dan Kegel wrote:
I just ran into two little newbie problems having to do with booleans.
CMP0012 made various boolean constants case insensitive,
but NOT is still case sensitive.
If you use it in lowercase, you get the warning
CMake Warning (dev) at CMakeLists.txt:2 (if):
given arguments:
not foo
Unknown arguments specified
That's fairly clear, and anyone who's been around cmake will
suspect that uppercase is required.
Still, it might be nice to accept lowercase not at some point.
NOT isn't a constant but a boolean operator like AND/OR/EXISTS etc.,
and none of the latters is case-sensitive at the moment, so why
should NOT be the sole exception?
Also, people who mistakenly use !foo instead of NOT foo
get a surprise: the result is always silently false.
It might be nice to catch this possibly common error
and output an error message.
!foo seems to be a valid indentifier for a variable:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(FOO NONE)
SET(!foo bar)
GET_DIRECTORY_PROPERTY(VARS VARIABLES)
MESSAGE(VARS: ${VARS})
IF(!foo STREQUAL bar)
MESSAGE(!foor==bar)
ELSE()
MESSAGE(!foo!=bar)
ENDIF()
Besides the fact that you can not refer to it via ${!foo}, it's highly
inadvisable to name a variable in this way, of course. Anyway, if one
considers to introduce ! as an equivalent for NOT, one should also
add and | for AND/OR, or better and ||? What's about
=/==, !=, , =, , = for strings and/or numbers?
How to distinguish the latters? Nocturnal thoughts... ;-)
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] Patch CMake for Mac static library creation
On 11/04/2011 11:11 PM, Belcourt, K. Noel wrote: On Nov 4, 2011, at 3:56 PM, Belcourt, K. Noel wrote: This is a long overdue followup. On Dec 4, 2010, at 12:10 PM, Belcourt, K. Noel wrote: On Dec 4, 2010, at 10:08 AM, Ryan Pavlik wrote: You can configure this for your project: http://www.cmake.org/cmake/help/cmake-2-8- docs.html#prop_tgt:STATIC_LIBRARY_FLAGS STATIC_LIBRARY_FLAGS are passed to the archiver. On the Mac, I need to run ranlib after ar runs, and pass flags (-c) to ranlib. Another other ideas how to achieve this? If I use a custom command like this (physics is the name of the static library): add_custom_command(TARGET physics POST_BUILD COMMAND ranlib -c) This custom command can't work since you don't provide the library as argument for ranlib. How exactly does the failing command look alike? I get this error when it tries to run. /usr/bin/ranlib -c libphysics.a Error running link command: No such file or directory make[2]: *** [libs/test/physics/libphysics.a] Error 2 Because the quoted command includes the argument. Any ideas? Have you tried the VERBATIM flag, yet? 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] Undefined reference
On 11/03/2011 03:51 PM, Mauricio Klein wrote:
Thank you Raphael, it worked!
One last question: i've tried to compile my code using static linkage, once
i need my daemon runs in many Linux releases. But, even static, in many
systems my code crashes because the GLIBC version.
How do these crashes manifest themselves, e.g. shell/syslog messages,
return values, core dumps etc.? Are you sure they are related to the
GLIBC version? Does the executable actually have no single dependency
on any shared library, i.e. is it linked statically in its entirety?
What does ldd or readelf report?
My question is: asking for static linkage in CMake can solve this problem?
If even a statically linked executable crashes on the target system,
telling CMake to link statically will hardly solve this problem. ;)
Or maybe another approach in CMake, where i embed all the needed
libraries...
You might take a look the the BundleUtilities Module, but at first,
I'd recommend to investigate what exactly causes the crashes. Your
best bet is probably to provide a tiny but self-contained example
that works on your development platform and crashes on a target
system, along with some information about the latter's setup.
Regards,
Michael
On Thu, Nov 3, 2011 at 12:19 PM, Raphael Kubo da Costa
rak...@freebsd.orgwrote:
Mauricio Klein
mauricio.klein@gmail.com writes:
I can compile all my codes without problems, but in the linkage step, i
receive a lot of errors about undefined reference to OpenSSL functions
(yes, my code uses OpenSSL).
In my own (and ugly :P) Makefile, i use -lssl flag in g++ compile line.
My question is: how can i pass this flag in CMake.
Also, i'm not sure if i'm using CMake correctly. Is correctly use -lssl
flag in CMake or i need to copy the library to a folder inside my project
and link to this copy?
You need to find OpenSSL with `find_package(OpenSSL)' and then, assuming
it is found (ie. OPENSSL_FOUND is true), link to its libraries with
`target_link_libraries(YOUR_APP ${OPENSSL_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] Undefined reference
On 11/03/2011 06:20 PM, Mauricio Klein wrote:
The error reported occurs in the launch time: the daemon doesn't starts and
report (in terminal) a GLIBC version error. [...]
Usually, this means that it has *not* been linked statically against
the GLIBC on the build system. Which dependencies does ldd report?
[...] I mean, the daemon was compiled
in a old CentOS (4.8) and i'm trying to run in the latest Ubuntu.
But anyway, i will make more tests as you sugested and try to discovery
what exactly is happening.
Once again, thank you so much for your help!
On Thu, Nov 3, 2011 at 3:09 PM, Michael Hertling mhertl...@online.dewrote:
On 11/03/2011 03:51 PM, Mauricio Klein wrote:
Thank you Raphael, it worked!
One last question: i've tried to compile my code using static linkage,
once
i need my daemon runs in many Linux releases. But, even static, in many
systems my code crashes because the GLIBC version.
How do these crashes manifest themselves, e.g. shell/syslog messages,
return values, core dumps etc.? Are you sure they are related to the
GLIBC version? Does the executable actually have no single dependency
on any shared library, i.e. is it linked statically in its entirety?
What does ldd or readelf report?
My question is: asking for static linkage in CMake can solve this
problem?
If even a statically linked executable crashes on the target system,
telling CMake to link statically will hardly solve this problem. ;)
Or maybe another approach in CMake, where i embed all the needed
libraries...
You might take a look the the BundleUtilities Module, but at first,
I'd recommend to investigate what exactly causes the crashes. Your
best bet is probably to provide a tiny but self-contained example
that works on your development platform and crashes on a target
system, along with some information about the latter's setup.
Regards,
Michael
On Thu, Nov 3, 2011 at 12:19 PM, Raphael Kubo da Costa
rak...@freebsd.orgwrote:
Mauricio Klein
mauricio.klein@gmail.com writes:
I can compile all my codes without problems, but in the linkage step, i
receive a lot of errors about undefined reference to OpenSSL functions
(yes, my code uses OpenSSL).
In my own (and ugly :P) Makefile, i use -lssl flag in g++ compile
line.
My question is: how can i pass this flag in CMake.
Also, i'm not sure if i'm using CMake correctly. Is correctly use
-lssl
flag in CMake or i need to copy the library to a folder inside my
project
and link to this copy?
You need to find OpenSSL with `find_package(OpenSSL)' and then, assuming
it is found (ie. OPENSSL_FOUND is true), link to its libraries with
`target_link_libraries(YOUR_APP ${OPENSSL_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] Undefined reference
On 11/03/2011 06:39 PM, Mauricio Klein wrote:
ldd reports that is not dynamically executable, as expected. But even ldd
saying that, the problem with GLIBC occurs.
What exactly does ldd report, and how exactly the executable is linked?
Regards,
Michael
On Thu, Nov 3, 2011 at 3:33 PM, Michael Hertling mhertl...@online.dewrote:
On 11/03/2011 06:20 PM, Mauricio Klein wrote:
The error reported occurs in the launch time: the daemon doesn't starts
and
report (in terminal) a GLIBC version error. [...]
Usually, this means that it has *not* been linked statically against
the GLIBC on the build system. Which dependencies does ldd report?
[...] I mean, the daemon was compiled
in a old CentOS (4.8) and i'm trying to run in the latest Ubuntu.
But anyway, i will make more tests as you sugested and try to discovery
what exactly is happening.
Once again, thank you so much for your help!
On Thu, Nov 3, 2011 at 3:09 PM, Michael Hertling mhertl...@online.de
wrote:
On 11/03/2011 03:51 PM, Mauricio Klein wrote:
Thank you Raphael, it worked!
One last question: i've tried to compile my code using static linkage,
once
i need my daemon runs in many Linux releases. But, even static, in many
systems my code crashes because the GLIBC version.
How do these crashes manifest themselves, e.g. shell/syslog messages,
return values, core dumps etc.? Are you sure they are related to the
GLIBC version? Does the executable actually have no single dependency
on any shared library, i.e. is it linked statically in its entirety?
What does ldd or readelf report?
My question is: asking for static linkage in CMake can solve this
problem?
If even a statically linked executable crashes on the target system,
telling CMake to link statically will hardly solve this problem. ;)
Or maybe another approach in CMake, where i embed all the needed
libraries...
You might take a look the the BundleUtilities Module, but at first,
I'd recommend to investigate what exactly causes the crashes. Your
best bet is probably to provide a tiny but self-contained example
that works on your development platform and crashes on a target
system, along with some information about the latter's setup.
Regards,
Michael
On Thu, Nov 3, 2011 at 12:19 PM, Raphael Kubo da Costa
rak...@freebsd.orgwrote:
Mauricio Klein
mauricio.klein@gmail.com writes:
I can compile all my codes without problems, but in the linkage
step, i
receive a lot of errors about undefined reference to OpenSSL
functions
(yes, my code uses OpenSSL).
In my own (and ugly :P) Makefile, i use -lssl flag in g++ compile
line.
My question is: how can i pass this flag in CMake.
Also, i'm not sure if i'm using CMake correctly. Is correctly use
-lssl
flag in CMake or i need to copy the library to a folder inside my
project
and link to this copy?
You need to find OpenSSL with `find_package(OpenSSL)' and then,
assuming
it is found (ie. OPENSSL_FOUND is true), link to its libraries with
`target_link_libraries(YOUR_APP ${OPENSSL_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 the heck does one set options?
On 11/03/2011 08:20 PM, Dan Kegel wrote: Thanks for the authoritative answer. I'm now using SET(gtest_force_shared_crt on CACHE BOOL Use shared (DLL) run-time lib even when Google Test is built as static lib.) add_subdirectory(gtest) include_directories(gtest/include) add_executable(mymain mymain.cpp) target_link_libraries(mymain gtest_main) in my test app, and it's working with visual c++ 2008 (will try linux shortly). Yes, this should work well if the gtest_force_shared_crt variable is to have a different default value than the one provided by the gtest CMakeLists.txt. However, variables preset with OPTION() are usually intended to be at the user's disposal - otherwise, they wouldn't be options - so a project should definitely pass through without errors regardless to which values these variable are set at first. In other words, it shouldn't be necessary to preset gtest_force_shared_crt to ON for the project to succeed. Of course, inter-option dependencies must be handled properly, see the CMakeDependentOption module, e.g. I confess, I've been putting off understanding cmake's variable scoping and caching; I guess I'll have to pay more attention to it. I hope the library of worked examples I'm putting together at http://code.google.com/p/winezeug/source/browse/#svn/trunk/cmake_examples will eventually help other doc-o-phobes come up the curve faster. IMO, the actual difficulty is to understand SET(VARIABLE VALUE CACHE TYPE ...) as this command can - write to the cache and to the current scope, - write to the current scope only, - do nothing. Moreover, the potential difference between -DVARIABLE=VALUE and -DVARIABLE:TYPE=VALUE is a bug, IMO, since TYPE should only be relevant for the GUIs, but not for the resulting configuration. Anyway, if one conceptually distinguishes cache variables from scope variables, everything is fine. 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] Undefined reference
On 11/03/2011 10:18 PM, Dan Kegel wrote: On Thu, Nov 3, 2011 at 7:51 AM, Mauricio Klein mauricio.klein@gmail.com wrote: One last question: i've tried to compile my code using static linkage, once i need my daemon runs in many Linux releases. Static linking of glibc is not really supported; IIRC glibc's DNS and localization support use shared libraries under the hood, even when you ask for static linking... and since these are internal interfaces, they have changed in incompatible ways in the past. So beware! While it may be ok to link statically to most libraries, glibc should always be linked dynamically. If you will ever meet with a little accident while updating glibc without a package manager, a common procedure is to use statically linked utilities, i.e. utilities capable to run without the ruined glibc, at least in order to repair symlinks, e.g. Another occasion for the use of statically linked executables without any reference to glibc and friends is an initramfs that often doesn't have a lib directory at all. So, what do you mean when saying static linking against glibc is not really supported? Do you refer to particular systems or special setups? Could you provide an example? If you are still having problems after going back to dynamically linking with glibc, please post source code for a tiny test program that exhibits the problem, along with how you built and tested it, and the log showing the failure. Yep, message after failed invocation, ldd, linker command etc. 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() with a higher level directory
On 11/03/2011 09:10 PM, Daniel Dekkers wrote: Hi, We are creating a directory structure for distribution of an open-source library with examples included. It looks something like this: + library - the root directory CMakeLists.txt - create context for building (only) the library + src - contains the sources of the library CMakeLists.txt - actually add sources for (only) the library + examples CMakeLists.txt - create context for building all the examples (and the library, once) + example0 CMakeLists.txt - create context for building example0 (and the library) + src CMakeLists.txt - add sources for example0 + rsrc + example1 CMakeLists.txt - create context for building example1 (and the library) + src CMakeLists.txt - add sources for example1 + rsrc + ... The CMakeLists.txt in library, library/examples and library/examples/example0 and library/examples/example1 should all be possible entry points for a build. Maybe you want to build only the library, maybe you want to build the whole example suite, or maybe an individual example. Of course, the CMakeLists.txt in examples (or example0 and example1) depends on the actual library, so, from that level, we would like to call ADD_SUBDIRECTORY() to the *higher level* library directory... which is unacceptable for ADD_SUBDIRECTORY() (and probably conflicts with the whole CMake structure). If we would move examples up the hierarchy there wouldn't be a problem, but that doesn't give a nice distribution package. Any hints on a proper way to do this? Kind Regards, Daniel Dekkers IMO, you should set up your overall project roughly as usual, i.e.: library/CMakeLists.txt: ADD_SUBDIRECTORY(src) ADD_SUBDIRECTORY(examples) library/examples/CMakeLists.txt: SET_DIRECTORY_PROPERTIES(PROPERTIES EXCLUDE_FROM_ALL TRUE) ADD_SUBDIRECTORY(example0) ADD_SUBDIRECTORY(example1) ... ADD_CUSTOM_TARGET(examples) ADD_DEPENDENCIES(examples example0 example1 ...) library/examples/example0/CMakeLists.txt: TARGET_LINK_LIBRARIES(example0 library) In this way, you will have all dependencies set up correctly, and the examples are not built on behalf of make or make all. In order to build them, you might trigger the examples target or any individual examplei target, or you can jump into a target's directory under- neath CMAKE_BINARY_DIR and issue make from within there. However, you don't have an automatic target anymore to build everything, so you would need to provide one on your own, e.g.: library/CMakeLists.txt: ADD_CUSTOM_TARGET(world) ADD_DEPENDENCIES(world library examples) If you want to exclude unwanted parts of your project already from the configuration, you can use appropriate OPTION() commands and surround the ADD_SUBDIRECTORY() commands by IF(option)...ENDIF(). Note that you will have to handle the dependencies of your project's parts by yourself in this case, i.e. you can't disable ADD_SUBDIRECTORY(src) while enabling ADD_SUBDIRECTORY(examples) in library/CMakeLists.txt. 'hope that helps. Regards, Michael PS: Please don't hijack foreign threads. -- 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 Visual Studio PDB files with CMake
On 11/03/2011 10:02 PM, Stephen Torri wrote:
Searching the net for how to install PDB files with CMake comes up with no
real solution. I can see from the mailing list archives that this issue had
been brought up before. What is am acceptable way to install PDB files when
compiling on Windows?
Stephen
The problem is that PDB files are usually generated next to their binary
in a configuration-specific directory which can not be accessed smoothly
by INSTALL(FILES ...). However, you can use a POST_BUILD custom command
in conjunction with generator expressions to copy the PDB files to a
well-known location where INSTALL(FILES ...) will find them, e.g.:
ADD_EXECUTABLE(main ...)
ADD_CUSTOM_COMMAND(TARGET main POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_if_different
$TARGET_FILE_DIR:main/main.pdb
${CMAKE_BINARY_DIR}/main.pdb)
INSTALL(FILES ${CMAKE_BINARY_DIR}/main.pdb DESTINATION ...)
Possibly, you might need to use a convenient CMake script or the
like instead of copy_if_different to account for missing PDB
files in non-debug configurations.
While this should work quite well, it would be nice if INSTALL()
has an idea of generator expressions, too, so it can find non-
target files residing in configuration-specific locations.
Perhaps, that's worth a feature request?
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_directories() and duplicates
On 11/02/2011 06:54 PM, Robert Dailey wrote:
Does the include_directories() command strip out duplicate paths added?
Yes, it does; see the following exemplary project:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(INCLUDE C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
INCLUDE_DIRECTORIES(${CMAKE_BINARY_DIR} ${CMAKE_SOURCE_DIR})
INCLUDE_DIRECTORIES(BEFORE ${CMAKE_SOURCE_DIR})
Although CMAKE_SOURCE_DIR is added twice, it appears only once in the
compilation command. Note that the BEFORE flag additionally changes
the include directories' order. For more information, refer to
cmMakefile::AddIncludeDirectory() in Source/cmMakefile.cxx:
// Don't add an include directory that is already present.
However, with cmake --build and VS2008, I can see the following:
Z:\work\includetype CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(INCLUDE C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
INCLUDE_DIRECTORIES(${CMAKE_BINARY_DIR} ${CMAKE_SOURCE_DIR})
INCLUDE_DIRECTORIES(BEFORE ${CMAKE_SOURCE_DIR})
Z:\work\includemkdir obj
Z:\work\includecd obj
Z:\work\include\objcmake ..
-- Building for: Visual Studio 9 2008
-- Check for working C compiler using: Visual Studio 9 2008
-- Check for working C compiler using: Visual Studio 9 2008 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: Z:/work/include/obj
Z:\work\include\objcmake --build .
Microsoft (R) Visual Studio Version 9.0.21022.8.
[...]
1cl /Od /I Z:\work\include /I Z:\work\include\obj [...]
REM Everything works as expected, but now
REM comment out CMakeLists.txt's last line:
Z:\work\include\objtype ..\CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(INCLUDE C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
INCLUDE_DIRECTORIES(${CMAKE_BINARY_DIR} ${CMAKE_SOURCE_DIR})
#INCLUDE_DIRECTORIES(BEFORE ${CMAKE_SOURCE_DIR})
Z:\work\include\objcmake --build .
Microsoft (R) Visual Studio Version 9.0.21022.8.
[...]
1Checking Build System
1CMake is re-running because [...]
[...]
1-- Configuring done
1-- Generating done
1-- Build files have been written to: Z:/work/include/obj
[...]
2cl /Od /I Z:\work\include /I Z:\work\include\obj [...]
REM CMAKE_SOURCE_DIR is still before CMAKE_BINARY_DIR
REM although CMake has been re-run in the meantime.
REM However:
Z:\work\include\objcmake .
-- Configuring done
-- Generating done
-- Build files have been written to: Z:/work/include/obj
Z:\work\include\objcmake --build .
Microsoft (R) Visual Studio Version 9.0.21022.8.
[...]
1cl /Od /I Z:\work\include\obj /I Z:\work\include [...]
REM Now, the include directories' order is correct.
It seems as if a reconfiguration triggered by cmake --build due to
a changed CMakeLists.txt file has not the same effect as an explicit
reconfiguration and a subsequent rebuild. Can anybody confirm this
observation, and might it be considered as buggy behavior?
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] Setting a cmake option via make targets?
On 11/02/2011 07:32 PM, Yngve Inntjore Levinsen wrote:
Onsdag 02 november 2011 skrev szalai endre:
Hi guys,
I am using Rational Purify for runtime error checks in C++. To use it, you
have to call purify instead of the C++ linker at link phase. To do so, I
have the following cmake file:
//
project(myproject )
option (USE_PURIFY Use Rational Purify for runtime error checks OFF)
IF (USE_PURIFY)
set(CMAKE_CXX_LINK_EXECUTABLE purify ${CMAKE_CXX_LINK_EXECUTABLE})
ENDIF (USE_PURIFY)
add_executable (myproject HelloWorld.cc)
//
This adds the option and changes the linker (prepending with purify). This
works fine.
Now I would like to trigger the IF() line from a make target. Say, when I
type make myproject_purify, I would like to set the option (or prepend
the linker, whichever is best).
I am quite uncertain how to do it with cmake. I did not find any hint if I
can set options from cmake itself or not. Also, whenever I define a new
make target, I have to supply a shell command and it seems I cannot execute
cmake commands there.
So my question: how would you set an option via a make target? Any hints?
Thanks,
Mc
--
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,
Just an idea, would it be possible to just add a second target and use
set_target_properties() somehow? I'm guessing it would be something like:
set(sources HelloWorld.cc)
add_executable (myproject ${sources})
add_executable (myproject_purify ${sources} EXCLUDE_FROM_ALL)
set_target_properties(myproject_purify CMAKE_CXX_LINK_EXECUTABLE purify
${CMAKE_CXX_LINK_EXECUTABLE})
I have not tested this, so I might be wrong.
Cheers,
Yngve
CMAKE_CXX_LINK_EXECUTABLE isn't a target property, so you cannot do it
in this way. However, you might use that approach in conjunction with
purify as the targets' RULE_LAUNCH_LINK property and custom targets:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(PURIFY CXX)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.cxx int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.cxx)
OPTION(PURIFY Purify OFF)
IF(PURIFY)
SET_TARGET_PROPERTIES(main PROPERTIES RULE_LAUNCH_LINK purify)
ENDIF()
ADD_CUSTOM_TARGET(purify
COMMAND ${CMAKE_COMMAND} ${CMAKE_BINARY_DIR} -DPURIFY=ON)
ADD_CUSTOM_TARGET(unpurify
COMMAND ${CMAKE_COMMAND} ${CMAKE_BINARY_DIR} -DPURIFY=OFF)
The custom target purify reconfigures the project with -DPURIFY=ON
whereas unpurify does the reverse. So, after make purify, Make
rebuilds the project with purify, and after make unpurify, the
project is rebuilt as usual.
BTW, manipulating the CMAKE_CXX_LINK_EXECUTABLE rule variable in this
manner works, too, but the RULE_LAUNCH_* properties are a bit more to
my personal liking. Anyway, both do work for Makefile generators only.
'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] Weird linking error while cross compiling
On 10/28/2011 06:20 PM, Jose wrote:
I give up. [...]
Never say die. ;)
[...] I solved the problem with the solution Michael gave me. Actually
this linking flag : -Bstatic
was the causant of the troubles.
Out of curiosity: We've seen the failing link line; how does the
successful one look alike? Do you still use the -Bstatic flag?
Nevertheless now I get undefined references to functions defined in the
library portablexdr .
I have been trying to fix it for two days without success. The library is
being linked and I have checked the content of the library with
mingw32-nm and it has all the functions defined.
I have to say that I modified and rebuilt the library to include some
functions that were not present ( portableXDR does not follow the Sun XDR
standard). So I guess this is what it is
causing me the troubles but It should not since I rebuilt it without
problems and when I check the content of the library with nm the functions
are there.
Any help??
Could you provide some more information, i.e. excerpts from the make
VERBOSE=1 output and the concerned CMakeLists.txt files, especially
the latters' TARGET_LINK_LIBRARIES() commands? Ideally, you should
post a small self-contained example which demonstrates the issue.
Regards,
Michael
2011/10/26 Michael Hertling mhertl...@online.de
On 10/26/2011 10:28 AM, Andreas Pakulat wrote:
On 26.10.11 03:54:02, Jose wrote:
Sorry for not being very specific.
This is the command that Cmake is running while linking :
/usr/bin/i686-pc-mingw32-g++ -O3 -O3-Wl,-Bstatic -static-libgcc
-Wl,--whole-archive CMakeFiles/sqt2pin.dir/objects.a
-Wl,--no-whole-archive
-o sqt2pin.exe -Wl,--out-implib,libsqt2pin.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
-L/home/fedora/percolator/percolator/src/converters/../../src
libconverters.a libperclibrary_part.a MSToolkit/libMSToolkit.a
MSToolkit/RAMP/libRAMP.a -lxerces-c -lportablexdr
/home/fedora/percolator/percolator/src/converters/libs/dll/libtokyocabinet.a
-lz -lsqlite3 -Wl,-Bstatic -lkernel32 -luser32 -lgdi32 -lwinspool
-lshell32
-lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lxerces-c
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lportablexdr
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lz
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lsqlite3
That is weird cos I load all the libraries in the same way and they
all
the variables content the right paths to the libraries : (for example)
Xercesc : /usr/i686-pc-mingw32/sys-root/mingw/lib/libxerces-c.dll.a ,
XDR :
/usr/i686-pc-mingw32/sys-root/mingw/lib/libportablexdr.dll.a
This is how I link :
#COMPILING SQT2PIN
include_directories(. MSToolkit/RAMP MSToolkit )
add_executable(sqt2pin Sqt2Pin.cpp )
IF(STATIC AND MINGW)
set_property(TARGET sqt2pin PROPERTY LINK_SEARCH_END_STATIC ON)
set_target_properties(sqt2pin PROPERTIES LINK_FLAGS -Wl,-Bstatic
-static-libgcc)
ENDIF()
message(STATUS Xercesc : ${XERCESC_LIBRARIES} , XDR :
${PORTABLEXDR_LIBRARIES})
target_link_libraries(sqt2pin converters perclibrary_part MSToolkit
RAMP
${XERCESC_LIBRARIES} ${PORTABLEXDR_LIBRARIES} ${TOKYOCABINET_LIBRARIES}
)
I might be missing something very stupid because I use the same
prodecure
to search for the librarysthe FindXXX.cmake macros that are tested
and
working with other programs.
Could it be the include_directories(library include dir) which is
messing
this up? it looks like the linker disregard the path of the library that
Im
pasinng and looks for -lxerces-c instead. Is that xerces-c defined
somehow
before?
This happens if the library is considered to be in a 'system path' since
in that case specifying the path is not necessary for the linker to find
it. However in your specific case it seems like cmake does this even for
static libraries, which is of course wrong. I'd suggest to file a
bugreport for this with a small self-contained example.
Andreas
The -l switch of ld is not related to the library's type, i.e.
shared or static; see ld's manpage and the following example:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(STATIC C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c int f(void){return 0;}\n)
EXECUTE_PROCESS(COMMAND ${CMAKE_C_COMPILER} -c f.c)
EXECUTE_PROCESS(COMMAND ${CMAKE_AR} cr libf.a f.o)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return f();}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main -L${CMAKE_BINARY_DIR} f /usr/lib/libz.a)
The executable main is linked against the static libf.a via the -l
switch. Usually, in particular on ELF systems, ld just prefers shared
libraries with -l unless it is told to not do so, e.g. using -Bstatic.
However, MinGW's ld behaves differently in this regard; IIRC, it even
Re: [CMake] RC compiler on Linux - new problem
On 10/25/2011 10:16 AM, pellegrini wrote:
Hi Michael,
I tried to adapt the files you gave me to my project. It almost works.
As a reminder, there were a CMakeLists.txt with an overloaded
add_executable function that created a sym_link for the rc files and a
shell file (rc.sh) used to suit the rc compiler call to my needs.
I found one problem that I still not have solved. The shell script is
declared under the following command:
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE bash rc.sh
CMAKE_RC_COMPILER SOURCE OBJECT)
However, this command makes that even my f90 files uses the rc compiler
which obvioulsy makes my build crash. I tried to use something like
set_property(SOURCE myrcfile.rc PROPERTY RULE_LAUNCH_COMPILE ... in
order to apply the patch only when a rc file is under process but
unfortunately this property is not a valid source properties.
Would you see any way to circumvent that problem ?
thanks
Eric
The rc.sh script is designed to differentiate between an RC invocation
and something else; this is why it is called with the RC as the first
argument. If the first argument of the actual command line is equal
to CMAKE_RC_COMPILER, the command line is modified to adapt to the
winteracter RC; otherwise, it is executed without modification. Watch
out for the lines starting with Executing ... in the output of Make.
If it still does not work, could you provide a small self-contained
example which demonstrates the issue for further investigation?
However, I reconsidered your concern in the meantime. Possibly, it's a
more appropriate approach to use a wrapper script for the winteracter
RC to adapt the latter to CMake's expectations. This script should:
- accept parameters according to Modules/CMakeRCInformation.cmake,
- link or copy the source file to a temporary directory the
winteracter RC can write its output file to thereafter,
- move the output file where it's expected by CMake.
This wrapper can be enabled when WINTERACTER_RC_COMPILER is set at
the initial configuration of the project, so you don't need to re-
implement ADD_EXECUTABLE() et al. - which works only once anyway -
or to rely on the Makefile-specific RULE_LAUNCH_COMPILE property,
and the RC files still don't need to be handled specially, which
has been the idea of ADD_EXECUTABLE()'s reimplementation. However,
the downside is that you can not use CMake anymore to detect the
winteracter RC automatically; you must do it by yourself before
the PROJECT() or ENABLE_LANGUGAE() command, e.g.
IF(WINTERACTER_RC_COMPILER)
CONFIGURE_FILE(rc.sh.in rc.sh @ONLY)
SET(CMAKE_RC_COMPILER ${CMAKE_BINARY_DIR}/rc.sh
CACHE STRING RC compiler FORCE)
ENDIF()
PROJECT(... RC)
with a template rc.sh.in for the wrapper script rc.sh, containing
@WINTERACTER_RC_COMPILER@ somewhere. In this way, anything should
work as usual if WINTERACTER_RC_COMPILER is not set at the initial
configuration of the project, but if it is set, the wrapper script
is configured and forced to be used as the RC, and the subsequent
PROJECT() or ENABLE_LANGUGAE() command won't search for an RC by
themselves.
'hope that helps.
Regards,
Michael
pellegrini a écrit :
thanks a lot Michael.
Finally, this was not such a trivial problem but I should find my way
with the examples you gave me.
Eric
Michael Hertling a écrit :
On 10/21/2011 06:49 PM, pellegrini wrote:
Hi all,
after digging and googling some hours I did a first step in the
right direction.
I had to add the command:
enable_language(rc)
set(cmake_rc_compiler_arg1 -cif8)
The resource compiler I (must) use is the one provided by
winteracter Fortran library.
This led me to a serie of problems related to the use of this compiler:
- it does not accept any output flag so that the output resource
object is always created in-source in the rc file directory.
- on Linux, it produces a .o object file instead of a .res file
Looking at the CMakeRCInformation.cmake I see that by construction
CMake will use the following compile command:
CMAKE_RC_COMPILER FLAGS DEFINES /foOBJECT SOURCE
with a resource object file with a .res extension.
You might rewrite this rule variable, e.g. in order to drop
/foOBJECT, but this wouldn't resolve your issues, AFAICS.
On a Linux machine, this produces a wrong build command line with
the path for the output object file being /foCMakeFiles/ This
problem was raised sometime ago in the mantis bug tracker but
unfortunatley the patch proposed apply for mingw using windres but
not for Linux.
Is there a fix for this ?
If no, is there a way to inform the linker that:
- my resource object file is located in-source
You might create symlinks to the resource files - or copy them - so
that the winteracter RC generates its output files within the build
tree; note that the source tree may be read-only. This could even be
done on the fly with an adapted version of ADD_EXECUTABLE/LIBRARY
Re: [CMake] Weird linking error while cross compiling
On 10/26/2011 10:28 AM, Andreas Pakulat wrote:
On 26.10.11 03:54:02, Jose wrote:
Sorry for not being very specific.
This is the command that Cmake is running while linking :
/usr/bin/i686-pc-mingw32-g++ -O3 -O3-Wl,-Bstatic -static-libgcc
-Wl,--whole-archive CMakeFiles/sqt2pin.dir/objects.a -Wl,--no-whole-archive
-o sqt2pin.exe -Wl,--out-implib,libsqt2pin.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
-L/home/fedora/percolator/percolator/src/converters/../../src
libconverters.a libperclibrary_part.a MSToolkit/libMSToolkit.a
MSToolkit/RAMP/libRAMP.a -lxerces-c -lportablexdr
/home/fedora/percolator/percolator/src/converters/libs/dll/libtokyocabinet.a
-lz -lsqlite3 -Wl,-Bstatic -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32
-lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lxerces-c
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lportablexdr
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lz
/usr/lib/gcc/i686-pc-mingw32/4.5.3/../../../../i686-pc-mingw32/bin/ld:
cannot find -lsqlite3
That is weird cos I load all the libraries in the same way and they all
the variables content the right paths to the libraries : (for example)
Xercesc : /usr/i686-pc-mingw32/sys-root/mingw/lib/libxerces-c.dll.a , XDR :
/usr/i686-pc-mingw32/sys-root/mingw/lib/libportablexdr.dll.a
This is how I link :
#COMPILING SQT2PIN
include_directories(. MSToolkit/RAMP MSToolkit )
add_executable(sqt2pin Sqt2Pin.cpp )
IF(STATIC AND MINGW)
set_property(TARGET sqt2pin PROPERTY LINK_SEARCH_END_STATIC ON)
set_target_properties(sqt2pin PROPERTIES LINK_FLAGS -Wl,-Bstatic
-static-libgcc)
ENDIF()
message(STATUS Xercesc : ${XERCESC_LIBRARIES} , XDR :
${PORTABLEXDR_LIBRARIES})
target_link_libraries(sqt2pin converters perclibrary_part MSToolkit RAMP
${XERCESC_LIBRARIES} ${PORTABLEXDR_LIBRARIES} ${TOKYOCABINET_LIBRARIES} )
I might be missing something very stupid because I use the same prodecure
to search for the librarysthe FindXXX.cmake macros that are tested and
working with other programs.
Could it be the include_directories(library include dir) which is messing
this up? it looks like the linker disregard the path of the library that Im
pasinng and looks for -lxerces-c instead. Is that xerces-c defined somehow
before?
This happens if the library is considered to be in a 'system path' since
in that case specifying the path is not necessary for the linker to find
it. However in your specific case it seems like cmake does this even for
static libraries, which is of course wrong. I'd suggest to file a
bugreport for this with a small self-contained example.
Andreas
The -l switch of ld is not related to the library's type, i.e.
shared or static; see ld's manpage and the following example:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(STATIC C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c int f(void){return 0;}\n)
EXECUTE_PROCESS(COMMAND ${CMAKE_C_COMPILER} -c f.c)
EXECUTE_PROCESS(COMMAND ${CMAKE_AR} cr libf.a f.o)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return f();}\n)
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main -L${CMAKE_BINARY_DIR} f /usr/lib/libz.a)
The executable main is linked against the static libf.a via the -l
switch. Usually, in particular on ELF systems, ld just prefers shared
libraries with -l unless it is told to not do so, e.g. using -Bstatic.
However, MinGW's ld behaves differently in this regard; IIRC, it even
prefers static and import libraries to shared ones with the -l switch.
BTW, /usr/lib/libz.a is converted into -Wl,-Bstatic -lz -Wl,-Bdynamic
due to /usr/lib being a system directory, i.e. CMake performs this -l
conversion of full paths in system directories for static libraries,
too; why should it be called wrong?
Jose, could you find out which directories CMake considers as system
directories and if these are actually searched implicitly by ld? If
CMake takes /usr/i686-pc-mingw32/sys-root/mingw/lib as system dir,
thus libxerces-c.dll.a -- -lxerces-c, but ld does not search it
without a proper -L switch, the issue would be quite clear. As
a quick workaround, you might use imported targets for the
concerned libraries to avoid the -l conversion, i.e.:
ADD_LIBRARY(xerces-c STATIC IMPORTED)
SET_TARGET_PROPERTIES(xerces-c PROPERTIES IMPORTED_LOCATION
/usr/i686-pc-mingw32/sys-root/mingw/lib/libxerces-c.dll.a)
TARGET_LINK_LIBRARIES(... xerces-c ...)
'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 source files on a per-configuration basis
On 10/06/2011 10:29 AM, Michael Wild wrote:
On 10/06/2011 08:14 AM, Michael Hertling wrote:
On 10/06/2011 07:04 AM, Michael Wild wrote:
On Thu 06 Oct 2011 05:17:00 AM CEST, Michael Hertling wrote:
On 10/05/2011 10:47 PM, Robert Dailey wrote:
In my particular CMake project, I have three CPP files:
a.cpp
b.cpp
c.cpp
I want 'a.cpp' to be compiled in all configurations (release debug).br
I only want 'b.cpp' to be compiled in DEBUG configuration.br
I only want 'c.cpp' to be compiled in RELEASE configuration.
How can I do this? I need something similar to the `debug` and `optimized`
keywords that are accepted by the `target_link_libraries()` CMake
operation.
If it's okay that b.cpp and c.cpp are compiled in all configurations but
incorporated in the final binaries only in the DEBUG or in the RELEASE
configuration, respectively, you might do the following:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(IMPORTEDEMPTY C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
# Add library for DEBUG:
FILE(WRITE ${CMAKE_BINARY_DIR}/b.c void b(void){}\n)
ADD_LIBRARY(b STATIC b.c)
# Add library for RELEASE:
FILE(WRITE ${CMAKE_BINARY_DIR}/c.c void c(void){}\n)
ADD_LIBRARY(c STATIC c.c)
# Add empty static library:
FILE(WRITE ${CMAKE_BINARY_DIR}/empty.c )
ADD_LIBRARY(empty STATIC empty.c)
# Reimport empty static library:
EXPORT(TARGETS empty NAMESPACE imported FILE importedempty.cmake)
INCLUDE(${CMAKE_BINARY_DIR}/importedempty.cmake)
# Impose IMPORTED_LINK_INTERFACE_LIBRARIES_{DEBUG,RELEASE} properties:
FOREACH(i IN LISTS CMAKE_CONFIGURATION_TYPES ITEMS ${CMAKE_BUILD_TYPE})
STRING(TOUPPER ${i} i)
IF(i STREQUAL DEBUG)
SET_TARGET_PROPERTIES(importedempty PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_${i} b)
ELSEIF(i STREQUAL RELEASE)
SET_TARGET_PROPERTIES(importedempty PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_${i} c)
ENDIF()
ENDFOREACH()
# Specify required dependencies:
ADD_DEPENDENCIES(importedempty empty b c)
# Add final binary:
FILE(WRITE ${CMAKE_BINARY_DIR}/a.c int main(void){return 0;}\n)
ADD_EXECUTABLE(a a.c)
TARGET_LINK_LIBRARIES(a importedempty)
Adventurous, but somewhat clean; see [1] for an explanation, and be
especially careful with a file named libc.a on *nix systems. ;-)
If you really need to avoid the compilation of b.cpp or c.cpp in
certain configurations, you might try the following approach:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(RECONF C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/a.c int main(void){return 0;}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/b.c void b(void){}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/c.c void c(void){}\n)
STRING(TOUPPER ${CONF} CONF)
IF(CONF STREQUAL DEBUG)
ADD_EXECUTABLE(a0 EXCLUDE_FROM_ALL a.c b.c)
ELSEIF(CONF STREQUAL RELEASE)
ADD_EXECUTABLE(a0 EXCLUDE_FROM_ALL a.c c.c)
ELSE()
ADD_EXECUTABLE(a0 EXCLUDE_FROM_ALL a.c)
ENDIF()
ADD_CUSTOM_TARGET(a ALL
COMMAND ${CMAKE_COMMAND}
-DCONF=$CONFIGURATION
${CMAKE_BINARY_DIR}
COMMAND ${CMAKE_COMMAND}
--build ${CMAKE_BINARY_DIR}
--config $CONFIGURATION
--target a0)
Effectively, when target a is built, the project reconfigures itself
with the current configuration passed in via CONF and with a helper
target a0 which is made up from the configuration-specific sources;
finally, this target a0 is built with the current configuration.
This can be seen working on *nix with Makefiles, but there might
be issues with other generators and IDEs.
'hope that helps.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg34680.html
I think it would be much easier to have a wrapper file, say b_or_c.cpp
which #include's b.cpp or c.cpp at compile time depending on the current
configuration. E.g. like this:
///
#if defined USE_B_CPP
# include b.cpp
#elseif defined USE_C_CPP
# include c.cpp
#else // what should happen otherwise?
# error Either USE_B_CPP or USE_C_CPP must be defined!
#endif
///
And then in your CMakeLists.txt you do:
###
set_source_files_properties(b_or_c.cpp PROPERTIES
COMPILE_DEFINITIONS_DEBUG USE_B_CPP
COMPILE_DEFINITIONS_RELEASE USE_C_CPP
# what should happen in a default build?
# Or RELWITHDEBINFO and MINSIZEREL?
)
###
Yes, this would work, too, but if neither b.cpp nor c.cpp should be
compiled if the current configuration is neither DEBUG nor RELEASE,
the b_or_c.cpp file would be effectively empty, and adding an object
file compiled from an empty source file to a binary is not 100 % the
same as dropping the object file completely - at least with gcc and
even with -Os. However, it's a quite negligible effect, but linking
Re: [CMake] RC compiler on Linux - new problem
On 10/21/2011 06:49 PM, pellegrini wrote:
Hi all,
after digging and googling some hours I did a first step in the right
direction.
I had to add the command:
enable_language(rc)
set(cmake_rc_compiler_arg1 -cif8)
The resource compiler I (must) use is the one provided by winteracter
Fortran library.
This led me to a serie of problems related to the use of this compiler:
- it does not accept any output flag so that the output resource
object is always created in-source in the rc file directory.
- on Linux, it produces a .o object file instead of a .res file
Looking at the CMakeRCInformation.cmake I see that by construction CMake
will use the following compile command:
CMAKE_RC_COMPILER FLAGS DEFINES /foOBJECT SOURCE
with a resource object file with a .res extension.
You might rewrite this rule variable, e.g. in order to drop
/foOBJECT, but this wouldn't resolve your issues, AFAICS.
On a Linux machine, this produces a wrong build command line with the
path for the output object file being /foCMakeFiles/ This problem
was raised sometime ago in the mantis bug tracker but unfortunatley the
patch proposed apply for mingw using windres but not for Linux.
Is there a fix for this ?
If no, is there a way to inform the linker that:
- my resource object file is located in-source
You might create symlinks to the resource files - or copy them - so
that the winteracter RC generates its output files within the build
tree; note that the source tree may be read-only. This could even be
done on the fly with an adapted version of ADD_EXECUTABLE/LIBRARY().
- the extension is not .res but .o
You might use a RULE_LAUNCH_COMPILE property in conjunction with a
shell script which recognizes RC command lines, moves the .o to a
.res in the correct directory and drops the undesired /fo switch.
The attached CMakeLists.txt and rc.sh files outline these approaches;
check them out with meaningful ${CMAKE_SOURCE_DIR}/{abs,srcdir}.rc
and ${CMAKE_BINARY_DIR}/bindir.rc. However, they are untested as I
currently haven't any RC at hand; moreover, they're restricted to
Makefiles and won't work on Windows.
Regards,
Michael
pellegrini a écrit :
Hi all,
I use CMake 2.8.5 on Linux and Windows machine to build a Fortran
project.
On Windows, no problem, the build and the resulting GUI are OK. On
Linux, the build seems to
be OK but the resulting GUI gives an empty screen. Discussing with
Michael a few days ago made
me think that it could be related to the use of an inappropriated
motif library.
However, looking in more details I see with a make VERBOSE=1 that my
rc file is not built
(I do not see the line Building RC object ...). even if it is
declared as one of my sources files.
Is there some extra commands to specify to make cmake recognize and
compile a rc file ?
thanks
Eric
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(RC C RC)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/rc)
FUNCTION(ADD_EXECUTABLE TARGET)
UNSET(ARGS)
FOREACH(i IN LISTS ARGN)
IF(i MATCHES \\.rc$)
IF(IS_ABSOLUTE ${i})
GET_FILENAME_COMPONENT(p ${i} PATH)
FILE(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/rc${p})
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E create_symlink
${i} ${CMAKE_BINARY_DIR}/rc${i})
LIST(APPEND ARGS ${CMAKE_BINARY_DIR}/rc${i})
ELSEIF(EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/${i})
GET_FILENAME_COMPONENT(p ${CMAKE_CURRENT_SOURCE_DIR}/${i}
PATH)
FILE(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/rc${p})
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E create_symlink
${CMAKE_CURRENT_SOURCE_DIR}/${i}
${CMAKE_BINARY_DIR}/rc${CMAKE_CURRENT_SOURCE_DIR}/${i})
LIST(APPEND ARGS
${CMAKE_BINARY_DIR}/rc${CMAKE_CURRENT_SOURCE_DIR}/${i})
ELSE()
GET_FILENAME_COMPONENT(p ${CMAKE_CURRENT_BINARY_DIR}/${i}
PATH)
FILE(MAKE_DIRECTORY ${CMAKE_BINARY_DIR}/rc${p})
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E create_symlink
${CMAKE_CURRENT_BINARY_DIR}/${i}
${CMAKE_BINARY_DIR}/rc${CMAKE_CURRENT_BINARY_DIR}/${i})
LIST(APPEND ARGS
${CMAKE_BINARY_DIR}/rc${CMAKE_CURRENT_BINARY_DIR}/${i})
ENDIF()
ELSE()
LIST(APPEND ARGS ${i})
ENDIF()
ENDFOREACH()
_ADD_EXECUTABLE(${TARGET} ${ARGS})
ENDFUNCTION()
SET_PROPERTY(GLOBAL PROPERTY RULE_LAUNCH_COMPILE bash
${CMAKE_SOURCE_DIR}/rc.sh CMAKE_RC_COMPILER SOURCE OBJECT)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/bindir.rc ) # -- Something meaningful.
ADD_EXECUTABLE(main main.c srcdir.rc bindir.rc ${CMAKE_SOURCE_DIR}/abs.rc)
rc.sh
Description: Bourne shell script
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep
Re: [CMake] add_custom_command question
On 10/20/2011 12:37 PM, Łukasz Tasz wrote: Hi all, In my cmake project I have few commands that are creating outputs. But Unfortunately those outputs are used across many directories. So my question is what's the real scope of output_command? only Current_CmakeLists.txt? Yes, a custom command's OUTPUT must be referred to by an ADD_LIBRARY/ EXECUTABLE() or an ADD_CUSTOM_TARGET() within the same CMakeLists.txt file; otherwise, it is silently ignored. Can I somehow make make_target that is creating output registered in global scope? Mention the custom command's OUTPUT in a custom target's DEPENDS clause in the same CMakeLists.txt, and use ADD_DEPENDENCIES() to ensure that the custom target is triggered at the proper time. Note the issues w.r.t. relative paths in this regard. I'm familiar with pattern of attaching custom target with custom command, but I would like to avoid managing separately target, and output name. AFAIK, there's currently no chance to do this in another way, but a custom command can generate more than one output file, and a custom target can refer to more than one prerequisite, so you can possibly aggregate and don't need an own target/command per output file. thanks in advance Lukasz 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_MFC_FLAG not working in functions
On 10/20/2011 06:59 PM, Robert Dailey wrote:
Let me ask this,
What would be the parent of a function located in the root CMakeLists file
but called from a subordinate CMakeLists file?
It's the subordinate CMakeLists.txt file's parent, but what Michael
probably aims at is that some variables undergo a lazy evaluation,
i.e. when you say
set( CMAKE_MFC_FLAG 2 )
add_executable( ... )
in a function, and CMAKE_MFC_FLAG isn't evaluated till generation time,
the value 2 will be lost since it is limited to the function's scope.
See the following project for an example:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(LAZY C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FUNCTION(ADD_EXECUTABLE_LOCAL TARGET)
SET(CMAKE_C_FLAGS ${CMAKE_FLAGS} -DLOCAL)
ADD_EXECUTABLE(${TARGET} ${ARGN})
ENDFUNCTION()
FUNCTION(ADD_EXECUTABLE_PARENT TARGET)
SET(CMAKE_C_FLAGS ${CMAKE_FLAGS} -DPARENT PARENT_SCOPE)
ADD_EXECUTABLE(${TARGET} ${ARGN})
ENDFUNCTION()
ADD_SUBDIRECTORY(local)
ADD_SUBDIRECTORY(parent)
# local/CMakeLists.txt:
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/main.c
int main(void){return 0;}\n)
ADD_EXECUTABLE_LOCAL(local main.c)
# parent/CMakeLists.txt:
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/main.c
int main(void){return 0;}\n)
ADD_EXECUTABLE_PARENT(parent main.c)
This should somewhat reflect the situation you reported. The sole
difference between the functions - besides the differently named
preprocessor definitions - is the PARENT_SCOPE flag. As you can
see, the local target is built without the -DLOCAL whereas the
parent target is built with the -DPARENT. This is because the
CMAKE_C_FLAGS in ADD_EXECUTABLE_LOCAL() isn't in effect anymore
at the end of local/CMakeLists.txt when the ADD_EXECUTABLE() is
actually used to generate the final build files, i.e. Makefiles,
Projects etc. In contrast, -DPARENT *is* in effect at the end
of parent/CMakeLists.txt when the build files are generated.
Regards,
Michael
On Thu, Oct 20, 2011 at 11:55 AM, Michael Wild them...@gmail.com wrote:
On 10/20/2011 05:41 PM, Robert Dailey wrote:
On Thu, Oct 20, 2011 at 2:36 AM, Rolf Eike Beer e...@sf-mail.de
mailto:e...@sf-mail.de wrote:
I have a function defined very high up in the directory tree at
the root
CMakeLists file. Several levels below it, I have another
CMakeLists file
that I call that function from.
The function sets CMAKE_MFC_FLAG to 2. I notice that this flag gets
ignored
when it is set inside of the function in question. If I set the
flag
outside
of the function, in the lowest level CMakeLists file, it works.
This
property seems somehow tied to the directory itself, but I can't
figure
out
if this is a feature or a bug.
This behavior isn't very flexible as I'd like to make the details
of
configuring an MFC compatible project transparent to the lower
level
CMakeLists scripts. Hiding away the flag and how it needs to be
set is a
big
part of this, but I can't do it.
Anyone know how I can make this work?
A function creates a new variable scope, i.e. everything you set in
there
will be reset once you leave the function. Have a look at SET(...
PARENT_SCOPE) for this.
Not even that worked, unfortunately.
Basically from my function I do:
set( CMAKE_MFC_FLAG 2 )
add_executable( ... )
Since I'm setting it right before the add_executable() call, I would
think that scope has nothing to do with it.
No, the add_executable() call does not evaluate the variable. It only
gets evaluated *after* the processing of the current CMakeLists.txt
file. If using set(CMAKE_MFC_FLAG 2 PARENT_SCOPE) really doesn't work,
IMHO that would be a bug. The only work-around would be to use a macro
instead (where you don't need the PARENT_SCOPE at all).
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_MFC_FLAG not working in functions
On 10/20/2011 08:44 PM, Robert Dailey wrote: On Thu, Oct 20, 2011 at 12:56 PM, Michael Hertling mhertl...@online.dewrote: On 10/20/2011 06:59 PM, Robert Dailey wrote: Let me ask this, What would be the parent of a function located in the root CMakeLists file but called from a subordinate CMakeLists file? It's the subordinate CMakeLists.txt file's parent, but what Michael probably aims at is that some variables undergo a lazy evaluation, i.e. when you say set( CMAKE_MFC_FLAG 2 ) add_executable( ... ) in a function, and CMAKE_MFC_FLAG isn't evaluated till generation time, the value 2 will be lost since it is limited to the function's scope. See the following project for an example: Does this lazy evaluation also apply to variables set with PARENT_SCOPE? If so, that would explain why not even that helped. If the variable is subject to lazy evaluation - not all variables are, and I don't know if CMAKE_MFC_FLAG is - it doesn't matter how it has received its final value at the concerned CMakeLists.txt's end, i.e. if it has been set in the CMakeLists.txt immediately or in a function using PARENT_SCOPE or in a subordinate CMakeLists.txt file entered by ADD_SUBDIRECTORY(), also using PARENT_SCOPE; the latest value will be in effect for the generation step. BTW, I talked trash: What would be the parent of a function located in the root CMakeLists file but called from a subordinate CMakeLists file? It's the subordinate CMakeLists.txt file's parent, [...] This is not true, of course. A function called from a CMakeLists.txt file opens up its own scope, and its parent scope is the one of the calling CMakeLists.txt file, not the one of the latter's parent. Sorry about the mistake. If your issue still persists, could you come up with a minimal but complete exemplary project for further investigation? 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 question
On 10/20/2011 08:23 PM, Łukasz Tasz wrote: add_custom_target(TARGET generator COMMAND touch aaa.cxx COMMENT generate file ) add_custom_command(OUTPUT aaa.cxx COMMAND echo command DEPENDS generator bar This does not work^^^ COMMENT i'm just echo ) add_executable(bar EXCLUDE_FROM_ALL c.cxx) add_executable(foo aaa.cxx) error is: [ 33%] Built target bar make[2]: *** No rule to make target `../generator', needed by `aaa.cxx'. Stop. make[1]: *** [CMakeFiles/foo.dir/all] Error 2 one my mistake, which is slightly changing the output: add_custom_target(generator COMMAND touch aaa.cxx COMMENT generate file ) add_custom_command(OUTPUT aaa.cxx COMMAND echo command DEPENDS generator bar COMMENT i'm just echo ) add_executable(bar EXCLUDE_FROM_ALL c.cxx) add_executable(foo aaa.cxx) [ 0%] generate file [ 25%] Built target generator [ 50%] Built target bar make[3]: *** No rule to make target `generator', needed by `aaa.cxx'. Stop. regards Lukasz Which version of CMake do you use? This issue should have been resolved in 2.8.4, see [1]. If it still persists, could you come up with a minimal but complete example for further investigation? Regards, Michael [1] http://public.kitware.com/Bug/view.php?id=12057 -- 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] always rebuild executable
On 10/18/2011 02:21 PM, Anton Sibilev wrote:
Hi! Looking for some help..
I use add_executable(exename) + target_link_libraries (exename
staticlibname), linux OS. If 'staticlibname' is not under CMake and chagnes
somehow, CMake will not rebuild executable.
And so I have a problem, that I have few updates of 'staticlibname' lib, but
very old executable. Can I force to rebuild executable every build?
What do you mean with rebuild? If you just want to *relink* the final
binary - which is sufficient to incorporate a changed static library -
use a full path to the latter as recommended in the meantime. If you
actually want to *recompile* the final binary's object files, you
might do the following:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(REBUILD C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
EXECUTE_PROCESS(COMMAND gcc -c f.c)
EXECUTE_PROCESS(COMMAND ar cr libf.a f.o)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/m1.c void m1(void){}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/m2.c void m2(void){}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/m3.c void m3(void){}\n)
FILE(WRITE ${CMAKE_BINARY_DIR}/g.c void g(void){}\n)
ADD_EXECUTABLE(main main.c m1.c m2.c m3.c)
TARGET_LINK_LIBRARIES(main -L. f)
ADD_CUSTOM_COMMAND(TARGET main POST_BUILD
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_BINARY_DIR}/main.stamp)
GET_TARGET_PROPERTY(SOURCES main SOURCES)
STRING(REPLACE ; : SOURCES ${SOURCES})
ADD_CUSTOM_TARGET(invalidate ${CMAKE_COMMAND}
-DSOURCES=${SOURCES}
-DPREREQ=${CMAKE_BINARY_DIR}/libf.a
-DSTAMP=${CMAKE_BINARY_DIR}/main.stamp
-P ${CMAKE_SOURCE_DIR}/invalidate.cmake)
ADD_DEPENDENCIES(main invalidate)
# invalidate.cmake:
IF(${PREREQ} IS_NEWER_THAN ${STAMP})
STRING(REPLACE : ; SOURCES ${SOURCES})
FOREACH(i IN LISTS SOURCES)
EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E touch ${i})
ENDFOREACH()
ENDIF()
The invalidate.cmake script - triggered by a custom target - touches
a bunch of source files if a prerequisite is newer than a stamp file.
The latter is generated along with the main executable, and the pre-
requisite is the external static library. Note that one cannot use
-DSTAMP=$TARGET_FILE:main as this would introduce a circular
dependency among the 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] Transitively including dependency source directories
On 10/14/2011 11:39 PM, Robert Dailey wrote:
If I have the following target dependency chain:
A B C D
Then target D must have the include directories (defined on a per project
basis with a cache variable currently) for C, B, and A.
Right now I'm trying to implement the logic for this myself using macro
recursion, but as of right now I don't know of any way to get the list of
target dependencies from a target. For example, if I query target C's
dependencies, I should get a list back with just B in it. Then when I
query for B's dependencies, I should get a list with A in it.
I thought there might be a way to use get_target_property() for this, but
doesn't seem so.
How would you all recommend I go about this? Am I completely off base?
Right now each target has a ${name}_INCLUDE_DIRS internal cache variable,
which is a list of that target's include directories, so that if other
targets specify it as a dependency, they also know how to get to that
target's header files.
You might attribute an accumulative/transitive meaning to variables
like ${name}_INCLUDE_DIRS: A_INCLUDE_DIRS contains its own include
directories only, B_INCLUDE_DIRS contains its own directories *and*
A_INCLUDE_DIRS etc. Since each target usually knows on which other
targets it immediately depends, this setup should be quite possible.
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] Mixing static and dynamic library
On 10/17/2011 09:31 AM, pellegrini wrote:
Hi Michael,
thanks for your help.
You guessed right: there was no symlink against libXm.so.2. Surprinsigly
(is it actually ?) [...]
No, not really, see below.
[...] there was no symlink against
any of the libX libraries (Xmu, Xft, Xp ...) until I installed the
development packages that were missing for all of them.
Essentially, these so-called name links are a convenience feature
so that you can specify -lXm on the linker command line and have the
linker look for libXm.{so,a} automatically. You might also specify the
SONAME symlink or the actual library file instead. The reason why these
name links are typically contained in a package's development component
is the following: Suppose you have the Motif-2 runtime and development
components installed, i.e. libXm.so - libXm.so.2 and libXm.so.2.x.y;
suppose further you have a Motif-1 program so you need the Motif-1
libraries. Now, if the Motif-1 package installs its name links, you
will end up with libXm.so - libXm.so.1 so that the linker will link
against the Motif-1 libraries the next time it sees -lXm. Probably,
this is not what you want. Thus, the name links should be installed
by/for the packages that are used for development, and usually, you
cannot install the development components of different versions of
the same package to the same prefix, e.g. due to the headers. BTW,
CMake accounts for that with INSTALL()'s NAMELINK_{ONLY,SKIP} flags.
The build works now, the output is not the one expected (a blank screen
instead of the expected GUI) but this is
another story ...
Indeed, the lib{X11,Xt,Xm,...} stuff provides numerous opportunities to
stumble; e.g., not-managing Widgets, a missing XtRealizeWidget() on the
top-level shell or messed up resources are quite popular, IIRC. ;-)
thanks again
Eric
Regards,
Michael
Michael Hertling a écrit :
On 10/13/2011 03:27 PM, pellegrini wrote:
Hi all,
I would like to port a hardcoded build line from an old make file to my
CMakeLists.txt file for a fortran 90
project using ifort compiler.
The line is the following:
ifort *.o -o myexec -static-intel -Bstatic -lXm -Bdynamic -lXt
First, if I get it right (sorry for my ignorance but I come from the
python world where I was quite
preserved from these lines !!!), the goal is to build an executable:
- statically bound to the intel libraries
- statically bound to libXm library
- dynamically bound to libXt library
A locate told me that on my machine both Xt and Xm are in dynamic form
(libXm.so.2, libXt.so.6) and in a standard location (/usr/lib). So in my
CMakeLists.txt file, I tried:
set(CMAKE_Fortran_FLAGS_RELEASE -static-intel)
add_executable(myexec $SOURCES)
target_link_libraries(myexec -Bdynamic Xm Xt)
when building the project I get an error at link time (ld: cannot find
-lXm).
Would you have any idea of what is going wrong with my settings ?
thanks a lot
Eric
The message ld: cannot find -lXm reveals that the linker can't find
libXm.so - or libXm.a if not ruled out - in the directories searched
for libraries; the mere presence of the SONAMEd libXm.so.2 does not
suffice unless you tell CMake to use it, e.g. via imported libraries
and appropriate IMPORTED_LOCATION properties. Typically, you have a
symlink libXm.so - libXm.so.2 or to the actual library file, so the
-lXm is sufficient for the linker to succeed, but this symlink isn't
necessary to execute a program linked against the Motif library, and
sometimes it is dropped when the package's development component is
not installed. Thus, could you check if there is a libXm.so symlink?
If not, create it and try anew, and if it still does not work, could
you post the relevant part of the make VERBOSE=1 output for further
investigation?
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 define custom import library name (MSVC)?
On 10/16/2011 06:27 PM, zex spectrum wrote:
Hello,
I generate a shared library named, for example, mylib80.dll (it has
postfix 80, because I want to embed version info into library name.
I use set_target_properties with Config_POSTFIX property to achieve
this. By default, CMake names corresponding import library as
mylib80.lib. But I want my shared lib to have an import lib named
mylib.lib (without version embedded into its name). Is it possible at
all? I tried IMPORT_SUFFIX, but it seems to not work as I expect.
AFAIK, a shared library target's import library is named like
... + ARCHIVE_OUTPUT_NAME_CONFIG + CONFIG_POSTFIX + IMPORT_SUFFIX
so you cannot use the IMPORT_SUFFIX to overwrite the CONFIG_POSTFIX.
I use MSVC, I do not need to have this for GCC and other compilers.
Any help would be appreciated.
You might use an additional INSTALL(CODE ...) step, see the attached
CMakeLists.txt file. Note that the LOCATION property might have side
effects, cf. [1], so it's probably best to place it at the very end.
'hope that helps.
Regards,
Michael
[1] http://public.kitware.com/Bug/view.php?id=11671
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(IMPLIB C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c
__declspec(dllexport) void f(void){}\n)
ADD_LIBRARY(f SHARED f.c)
SET_TARGET_PROPERTIES(f PROPERTIES DEBUG_POSTFIX 80)
INSTALL(TARGETS f RUNTIME DESTINATION bin ARCHIVE DESTINATION lib)
GET_TARGET_PROPERTY(F0 f LOCATION_DEBUG)
GET_FILENAME_COMPONENT(F0 ${F0} NAME_WE)
STRING(REGEX REPLACE 80\$ F ${F0})
INSTALL(CODE FILE(RENAME \${CMAKE_INSTALL_PREFIX}/lib/${F0}.lib\
\${CMAKE_INSTALL_PREFIX}/lib/${F}.lib\))
--
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 define custom import library name (MSVC)?
On 10/17/2011 01:58 PM, Michael Hertling wrote:
On 10/16/2011 06:27 PM, zex spectrum wrote:
Hello,
I generate a shared library named, for example, mylib80.dll (it has
postfix 80, because I want to embed version info into library name.
I use set_target_properties with Config_POSTFIX property to achieve
this. By default, CMake names corresponding import library as
mylib80.lib. But I want my shared lib to have an import lib named
mylib.lib (without version embedded into its name). Is it possible at
all? I tried IMPORT_SUFFIX, but it seems to not work as I expect.
AFAIK, a shared library target's import library is named like
... + ARCHIVE_OUTPUT_NAME_CONFIG + CONFIG_POSTFIX + IMPORT_SUFFIX
so you cannot use the IMPORT_SUFFIX to overwrite the CONFIG_POSTFIX.
I use MSVC, I do not need to have this for GCC and other compilers.
Any help would be appreciated.
You might use an additional INSTALL(CODE ...) step, see the attached
CMakeLists.txt file. Note that the LOCATION property might have side
effects, cf. [1], so it's probably best to place it at the very end.
'hope that helps.
Regards,
Michael
[1] http://public.kitware.com/Bug/view.php?id=11671
Addendum: If you want to be independent of the import library's actual
suffix, you might use INSTALL(SCRIPT ...) instead of INSTALL(CODE ...)
with the import library installed temporarily under CMAKE_BINARY_DIR:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(IMPLIB C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(SRCDIR ${CMAKE_BINARY_DIR}/fimplib)
SET(DSTDIR ${CMAKE_INSTALL_PREFIX}/lib)
CONFIGURE_FILE(
${CMAKE_SOURCE_DIR}/install_implib.cmake.in
${CMAKE_BINARY_DIR}/install_implib.cmake
@ONLY)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c
__declspec(dllexport) void f(void){}\n)
ADD_LIBRARY(f SHARED f.c)
SET_TARGET_PROPERTIES(f PROPERTIES
DEBUG_POSTFIX 80
IMPORT_SUFFIX .imp) # -- for demonstration.
INSTALL(TARGETS f
RUNTIME DESTINATION bin
ARCHIVE DESTINATION ${CMAKE_BINARY_DIR}/fimplib)
INSTALL(SCRIPT ${CMAKE_BINARY_DIR}/install_implib.cmake)
# install_implib.cmake.in:
FILE(GLOB F @SRCDIR@/*)
GET_FILENAME_COMPONENT(F_EXT ${F} EXT)
GET_FILENAME_COMPONENT(F_NWE ${F} NAME_WE)
STRING(REGEX REPLACE 80\$ F_NWE ${F_NWE})
FILE(RENAME ${F} @SRCDIR@/${F_NWE}${F_EXT})
FILE(INSTALL @SRCDIR@/${F_NWE}${F_EXT}
DESTINATION @DSTDIR@
USE_SOURCE_PERMISSIONS)
AFAICS, the intermediate installation of the import library is necessary
to separate the latter from the DLL part, so one has a chance to rename
it without knowing its actual suffix. Moreover, the FILE(INSTALL ...)
is told to retain its permissions which INSTALL(FILES ...) wouldn't.
The basic idea is: The import library should be installed once with
INSTALL(... ARCHIVE DESTINATION ...) to get the correct permissions,
and you can not modify its name separately from the DLL part before
the INSTALL() command. So, you need to rename it afterwards, either
in the installation directory with knowledge of its suffix, or in a
dedicated intermediate directory where you can use FILE(GLOB ...)
and GET_FILENAME_COMPONENT() without knowing the suffix.
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] Fwd: Save stripped debugging information
On 10/14/2011 12:58 AM, Rolf Eike Beer wrote: Am Donnerstag, 13. Oktober 2011, 20:09:04 schrieb Michael Hertling: On 10/12/2011 03:40 PM, Rolf Eike Beer wrote: On 10/03/2011 09:18 AM, Yuri Timenkov wrote: Hi Michael, On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling mhertl...@online.dewrote: On 10/01/2011 10:07 AM, Yuri Timenkov wrote: that's the problem: you don't know neither file name nor it's location, especially in multi-configuration generators. You *do* know a debug file's name and location, either because you must generate it explicitly (objcopy approach) or via the concerned target's $TARGET_FILE_DIR:... generator expression in custom targets/commands (Visual approach). Otherwise, a debug file with unknown name and/or location would be rather useless. I'm sorry that you misunderstood me, but I was concerned about install() commands. CMake already does a lot of things to make different platforms and generators work in same way. As it was noted before, install already knows about such subtleties between generators and platforms like export libraries. So why not make it aware of separate debug information? Because, IMO, the platform/generator independent extraction and/or recognition of debug info files is significantly more difficult to specify than the handling of DLLs along with their import libraries in VS, e.g. AFAICS, the latter works well since the import libraries are generated next to their DLLs sharing the same base name, and both are covered by INSTALL()'s RUNTIME/ARCHIVE DESTINATION clauses which also have a defined meaning on *nix. For VS alone, the installation of debug info files would in fact be as easy as the installation of an import library, but how would you specify and parameterize this task on *nix? With the GNU toolchain, CMake can't know in advance if and how debug info files are generated, where they're written to etc. I think you got something reverse here. To actually get the debug information in a separate file with binutils you need to run objcopy. [...] No, you can use the full symbol-equipped executable as debug info file: cite src=man objcopy Also the --only-keep-debug step is optional. You could instead do this: 1. Link the executable as normal. 2. Copy foo to foo.full 3. Run objcopy --strip-debug foo 4. Run objcopy --add-gnu-debuglink=foo.full foo i.e., the file pointed to by the --add-gnu-debuglink can be the full executable. It does not have to be a file created by the --only-keep-debug switch. /cite As you can see, the debug info file is *not* generated by objcopy; it's just a copy of the original non-stripped binary. The --only-keep-debug switch is virtually the complement of --strip-debug; essentially, it removes non-debug-related sections - convenient but not necessary. Yes it's a copy. So someone has to do this. And to know the location. And this is CMake. So CMake will do the copy, call the objdump and do other fancy things. But it is completely driven by CMake, so CMake knows which files are involved. It's not that at any point CMake is calling a program that would magically create files at places that CMake doesn't know of before, all output filenames will be specified by CMake. Actually, my intention was to point out that generating debug info files on *nix is not equivalent to invoking objcopy; there're other methods, and we do not know which utility Y the toolchain X uses for this purpose. Apart from that, we can readily agree on the assumption that debug info files have certain names on *nix which are also known to CMake if this is believed to ease the further discussion. The only thing that may magically happen is the generation of the build id. But that will not create a file on it's own, and CMake can easily read the build id out of the generated executable. The file named after the build id is later created by cp, objcopy, or CMake. And once again CMake would know about the name. Indeed, the problem w.r.t. the build ID is not an additional file, but the fact that (1) it must already be taken into account for the linking step, (2) must be provided with a user-supplied value and (3) the debug info file must be installed to or linked from a certain directory. If a cross-platform unification is to make sense, you must enhance the link step as well as the install step. Suppose this CMakeLists.txt excerpt: ADD_EXECUTABLE(main main.c) INSTALL(TARGETS main RUNTIME DESTINATION bin DEBUG DESTINATION ...) Suppose further a *nix user A wants to create and install a debug file for main with objcopy --only-keep-debug/--add-gnu-debuglink, whereas user B wants to do this with a build ID. What do you suggest that A and B should add to their respective CMakeLists.txt to accomplish their goals? Just conceptually, no implementation details. -optionally, and only on installation, check if the file has a build-id (using readelf, objdump or whatever
Re: [CMake] ExternalProject and clean targets
On 10/12/2011 10:22 PM, Lori Pritchett-Sheats wrote:
I'm building external packages in my CMake system using the
ExternalPackages_Add function. When a package is built this way and I
execute a 'make clean' at the top of my build tree, all targets are
cleaned including the external packages. Is there a way to remove the
external package targets from the the default clean target?
The following exemplary project does not exhibit this behavior:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(CLEAN C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
INCLUDE(ExternalProject)
ExternalProject_Add(external
SOURCE_DIR ${CMAKE_SOURCE_DIR}/external
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=INSTALL_DIR)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
ADD_DEPENDENCIES(main external)
INSTALL(TARGETS main DESTINATION bin)
# external/CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(EXTERNAL C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(f SHARED f.c)
INSTALL(TARGETS f DESTINATION lib)
After configuring and building:
% ls main external-prefix/src/external-build/libf.so
external-prefix/src/external-build/libf.so main
After make clean in CMAKE_BINARY_DIR:
% ls main external-prefix/src/external-build/libf.so
ls: cannot access main: No such file or directory
external-prefix/src/external-build/libf.so
The top-level project's target is gone whereas the external project's
one is intact, and [1] reports the same, i.e. the opposite of your
concern. Thus, could you boil down your issue to a minimal but
self-contained example for further investigation?
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg35411.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] Mixing static and dynamic library
On 10/13/2011 03:27 PM, pellegrini wrote: Hi all, I would like to port a hardcoded build line from an old make file to my CMakeLists.txt file for a fortran 90 project using ifort compiler. The line is the following: ifort *.o -o myexec -static-intel -Bstatic -lXm -Bdynamic -lXt First, if I get it right (sorry for my ignorance but I come from the python world where I was quite preserved from these lines !!!), the goal is to build an executable: - statically bound to the intel libraries - statically bound to libXm library - dynamically bound to libXt library A locate told me that on my machine both Xt and Xm are in dynamic form (libXm.so.2, libXt.so.6) and in a standard location (/usr/lib). So in my CMakeLists.txt file, I tried: set(CMAKE_Fortran_FLAGS_RELEASE -static-intel) add_executable(myexec $SOURCES) target_link_libraries(myexec -Bdynamic Xm Xt) when building the project I get an error at link time (ld: cannot find -lXm). Would you have any idea of what is going wrong with my settings ? thanks a lot Eric The message ld: cannot find -lXm reveals that the linker can't find libXm.so - or libXm.a if not ruled out - in the directories searched for libraries; the mere presence of the SONAMEd libXm.so.2 does not suffice unless you tell CMake to use it, e.g. via imported libraries and appropriate IMPORTED_LOCATION properties. Typically, you have a symlink libXm.so - libXm.so.2 or to the actual library file, so the -lXm is sufficient for the linker to succeed, but this symlink isn't necessary to execute a program linked against the Motif library, and sometimes it is dropped when the package's development component is not installed. Thus, could you check if there is a libXm.so symlink? If not, create it and try anew, and if it still does not work, could you post the relevant part of the make VERBOSE=1 output for further investigation? 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] ExternalProject and clean targets
On 10/15/2011 12:34 PM, David Cole wrote:
On Sat, Oct 15, 2011 at 3:48 AM, Michael Hertling mhertl...@online.de wrote:
On 10/12/2011 10:22 PM, Lori Pritchett-Sheats wrote:
I'm building external packages in my CMake system using the
ExternalPackages_Add function. When a package is built this way and I
execute a 'make clean' at the top of my build tree, all targets are
cleaned including the external packages. Is there a way to remove the
external package targets from the the default clean target?
The following exemplary project does not exhibit this behavior:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(CLEAN C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
INCLUDE(ExternalProject)
ExternalProject_Add(external
SOURCE_DIR ${CMAKE_SOURCE_DIR}/external
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=INSTALL_DIR)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
ADD_DEPENDENCIES(main external)
INSTALL(TARGETS main DESTINATION bin)
# external/CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(EXTERNAL C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c void f(void){}\n)
ADD_LIBRARY(f SHARED f.c)
INSTALL(TARGETS f DESTINATION lib)
After configuring and building:
% ls main external-prefix/src/external-build/libf.so
external-prefix/src/external-build/libf.so main
After make clean in CMAKE_BINARY_DIR:
% ls main external-prefix/src/external-build/libf.so
ls: cannot access main: No such file or directory
external-prefix/src/external-build/libf.so
The top-level project's target is gone whereas the external project's
one is intact, and [1] reports the same, i.e. the opposite of your
concern. Thus, could you boil down your issue to a minimal but
self-contained example for further investigation?
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg35411.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
When Lori said all targets are cleaned including the external
packages I think she meant that she would like the ExternalProject
stamp files to remain intact across a clean such that the
ExternalProject steps do not re-execute on the next make. Is that
indeed what you meant, Lori?
If so, I do not know of an easy way to achieve that goal.
One thing that comes to mind is separating out the parts that you
don't want to re-build after a clean into a separate project, and
build/[install] that into a place where you can reference the
built/installed products from a second project in which you frequently
'clean'...
Another alternative would be to avoid the top-level clean altogether,
and simply go down into an individual external project's build tree
and do the make clean in there so as to only clean the individual
project you're immediately working with.
I've frequently thought we should cache/share ExternalProject builds
across other multiple builds that could reference them but I
hesitate to put legs on that idea because of possibly introducing easy
ways to create giant tangled messes of projects with incompatible
compiler/linker flags. It's worth keeping on the idea pile, though,
and a motivated individual could certainly already achieve this by
placing the build/install products of ExternalProject_Add calls in
shared locations (i.e., in the HOME directory instead of as
sub-directories of the present build tree).
HTH,
David
Ah, I see. Would it be an alternative to get the external projects'
stamp files out of the way, trigger the top-level project's clean
target and restore the stamp files right after that? If I add the
following to the above-noted top-level CMakeLists.txt
ExternalProject_Get_Property(external STAMP_DIR)
SET(DIRS ${STAMP_DIR}) # Mind the separator.
ADD_CUSTOM_TARGET(tl-clean
COMMAND ${CMAKE_COMMAND} -DDIRS=${DIRS} -DSEP=:
-P ${CMAKE_SOURCE_DIR}/savestampfiles.cmake
COMMAND ${CMAKE_COMMAND} --build ${CMAKE_BINARY_DIR}
--target clean
COMMAND ${CMAKE_COMMAND} -DDIRS=${DIRS} -DSEP=:
-P ${CMAKE_SOURCE_DIR}/restorestampfiles.cmake)
with
# savestampfiles.cmake:
STRING(REPLACE ${SEP} ; DIRS ${DIRS})
FOREACH(i IN LISTS DIRS)
FILE(GLOB FILES ${i}/*)
FOREACH(j IN LISTS FILES)
FILE(RENAME ${j} ${j}.bak)
ENDFOREACH()
ENDFOREACH()
# restorestampfiles.cmake:
STRING(REPLACE ${SEP} ; DIRS ${DIRS})
FOREACH(i IN LISTS DIRS)
FILE(GLOB FILES ${i}/*.bak)
FOREACH(j IN LISTS FILES)
STRING(REGEX REPLACE \\.bak\$ k ${j})
FILE(RENAME ${j} ${k})
ENDFOREACH()
ENDFOREACH()
a make tl-clean in CMAKE_BINARY_DIR cleans the top-level project
- not the external ones' targets
Re: [CMake] complete change of compilation flags for a single file
On 10/11/2011 11:42 AM, Ilias Miroslav wrote:
Dear experts,
within our cmake project there are needs to change compilation flags of some
individual files, especially we want sometimes to decrease optimization level.
For that there is a command set_source_file_properties, but among
PROPERTIES,
http://grip.espace-win.net/doc/apps/cmake/cmake-properties.txt ,
there is no flag to completely replace/modify CMAKE_Fortran_FLAGS +
CMAKE_Fortran_FLAGS_RELEASE for that file.
There is only COMPILE_FLAGS putting extra compiler flags for file 's
compilation.
For instance, for chosen file some_file.F90
SET_SOURCE_FILES_PROPERTIES( some_file.F90 PROPERTIES COMPILE_FLAGS -O1l)
this command combines -O3 from CMAKE_Fortran_FLAGS_RELEASE with -O1 from
COMPILE_FLAGS ... but we want only -O1.
Another example:
set_source_files_properties( abacus/her2drv.FPROPERTIES COMPILE_FLAGS
-O0 -no-ip )
make VERBOSE=1 abacus/her2drv.o
make -f CMakeFiles/dirac.dir/build.make
CMakeFiles/dirac.dir/abacus/her2drv.F.o
make[1]: Entering directory
`/people/disk2/ilias/QCH_Work/qch_progs/dirac_git/trunk/build_ompi_ifort_icc_mkl_ilp64'
/people/disk2/ilias/bin/cmake_install/bin/cmake -E cmake_progress_report
/people/disk2/ilias/QCH_Work/qch_progs/dirac_git/trunk/build_ompi_ifort_icc_mkl_ilp64/CMakeFiles
Building Fortran object CMakeFiles/dirac.dir/abacus/her2drv.F.o
/people/disk2/ilias/bin/openmpi_ifort_icc_ilp64/bin/mpif90 -o
CMakeFiles/dirac.dir/abacus/her2drv.F.o -DPRG_DIRAC -DTHIS_IS_CMAKE_BUILD
-DMOD_XML -DMOD_OPENRSP -DMOD_OOF -DMOD_ESR -DMOD_KRCC -DMOD_SRDFT
-DMOD_XCFUN -DMOD_MAGNETIZ -DMOD_MCSCF_spinfree -DMOD_UNRELEASED -DMOD_CAP
-DMOD_ERI -DMOD_DNF -DINSTALL_WRKMEM=6400 -DSYS_LINUX -DINT_STAR8
-DVAR_MPI -DVAR_MPI2 -w -assume byterecl -DVAR_IFORT -g -traceback -i8 -O3
-ip -module modules
-I/people/disk2/ilias/bin/openmpi_ifort_icc_ilp64_valgrind/include
-I/people/disk2/ilias/QCH_Work/qch_progs/dirac_git/trunk/include
-I/people/disk2/ilias/QCH_Work/qch_progs/dirac_git/trunk/build_ompi_ifort_icc_mkl_ilp64/modules
-I/people/disk2/ilias/QCH_Work/qch_progs/dirac_git/trunk/build_ompi_ifort_icc_mkl_ilp64/xcint/xcfun/fortran
-O0 -no-ip -c
/people/disk2/ilias/QCH_Work/qch_progs/dirac_git/trunk/abacus/her2drv.F
make[1]: Leaving directory
`/people/disk2/ilias/QCH_Work/qch_progs/dirac_git/trunk/build_ompi_ifort_icc_mkl_ilp64'
Here it combines -O3 -ip at the beginning (in CMAKE_Fortran_FLAGS_RELEASE
) with -O0 -no-ip at the end, but we don't want this.
Any help please ?
Miro
A thorough management of compilation flags is notoriously demanding
with CMake because these flags stem from several origins - multiple
variables, properties and even from environment variables when the
project is configured for the first time, e.g. CC - and aren't kept
at a central place and joint not until the generation step, AFAIK.
If you get along with Makefiles, you might use the RULE_LAUNCH_*
properties to make last-minute modifications; see the following:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(RMFLAGS C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
SET_SOURCE_FILES_PROPERTIES(main.c PROPERTIES COMPILE_FLAGS -O1)
ADD_EXECUTABLE(main main.c)
SET(RMFLAGS bash ${CMAKE_SOURCE_DIR}/rmflags.sh)
SET_TARGET_PROPERTIES(main PROPERTIES
RULE_LAUNCH_COMPILE ${RMFLAGS} -O3 --)
# rmflags.sh:
FLAGS=()
while [ $1 != -- ]; do
FLAGS[${#FLAGS[@]}]=$1; shift
done
shift
CMD=($1); shift
declare -i OCCURS
for i in $@; do
OCCURS=0
for j in ${FLAGS[@]}; do
[ $i == $j ] : $((++OCCURS))
done
[ $OCCURS -eq 0 ] CMD[${#CMD[@]}]=$i
done
echo Executing ${CMD[@]}
exec ${CMD[@]}
Configure with CMAKE_BUILD_TYPE==release, and the rmflags.sh script
will drop the -O3 flag from the compiler command line. In this way,
you should be able to perform arbitrary manipulations. However, if
you use the GCC compilers only, you might rely on the following
assertion from gcc's manpage:
If you use multiple -O options, with or without level numbers,
the last such option is the one that is effective.
'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
