Re: [CMake] Cannot add target-level dependencies to non-existent target
I've not come across the target_sources command before - is it new in 3.1.3
? From reading the documentation it looks like it allows one to add
sources to a target *after* the target has been created via add_library or
add_executable. If that is true then that could be a very useful command.
I will investigate further but it could be just what I need.
--
Glenn
On 30 June 2015 at 22:34, Stephen Kelly steve...@gmail.com wrote:
Glenn Coombs wrote:
I am getting the error in the subject. The code I have looks like this:
if (PRE_COMPILED_HEADERS_FOUND)
ADD_PRECOMPILED_HEADER(${header_pch} ${source_pch} sources
systemc)
endif()
add_library(systemc ${sources} ${sources_no_pch} ${headers})
Use target_sources after the target is created.
add_library(systemc ${sources} ${headers})
if (PRE_COMPILED_HEADERS_FOUND)
ADD_PRECOMPILED_HEADER(${header_pch} ${source_pch} pch_files systemc)
target_sources(systemc PRIVATE ${pch_files})
endif()
Thanks,
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] warn if features used that require cmake-x.y
I don't think policies are sufficient. I just tried using the new target_sources command that was introduced in CMake 3.1.0 in a CMakeLists.txt file that specified cmake_minimum_required(VERSION 3.0) and it didn't warn that the CMakeLists.txt file wouldn't work with CMake 3.0. I think if you want to guarantee that it will work with CMake x.y then you must always use CMake x.y instead of using newer versions and hoping they will tell you if you have used something that won't work on the older version you require. On 2 July 2015 at 05:13, Stuermer, Michael SP/HZA-ZSEP michael.stuer...@schaeffler.com wrote: Have a look at cmake_minimum_required() and cmake_policy(). I think with these both it should be possible to verify you are using a cmake version that provides all features which are required by your project. See here: http://www.cmake.org/cmake/help/v3.3/command/cmake_minimum_required.html?#command:cmake_minimum_required and here: http://www.cmake.org/cmake/help/v3.3/command/cmake_policy.html best regards, Michael -Original Message- From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Nicolas Bock Sent: Wednesday, July 01, 2015 8:29 PM To: cmake@cmake.org Subject: [CMake] warn if features used that require cmake-x.y Hi, is there a way to get CMake to warn if a feature is used that requires a cmake version greater than some version x.y? Thanks, nick -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] Cannot add target-level dependencies to non-existent target
I am getting the error in the subject. The code I have looks like this:
if (PRE_COMPILED_HEADERS_FOUND)
ADD_PRECOMPILED_HEADER(${header_pch} ${source_pch} sources systemc)
endif()
add_library(systemc ${sources} ${sources_no_pch} ${headers})
where the call to add_dependency is in the ADD_PRECOMPILED_HEADER macro and
is adding a dependency on the systemc target about to be created on the
next line. I could split the macro into 2 and call one before the
add_library and one after the add_library but that is rather messy.
At the point I try to add the dependency the target does not exist, but it
is added shortly after. Is this the way CMake is supposed to behave or
should it only cause an error if the target doesn't exist at generate time
?
--
Glenn
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] output of add_custom_command as target in Makefile
If you run make help it will list targets it understands. And as you
pointed out there is no target for foo.cc. You can make foo but if you
really want a target for foo.cc you can add one yourself:
cmake_minimum_required(VERSION 3.0.0)
project(custom-command-target)
add_custom_command (
OUTPUT foo.cc
COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/genFoo foo.cc
)
add_custom_target(foo.cc DEPENDS ${CMAKE_BINARY_DIR}/foo.cc)
add_executable (foo foo.cc)
That should create a foo.cc target that you can run that will do the right
thing.
--
Glenn
On 12 June 2015 at 14:20, Dave Yost d...@yost.com wrote:
I’m not doing it wrong. Remember, this is a simplified example.
We want to be able to make foo.cc so we can look at it and compare it.
Yes, we could make foo and then look at foo.cc, but until foo.cc is
right, we will suffer a lot of compiler error clutter. When foo.cc looks
right, then we will make foo.
BTW, changing add_custom_command to add_custom_target has no apparent
effect and doesn’t help.
On 2015-06-12, at 12:24 AM, Nagy-Egri Máté Ferenc csiga.b...@aol.com
wrote:
You’re doing it all wrong. You do not name source files as make targets,
but the target name (or project name, I have no idea, because it rarely
makes sense to name them differently). Try simply “foo”
or “custom-command-target”. You would never say “make foo.cpp”, not even in
an ordinary GNU Make script.
*Feladó:* Dave Yost d...@yost.com
*Elküldve:* péntek, 2015. június 12. 2:00
*Címzett:* cmake@cmake.org
In this example, how do I get
make foo.cc
to work?
0 Thu 16:56:19 yost DaveBook ~/p/c++/cmake/custom-command-target
369 Z% bundle CMakeLists.txt genFoo
#!/usr/bin/env unbundle
# See http://yost.com/computers/bundle/
CMakeLists.txt
cmake_minimum_required(VERSION 3.3.0)
project(custom-command-target)
add_custom_command (
OUTPUT foo.cc
COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/genFoo foo.cc
)
add_executable (foo foo.cc)
genFoo
#!/bin/bash
echo
int main() {
return 0;
}
0 Thu 16:56:23 yost DaveBook ~/p/c++/cmake/custom-command-target
370 Z% cd build
0 Thu 16:56:36 yost DaveBook ~/p/c++/cmake/custom-command-target/build
371 Z% cmake ..
-- Configuring done
-- Generating done
-- Build files have been written to:
/Users/yost/p/c++/cmake/custom-command-target/build
0 Thu 16:56:41 yost DaveBook ~/p/c++/cmake/custom-command-target/build
372 Z% make clean
0 Thu 16:56:45 yost DaveBook ~/p/c++/cmake/custom-command-target/build
373 Z% make foo.cc
make: *** No rule to make target 'foo.cc'. Stop.
2 Thu 16:56:49 yost DaveBook ~/p/c++/cmake/custom-command-target/build
374 Z%
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] Boost library directory not found unless I explicitly set BOOST_LIBRARYDIR ?
Hi,
I have installed Boost on Windows 7 for Visual Studio 2013 by running these
installers:
boost_1_56_0-msvc-12.0-32.exe
boost_1_56_0-msvc-12.0-64.exe
downloaded from
http://sourceforge.net/projects/boost/files/boost-binaries/1.56.0/.
I'm using CMake 2.8.12.1 and when I try to build a simple Boost example
using the filesystem library my cmake configuration step fails to find the
required libraries unless I use the BOOST_LIBRARYDIR variable to tell it
where the libraries are:
set(BOOST_VERSION_NEEDED 1.53.0)
if (MSVC)
set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIMEON)
# set(BOOST_LIBRARYDIR/Boost/boost_1_56_0/lib64-msvc-12.0)
endif()
find_package(Boost ${BOOST_VERSION_NEEDED} REQUIRED COMPONENTS system
filesystem)
Given that the library directory is where the official Boost installer put
it shouldn't the FindBoost.cmake package be checking that directory by
default ?
This is the output from CMake:
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:476 ] _boost_TEST_VERSIONS =
1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:478 ] Boost_USE_MULTITHREADED =
ON
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:480 ] Boost_USE_STATIC_LIBS = ON
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:482 ] Boost_USE_STATIC_RUNTIME
= ON
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:484 ] Boost_ADDITIONAL_VERSIONS
=
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:486 ] Boost_NO_SYSTEM_PATHS =
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:538 ] Declared as CMake or
Environmental Variables:
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:540 ] BOOST_ROOT =
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:542 ] BOOST_INCLUDEDIR =
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:544 ] BOOST_LIBRARYDIR =
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:546 ] _boost_TEST_VERSIONS =
1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:639 ] location of version.hpp:
C:/Boost/boost_1_56_0/boost/version.hpp
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:663 ] version.hpp reveals boost
1.56.0
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:739 ] guessed _boost_COMPILER =
-vc120
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:749 ] _boost_MULTITHREADED = -mt
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:792 ] _boost_RELEASE_ABI_TAG =
-s
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:794 ] _boost_DEBUG_ABI_TAG =
-sgd
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:842 ]
_boost_LIBRARY_SEARCH_DIRS =
C:/Boost/boost_1_56_0/lib;C:/Boost/boost_1_56_0/../lib;C:/Boost/boost_1_56_0/stage/lib;PATHS;C:/boost/lib;C:/boost;/sw/local/lib
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:930 ] Searching for
SYSTEM_LIBRARY_RELEASE:
libboost_system-vc120-mt-s-1_56;libboost_system-vc120-mt-s;libboost_system-mt-s-1_56;libboost_system-mt-s;libboost_system
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:966 ] Searching for
SYSTEM_LIBRARY_DEBUG:
libboost_system-vc120-mt-sgd-1_56;libboost_system-vc120-mt-sgd;libboost_system-mt-sgd-1_56;libboost_system-mt-sgd;libboost_system-mt;libboost_system
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:930 ] Searching for
FILESYSTEM_LIBRARY_RELEASE:
libboost_filesystem-vc120-mt-s-1_56;libboost_filesystem-vc120-mt-s;libboost_filesystem-mt-s-1_56;libboost_filesystem-mt-s;libboost_filesystem
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:966 ] Searching for
FILESYSTEM_LIBRARY_DEBUG:
libboost_filesystem-vc120-mt-sgd-1_56;libboost_filesystem-vc120-mt-sgd;libboost_filesystem-mt-sgd-1_56;libboost_filesystem-mt-sgd;libboost_filesystem-mt;libboost_filesystem
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:1017 ] Boost_FOUND = 1
Could NOT find Boost
Boost version: 1.56.0
Boost include path: C:/Boost/boost_1_56_0
Could not find the following static Boost libraries:
boost_system
boost_filesystem
No Boost libraries were found. You may need to set BOOST_LIBRARYDIR to the
directory containing Boost libraries or BOOST_ROOT to the location of Boost.
As you can see it is looking for a directory called lib rather than
lib64-msvc-12.0.
--
Glenn
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the
Re: [CMake] Boost library directory not found unless I explicitly set BOOST_LIBRARYDIR ?
Ryan,
Thanks for the helper script - I'll try that out on Monday.
Does anybody know if the FindBoost.cmake file is maintained by the CMake
developers, or does it have a 3rd party maintainer ? It would be nice to
see some logic similar to your script incorporated by default so that other
people experience the simplicity of it just working straight out of the box.
--
Glenn
On 14 November 2014 16:23, Ryan Pavlik ryan.pav...@gmail.com wrote:
I've used a script to help it out a bit. I think these Windows installers
are new. Here's the script I use - it basically sets BOOST_ROOT and
BOOST_LIBRARYDIR automatically in some cases.
https://gist.github.com/rpavlik/586f1fda6e32777623e1
Ryan
On Fri, Nov 14, 2014 at 6:56 AM, Glenn Coombs glenn.coo...@gmail.com
wrote:
Hi,
I have installed Boost on Windows 7 for Visual Studio 2013 by running
these installers:
boost_1_56_0-msvc-12.0-32.exe
boost_1_56_0-msvc-12.0-64.exe
downloaded from
http://sourceforge.net/projects/boost/files/boost-binaries/1.56.0/.
I'm using CMake 2.8.12.1 and when I try to build a simple Boost example
using the filesystem library my cmake configuration step fails to find the
required libraries unless I use the BOOST_LIBRARYDIR variable to tell it
where the libraries are:
set(BOOST_VERSION_NEEDED 1.53.0)
if (MSVC)
set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIMEON)
# set(BOOST_LIBRARYDIR/Boost/boost_1_56_0/lib64-msvc-12.0)
endif()
find_package(Boost ${BOOST_VERSION_NEEDED} REQUIRED COMPONENTS system
filesystem)
Given that the library directory is where the official Boost installer
put it shouldn't the FindBoost.cmake package be checking that directory by
default ?
This is the output from CMake:
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:476 ] _boost_TEST_VERSIONS =
1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:478 ] Boost_USE_MULTITHREADED =
ON
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:480 ] Boost_USE_STATIC_LIBS = ON
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:482 ] Boost_USE_STATIC_RUNTIME
= ON
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:484 ] Boost_ADDITIONAL_VERSIONS
=
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:486 ] Boost_NO_SYSTEM_PATHS =
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:538 ] Declared as CMake or
Environmental Variables:
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:540 ] BOOST_ROOT =
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:542 ] BOOST_INCLUDEDIR =
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:544 ] BOOST_LIBRARYDIR =
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:546 ] _boost_TEST_VERSIONS =
1.56.0;1.56;1.55.0;1.55;1.54.0;1.54;1.53.0;1.53
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:639 ] location of version.hpp:
C:/Boost/boost_1_56_0/boost/version.hpp
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:663 ] version.hpp reveals boost
1.56.0
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:739 ] guessed _boost_COMPILER =
-vc120
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:749 ] _boost_MULTITHREADED = -mt
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:792 ] _boost_RELEASE_ABI_TAG =
-s
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:794 ] _boost_DEBUG_ABI_TAG =
-sgd
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:842 ]
_boost_LIBRARY_SEARCH_DIRS =
C:/Boost/boost_1_56_0/lib;C:/Boost/boost_1_56_0/../lib;C:/Boost/boost_1_56_0/stage/lib;PATHS;C:/boost/lib;C:/boost;/sw/local/lib
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:930 ] Searching for
SYSTEM_LIBRARY_RELEASE:
libboost_system-vc120-mt-s-1_56;libboost_system-vc120-mt-s;libboost_system-mt-s-1_56;libboost_system-mt-s;libboost_system
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:966 ] Searching for
SYSTEM_LIBRARY_DEBUG:
libboost_system-vc120-mt-sgd-1_56;libboost_system-vc120-mt-sgd;libboost_system-mt-sgd-1_56;libboost_system-mt-sgd;libboost_system-mt;libboost_system
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:930 ] Searching for
FILESYSTEM_LIBRARY_RELEASE:
libboost_filesystem-vc120-mt-s-1_56;libboost_filesystem-vc120-mt-s;libboost_filesystem-mt-s-1_56;libboost_filesystem-mt-s;libboost_filesystem
[ C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/FindBoost.cmake:966 ] Searching for
FILESYSTEM_LIBRARY_DEBUG
Re: [CMake] How to get custom commands to build in parallel ?
I am already using /MP and the equivalent to the /maxcpucount. It is the
/MP one that is important in this context as I am only concerned with
improving the speed of a single project out of the many in my solution. I
believe the problem is with cmake rather than with Visual Studio as I can
select any of the other projects in the same solution and build them in
isolation and they will build their object files in parallel. For some
reason cmake isn't seeing the custom commands as something it can run in
parallel.
--
Glenn
On 23 September 2014 16:20, Robert Maynard robert.mayn...@kitware.com
wrote:
If you are using VS2013 you should look at the /maxcpucount flag which
allows msbuild to build multiple projects at the same time. You will
have to manually balance /MP and /maxcpucount as they cause a P*C
number of processes to execute.
On Tue, Sep 23, 2014 at 11:05 AM, Glenn Coombs glenn.coo...@gmail.com
wrote:
I have the following code in one of my CMakeLists.txt files:
set(feature_files_h)
set(feature_files_cpp)
macro(create_feature_files NAME)
add_custom_command(
OUTPUT ${FEATURES_OUTPUT_DIR}/${NAME}.cpp
${FEATURES_OUTPUT_DIR}/${NAME}.h
DEPENDS ${FEATURES_INPUT_DIR}/${NAME}.txt
WORKING_DIRECTORY ${SIM_ROOT}/tools/features
COMMAND perl ${FEATURES_PERL_PATH} -s${FEATURES_INPUT_DIR}
-d${FEATURES_OUTPUT_DIR} -f${NAME}
)
list(APPEND feature_files_h ${FEATURES_OUTPUT_DIR}/${NAME}.h)
list(APPEND feature_files_cpp ${FEATURES_OUTPUT_DIR}/${NAME}.cpp)
endmacro()
create_feature_files(example_features)
create_feature_files(fme_core_features)
create_feature_files(fme_features)
create_feature_files(front_end_features)
create_feature_files(inloop_filter_features)
add_library(${PROJECT_NAME} STATIC ${feature_files_cpp}
${feature_files_h}
${SIM_ROOT}/tools/features/cpp-code/cfeatures.cpp)
which creates a library from an existing source file called cfeatures.cpp
and from a bunch of auto-generated .cpp and .h files. The whole thing
works
fine and runs the perl script to create each of the auto-generated files
before creating the library. The only problem I have with it is that it
is
quite slow and I would like to speed it up by having it run the perl
commands to create the auto-generated files in parallel. Currently,
each of
the auto-generated cpp files is generated sequentially, then they are all
compiled in parallel and the library created in the final step.
I'm using cmake 3.0.0 with Visual Studio 2013 Express Edition. And I've
added the /MP option so that Visual Studio will do parallel builds. I've
also set the Projects and Solutions=Build and Run=maximum number of
parallel project builds option to 4. This works well with all the
normal
cpp files in other projects and I easily see all 4 cpu cores maxxed out.
But when building this project only 1 cpu core is used.
Can anybody tell me how to change it so that the auto-geneated files are
created in parallel as well ?
--
Glenn
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] How to get custom commands to build in parallel ?
I have the following code in one of my CMakeLists.txt files:
set(feature_files_h)
set(feature_files_cpp)
macro(create_feature_files NAME)
add_custom_command(
OUTPUT ${FEATURES_OUTPUT_DIR}/${NAME}.cpp
${FEATURES_OUTPUT_DIR}/${NAME}.h
DEPENDS ${FEATURES_INPUT_DIR}/${NAME}.txt
WORKING_DIRECTORY ${SIM_ROOT}/tools/features
COMMAND perl ${FEATURES_PERL_PATH} -s${FEATURES_INPUT_DIR}
-d${FEATURES_OUTPUT_DIR} -f${NAME}
)
list(APPEND feature_files_h ${FEATURES_OUTPUT_DIR}/${NAME}.h)
list(APPEND feature_files_cpp ${FEATURES_OUTPUT_DIR}/${NAME}.cpp)
endmacro()
create_feature_files(example_features)
create_feature_files(fme_core_features)
create_feature_files(fme_features)
create_feature_files(front_end_features)
create_feature_files(inloop_filter_features)
add_library(${PROJECT_NAME} STATIC ${feature_files_cpp} ${feature_files_h}
${SIM_ROOT}/tools/features/cpp-code/cfeatures.cpp)
which creates a library from an existing source file called cfeatures.cpp
and from a bunch of auto-generated .cpp and .h files. The whole thing
works fine and runs the perl script to create each of the auto-generated
files before creating the library. The only problem I have with it is that
it is quite slow and I would like to speed it up by having it run the perl
commands to create the auto-generated files in parallel. Currently, each
of the auto-generated cpp files is generated sequentially, then they are
all compiled in parallel and the library created in the final step.
I'm using cmake 3.0.0 with Visual Studio 2013 Express Edition. And I've
added the /MP option so that Visual Studio will do parallel builds. I've
also set the Projects and Solutions=Build and Run=maximum number of
parallel project builds option to 4. This works well with all the normal
cpp files in other projects and I easily see all 4 cpu cores maxxed out.
But when building this project only 1 cpu core is used.
Can anybody tell me how to change it so that the auto-geneated files are
created in parallel as well ?
--
Glenn
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Resetting CMAKE_Fortran_FLAGS for a specific file
In my opinion this is a deficiency in how cmake currently works with object
libraries. If one of the source files in an object library depends on a
third library then it should be possible to specify that in the link
interface of either the object library or the source file. It is wrong to
have to specify the dependency multiple times for every library or
executable that uses the object library. It is a property of the object
library, not the users of the object library.
I believe there is already a enhancement request open for something like
this.
--
Glenn
On 13 August 2014 15:44, marco restelli mreste...@gmail.com wrote:
2014-08-13 16:16 GMT+0200, Mark Abraham mark.j.abra...@gmail.com:
On Wed, Aug 13, 2014 at 7:12 AM, marco restelli mreste...@gmail.com
wrote:
2014-08-13 15:53 GMT+0200, Mark Abraham mark.j.abra...@gmail.com:
On Wed, Aug 13, 2014 at 3:18 AM, marco restelli mreste...@gmail.com
wrote:
Hi Petr,
thanks, very informative!
2014-08-13 9:20 GMT+0200, Petr Kmoch petr.km...@gmail.com:
Hi Marco.
Sane compilers allow later command-line options to override earlier
ones,
so what you're doing should be fine. Unfortunately, I know some
Fortran
compilers are not sane in this regard.
Here, I would really like to reduce as much as possible the flags
regardless of the chosen compiler, so undoing the chosen flags
seems to me cumbersome and compiler dependent, compared to resetting
them altogether. I like the idea of OBJECT libraries better (it also
solves other problems I have, I did not know about it!).
If you really need to solve this by explicitly modifying the global
list
for a particular file, the only thing I can think of is move those
files
to
a separate CMakeList and turn them into an object library:
This almost works, I have a problem specifying liking dependencies
for
the OBJECT libraries. With a normal library, I can use
TARGET_LINK_LIBRARIES( my_library ${other_libs_my_library_depends_on}
)
but if my_library is OBJECT I see the error
Object library target my_library may not link to anything.
See http://www.cmake.org/cmake/help/v3.0/command/add_library.html for
the
correct way to do things with object libraries - for this purpose,
they
are
closer to source files than libraries, which makes sense given that
there's
not actually a library written to disk anywhere.
Mark, thanks, but here I don't find anything that answers my question,
namely specifying that my OBJECT library (i.e. the files included in
it) require other libraries for linking.
The object library is never linked, so the issue of linking with it or to
it does not arise. The targets that use the object library have
transitive
linking dependencies, just like you had if the source files in the object
library had been directly specified as part of those targets.
OK, let me see if I understad it. Using the example in
http://www.cmake.org/Wiki/CMake/Tutorials/Object_Library
let us say I have
# A/CMakeLists.txt
add_library(A OBJECT ${A_srcs})
# B/CMakeLists.txt
add_library(B OBJECT ${B_srcs})
# CMakeLists.txt
add_subdirectory(A)
add_subdirectory(B)
add_library(big ${other_srcs} $TARGET_OBJECTS:A $TARGET_OBJECTS:B)
and I know that whenever I link the files listed in ${A_srcs}, i.e.
whenever I likd the OBJECT library A, I also need to link
libsomeotherlibrary.a . Then in the main CMakeLists.txt I add
TARGET_LINK_LIBRARIES( big someotherlibrary )
right?
Moreover, there is no way to specify someotherlibrary in
A/CMakeLists.txt, it has to be done where I define the target big,
namely in the main CMakeLists.txt. Is this correct?
Thanks,
Marco
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
Re: [CMake] cmake version/feature detection
If you know which version of cmake first introduced the feature you want to check for then you could base your decision on the values of these 3 cmake variables: CMAKE_MAJOR_VERSION CMAKE_MINOR_VERSION CMAKE_PATCH_VERSION -- Glenn On 5 August 2014 04:30, Leif Walsh leif.wa...@gmail.com wrote: Hi, I'm wondering what is the best way to do feature detection or version checking of cmake itself, in cmake. In particular, I'd like to check for the OBJECT library feature and either use it or fall back to our current mechanism if we're using an older cmake. -- Cheers, Leif -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Is it possible for a dependee to use the dependency LINKER_FLAGS ?
I just tried reproducing your 2 examples. Setup 1 works fine for me with
no messages about policy CMP0022. The only way I could get that message
produced was by omitting the cmake_minimum_required(VERSION 3.0) line. Are
you sure you're running the exact same CMakeLists.txt file that you have
posted here ?
For setup 2 I get the same results as you. CMake seems to insist on
converting the forward slash into a backwards slash, probably because it
thinks it is a file path, which totally screws things up. I suspect this
is a bug in cmake: adding linker flags like this works for linux because it
doesn't mess with strings like -Wl,-Bstatic. The only workaround I can
suggest is to set CMAKE_EXE_LINKER_FLAGS:
if (MSVC)
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS}
/FORCE:Multiple)
endif()
which correctly adds the option you want but it will do it for all
libraries in the current context. In order to only have it applied to the
one library you would need to have a separate CMakeLists.txt for that
library and add the lines above to adjust the CMAKE_EXE_LINKER_FLAGS only
in that CMakeLists.txt. Then you would have to do and
add_subdirectory(special_lib) somewhere in your higher level CMakeLists.txt.
--
Glenn
On 3 August 2014 07:43, Adrian M Negreanu gro...@gmail.com wrote:
I've tested this with vs 2013 but a few things makes me think
that using target_link_libraries is not for this type of usage.
First, for setup 1:
= CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
add_library(A a.cpp)
target_link_libraries(A INTERFACE -custom-flags)
add_executable(E e.cpp)
target_link_libraries(E A)
###
Cmake warns me:
CMake Warning (dev) in CMakeLists.txt:
Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
interface. Run cmake --help-policy CMP0022 for policy details. Use
the
cmake_policy command to set the policy and suppress this warning.
Target A has an INTERFACE_LINK_LIBRARIES property. This should be
preferred as the source of the link interface for this library but
because
CMP0022 is not set CMake is ignoring the property and using the link
implementation as the link interface instead.
INTERFACE_LINK_LIBRARIES:
/FORCE:multiple
For setup 2:
= CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
add_library(A a.cpp)
set_target_properties(A PROPERTIES INTERFACE_LINK_LIBRARIES
/FORCE:multiple)
add_executable(E e.cpp)
target_link_libraries(E A)
###
Cmake works fine, _but_ /FORCE:multiple is seen as a file, which leads
to error:
1-- Build started: Project: ZERO_CHECK, Configuration: Debug Win32
--
2-- Build started: Project: A, Configuration: Debug Win32 --
2 A.vcxproj - C:\Users\amnegrea\Debug\A.lib
3-- Build started: Project: E, Configuration: Debug Win32 --
3LINK : fatal error LNK1104: cannot open file '\FORCE:multiple.obj'
4-- Skipped Build: Project: ALL_BUILD, Configuration: Debug Win32
--
4Project not selected to build for this solution configuration
== Build: 2 succeeded, 1 failed, 0 up-to-date, 1 skipped ==
On Sat, Aug 2, 2014 at 7:38 PM, Walter Gray chrysal...@gmail.com wrote:
Glen is correct. You should take a look at the docs for interface modules
here:
http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#interface-libraries
I also put up some examples of how to do this on github a while back.
https://github.com/wal-rus/cmake-modules
Hope that helps! Also for future googling the concept is called Usage
Requirements.
On Aug 2, 2014 8:11 AM, Glenn Coombs glenn.coo...@gmail.com wrote:
I think that you can use the target_link_libraries command to do this:
add_library(A a.cpp)
target_link_libraries(A INTERFACE -custom-flags)
--
Glenn
On 30 July 2014 16:51, Adrian M Negreanu gro...@gmail.com wrote:
Hi,
Is it possible to attach a property on a target, and that property
to be used whenever the target is used ?
ex:
add_library(A a.cpp)
somehow_attach_LINK_FLAGS(A --custom-flags)
# in a different directory
add_executable(E e.cpp)
target_link_libraries(E A)
# ^--- this would do something similiar to
set_target_properties(E PROPERTIES LINK_FLAGS --custom-flags)
For example, to use A:LINK_FLAGS
Thanks
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For
more information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http
Re: [CMake] Spaces in a command
Not for me it doesn't:
$ make VERBOSE=yes
/usr/bin/cmake -H/home/glenn/src/cmake-test
-B/home/glenn/src/cmake-test/build --check-build-system
CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start
/home/glenn/src/cmake-test/build/CMakeFiles
/home/glenn/src/cmake-test/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/glenn/src/cmake-test/build'
make -f CMakeFiles/do-foo.dir/build.make CMakeFiles/do-foo.dir/depend
make[2]: Entering directory `/home/glenn/src/cmake-test/build'
cd /home/glenn/src/cmake-test/build /usr/bin/cmake -E cmake_depends
Unix Makefiles /home/glenn/src/cmake-test /home/glenn/src/cmake-test
/home/glenn/src/cmake-test/build /home/glenn/src/cmake-test/build
/home/glenn/src/cmake-test/build/CMakeFiles/do-foo.dir/DependInfo.cmake
--color=
make[2]: Leaving directory `/home/glenn/src/cmake-test/build'
make -f CMakeFiles/do-foo.dir/build.make CMakeFiles/do-foo.dir/build
make[2]: Entering directory `/home/glenn/src/cmake-test/build'
/usr/bin/cmake -E cmake_progress_report
/home/glenn/src/cmake-test/build/CMakeFiles 1
[100%] Generating foo
generate-foo || echo \no big deal\
make[2]: Leaving directory `/home/glenn/src/cmake-test/build'
/usr/bin/cmake -E cmake_progress_report
/home/glenn/src/cmake-test/build/CMakeFiles 1
[100%] Built target do-foo
make[1]: Leaving directory `/home/glenn/src/cmake-test/build'
/usr/bin/cmake -E cmake_progress_start
/home/glenn/src/cmake-test/build/CMakeFiles 0
I'm seeing the || outside of the double quotes. This is on Kubuntu 14.10
with cmake 2.8.12.2.
--
Glenn
On 29 July 2014 20:57, Bill Newcomb bnewc...@nvidia.com wrote:
On linux, at least, this results in there being double quotes around the
||, which causes it to not be interpreted by the shell.
B.
On 07/29/2014 12:25 PM, Glenn Coombs wrote:
I think this works like you want:
cmake_minimum_required(VERSION 2.6)
set(DO_RELAX 1)
if(DO_RELAX)
set(OR_RELAX || echo \no big deal\)
else()
set(OR_RELAX)
endif()
add_custom_command(OUTPUT foo COMMAND generate-foo ${OR_RELAX} VERBATIM)
add_custom_target(do-foo ALL DEPENDS foo)
--
Glenn
On 29 July 2014 19:19, J Decker d3c...@gmail.com
mailto:d3c...@gmail.com wrote:
can try removing the quotes and subst space for semicolon?
On Tue, Jul 29, 2014 at 11:13 AM, Bill Newcomb bnewc...@nvidia.com
mailto:bnewc...@nvidia.com wrote:
That doesn't work either:
foo:
$(CMAKE_COMMAND) -E cmake_progress_report
/home/bnewcomb/tmp/cmake-tests/custom-or/CMakeFiles
$(CMAKE_PROGRESS_1)
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR)
--blue --bold Generating foo
generate-foo || echo \no big deal\
The whole string gets passed as the first argument to
generate-foo.
B.
On 07/25/2014 09:43 AM, Iosif Neitzke wrote:
If VERBATIM is given then all arguments to the commands will
be
escaped properly for the build tool so that the invoked command
receives each argument unchanged. Note that one level of
escapes is
still used by the CMake language processor before
add_custom_command
even sees the arguments. Use of VERBATIM is recommended as it
enables
correct behavior. When VERBATIM is not given the behavior is
platform
specific because there is no protection of tool-specific
special
characters.
http://www.cmake.org/cmake/help/v3.0/command/add_custom_
command.html
On Fri, Jul 25, 2014 at 11:20 AM, Bill Newcomb
bnewc...@nvidia.com mailto:bnewc...@nvidia.com wrote:
I want to add stuff to a custom command based on some
definition:
cmake_minimum_required(VERSION 2.6)
set(DO_RELAX 1)
if(DO_RELAX)
set(OR_RELAX || echo \no big deal\)
else()
set(OR_RELAX )
endif()
add_custom_command(OUTPUT foo COMMAND generate-foo
${OR_RELAX})
add_custom_target(do-foo ALL DEPENDS foo)
However, this produces the following rule in the generated
makefile:
foo:
$(CMAKE_COMMAND) -E cmake_progress_report
/home/bnewcomb/tmp/cmake-tests/custom-or/CMakeFiles
$(CMAKE_PROGRESS_1)
@$(CMAKE_COMMAND) -E cmake_echo_color
--switch=$(COLOR) --blue --bold Generating foo
generate-foo ||\ echo\ no\ big\ deal
Is there some way I can get cmake to not escape all of the
spaces in the value of OR_RELAX?
Thanks,
B
Re: [CMake] Is it possible for a dependee to use the dependency LINKER_FLAGS ?
I think that you can use the target_link_libraries command to do this: add_library(A a.cpp) target_link_libraries(A INTERFACE -custom-flags) -- Glenn On 30 July 2014 16:51, Adrian M Negreanu gro...@gmail.com wrote: Hi, Is it possible to attach a property on a target, and that property to be used whenever the target is used ? ex: add_library(A a.cpp) somehow_attach_LINK_FLAGS(A --custom-flags) # in a different directory add_executable(E e.cpp) target_link_libraries(E A) # ^--- this would do something similiar to set_target_properties(E PROPERTIES LINK_FLAGS --custom-flags) For example, to use A:LINK_FLAGS Thanks -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Spaces in a command
I think this works like you want:
cmake_minimum_required(VERSION 2.6)
set(DO_RELAX 1)
if(DO_RELAX)
set(OR_RELAX || echo \no big deal\)
else()
set(OR_RELAX)
endif()
add_custom_command(OUTPUT foo COMMAND generate-foo ${OR_RELAX} VERBATIM)
add_custom_target(do-foo ALL DEPENDS foo)
--
Glenn
On 29 July 2014 19:19, J Decker d3c...@gmail.com wrote:
can try removing the quotes and subst space for semicolon?
On Tue, Jul 29, 2014 at 11:13 AM, Bill Newcomb bnewc...@nvidia.com
wrote:
That doesn't work either:
foo:
$(CMAKE_COMMAND) -E cmake_progress_report
/home/bnewcomb/tmp/cmake-tests/custom-or/CMakeFiles $(CMAKE_PROGRESS_1)
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --blue
--bold Generating foo
generate-foo || echo \no big deal\
The whole string gets passed as the first argument to generate-foo.
B.
On 07/25/2014 09:43 AM, Iosif Neitzke wrote:
If VERBATIM is given then all arguments to the commands will be
escaped properly for the build tool so that the invoked command
receives each argument unchanged. Note that one level of escapes is
still used by the CMake language processor before add_custom_command
even sees the arguments. Use of VERBATIM is recommended as it enables
correct behavior. When VERBATIM is not given the behavior is platform
specific because there is no protection of tool-specific special
characters.
http://www.cmake.org/cmake/help/v3.0/command/add_custom_command.html
On Fri, Jul 25, 2014 at 11:20 AM, Bill Newcomb bnewc...@nvidia.com
wrote:
I want to add stuff to a custom command based on some definition:
cmake_minimum_required(VERSION 2.6)
set(DO_RELAX 1)
if(DO_RELAX)
set(OR_RELAX || echo \no big deal\)
else()
set(OR_RELAX )
endif()
add_custom_command(OUTPUT foo COMMAND generate-foo ${OR_RELAX})
add_custom_target(do-foo ALL DEPENDS foo)
However, this produces the following rule in the generated makefile:
foo:
$(CMAKE_COMMAND) -E cmake_progress_report
/home/bnewcomb/tmp/cmake-tests/custom-or/CMakeFiles $(CMAKE_PROGRESS_1)
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR)
--blue --bold Generating foo
generate-foo ||\ echo\ no\ big\ deal
Is there some way I can get cmake to not escape all of the
spaces in the value of OR_RELAX?
Thanks,
B.
---
This email message is for the sole use of the intended recipient(s)
and may contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact
the sender by
reply email and destroy all copies of the original message.
---
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For
more information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
Re: [CMake] How to get a list of all the static libraries that a target will link against ?
I think I have found a way to work round this. Instead of trying to get a
list of all the static libraries that a target will link against I will
modify the various libraries so that they add their library dependencies
like this:
target_link_libraries(mtx_wrapper PUBLIC
$$STREQUAL:$TARGET_PROPERTY:TYPE,SHARED_LIBRARY:-Wl,-whole-archive
${MTXSIM_LIBRARIES}
$$STREQUAL:$TARGET_PROPERTY:TYPE,SHARED_LIBRARY:-Wl,-no-whole-archive
$$STREQUAL:$CXX_COMPILER_ID,GNU:dl
$$STREQUAL:$CXX_COMPILER_ID,Clang:dl
This should mean that all the dependent libraries get wrapped inside
-whole-archive/-no-whole-archive pairs when the target being linked is a
shared library. And if the target being linked is an executable then the
-whole-archive/-no-whole-archive options should automatically be omitted.
Initial tests indicate that this approach will work but I have encountered
a bug which slightly complicates the issue:
http://www.cmake.org/Bug/view.php?id=15034
Essentially, the -no-whole-archive option sometimes gets omitted unless
prefixed by some other command.
--
Glenn
On 21 July 2014 19:24, Angeliki Chrysochou angeliki.chrysoc...@gmail.com
wrote:
Well try it and see if it works. If you set this variable in a specific
CMakeLists file, it will affect the specific add_library (or
add_executable) that is in that CMakeLists file. With this way you can
control which libraries/executables will be linked with these flags, and
this is the level of control you have.
Cheers!
Angeliki
On Mon, Jul 21, 2014 at 7:05 PM, Glenn Coombs glenn.coo...@gmail.com
wrote:
The problem is that I need to add both -whole-archive and
-no-whole-archive options. And I need to control exactly where they occur
so that only my libraries occur inside the whole archive section. I'd be
happy to be proven wrong but I don't think setting CMAKE_EXE_LINKER_FLAGS
will give me that level of control.
--
Glenn
On 21 July 2014 09:57, Angeliki Chrysochou angeliki.chrysoc...@gmail.com
wrote:
Hi Glenn,
Adding linker flags exactly in target_link_libraries is not a very good
practice in my opinion. To add specific linker flags to an executable, you
can use the variable CMAKE_EXE_LINKER_FLAGS, which you can edit before
calling add_executable. You could set this variable accordingly in your
static and dynamic CMakeLists.txt to include the flags you wish in the
following way:
set(CMAKE_EXE_LINKER_FLAGS -whole-archive)
If you set this variable to include more custom linker flags which you
want to preserve across libraries, then you should set it in the following
way to preserve its old value:
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -whole-archive)
If you want to edit linker flags for a shared library or a module target
you can use these cmake variables (set them before add_library):
CMAKE_SHARED_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS
Be aware that variables have CMakeLists.txt file scope, so if you set
different values in one CMakeLists.txt then they might get overwritten or
appended (depending on the way you edit the variable).
All the best,
Angeliki
On Sat, Jul 19, 2014 at 2:39 PM, Glenn Coombs glenn.coo...@gmail.com
wrote:
Don't all shout at once :-) I'm guessing there are no easy solutions
then...
--
Glenn
On 28 June 2014 14:33, Glenn Coombs glenn.coo...@gmail.com wrote:
I have a project which compiles and links into both a stand alone
executable and a dynamic shared library. The library and the executable
link against the same project libraries but have different object files
containing their entry points: main.o for the executable and dll_main.o
for
the library. My project heirarchy looks like this (simplified a bit for
brevity):
CMakeLists.txt
mtx_source/CMakeLists.txt
mtx_wrapper/CMakeLists.txt
testbench/CMakeLists.txt
The top level CMakeLists.txt calls add_subdirectory on the various
project specific library folders which each build a static library. The
testbench folder is the one that builds both the executable and the
dynamic
library. When building the dynamic library I need to use the linker
options -whole-archive and -no-whole-archive to force my static project
libraries to be included into the dynamic library. The problem is how to
insert the -whole-archive and -no-whole-archive options so that they
select
the correct set of libraries. Currently in the testbench CMakeLists.txt
file I have these lines:
set(libs
VLC
mvea
${SYSTEMC_SUPPORT_LIBRARIES}
${DEVIFSLAVE_LIBRARIES}
${SYSTEMC_LIBRARIES}
${SIM_UTILS_LIBRARIES}
${HWDEBUG_LIBRARIES}
)
if (NOT STUB_OUT_MTX)
list(APPEND libs mtx_wrapper)
endif()
set(libs_dll ${libs} transif_slave)
if (UNIX)
list(INSERT libs_dll 0 -Wl,-whole-archive)
list(APPEND libs_dll -Wl,-no-whole-archive)
endif()
add_library ( csim_dll SHARED ${sources_dll} ${headers_dll} )
add_executable( testbench
Re: [CMake] How to get a list of all the static libraries that a target will link against ?
The problem is that I need to add both -whole-archive and -no-whole-archive
options. And I need to control exactly where they occur so that only my
libraries occur inside the whole archive section. I'd be happy to be
proven wrong but I don't think setting CMAKE_EXE_LINKER_FLAGS will give me
that level of control.
--
Glenn
On 21 July 2014 09:57, Angeliki Chrysochou angeliki.chrysoc...@gmail.com
wrote:
Hi Glenn,
Adding linker flags exactly in target_link_libraries is not a very good
practice in my opinion. To add specific linker flags to an executable, you
can use the variable CMAKE_EXE_LINKER_FLAGS, which you can edit before
calling add_executable. You could set this variable accordingly in your
static and dynamic CMakeLists.txt to include the flags you wish in the
following way:
set(CMAKE_EXE_LINKER_FLAGS -whole-archive)
If you set this variable to include more custom linker flags which you
want to preserve across libraries, then you should set it in the following
way to preserve its old value:
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -whole-archive)
If you want to edit linker flags for a shared library or a module target
you can use these cmake variables (set them before add_library):
CMAKE_SHARED_LINKER_FLAGS
CMAKE_MODULE_LINKER_FLAGS
Be aware that variables have CMakeLists.txt file scope, so if you set
different values in one CMakeLists.txt then they might get overwritten or
appended (depending on the way you edit the variable).
All the best,
Angeliki
On Sat, Jul 19, 2014 at 2:39 PM, Glenn Coombs glenn.coo...@gmail.com
wrote:
Don't all shout at once :-) I'm guessing there are no easy solutions
then...
--
Glenn
On 28 June 2014 14:33, Glenn Coombs glenn.coo...@gmail.com wrote:
I have a project which compiles and links into both a stand alone
executable and a dynamic shared library. The library and the executable
link against the same project libraries but have different object files
containing their entry points: main.o for the executable and dll_main.o for
the library. My project heirarchy looks like this (simplified a bit for
brevity):
CMakeLists.txt
mtx_source/CMakeLists.txt
mtx_wrapper/CMakeLists.txt
testbench/CMakeLists.txt
The top level CMakeLists.txt calls add_subdirectory on the various
project specific library folders which each build a static library. The
testbench folder is the one that builds both the executable and the dynamic
library. When building the dynamic library I need to use the linker
options -whole-archive and -no-whole-archive to force my static project
libraries to be included into the dynamic library. The problem is how to
insert the -whole-archive and -no-whole-archive options so that they select
the correct set of libraries. Currently in the testbench CMakeLists.txt
file I have these lines:
set(libs
VLC
mvea
${SYSTEMC_SUPPORT_LIBRARIES}
${DEVIFSLAVE_LIBRARIES}
${SYSTEMC_LIBRARIES}
${SIM_UTILS_LIBRARIES}
${HWDEBUG_LIBRARIES}
)
if (NOT STUB_OUT_MTX)
list(APPEND libs mtx_wrapper)
endif()
set(libs_dll ${libs} transif_slave)
if (UNIX)
list(INSERT libs_dll 0 -Wl,-whole-archive)
list(APPEND libs_dll -Wl,-no-whole-archive)
endif()
add_library ( csim_dll SHARED ${sources_dll} ${headers_dll} )
add_executable( testbench ${sources} ${headers} )
target_link_libraries(csim_dll ${libs_dll} ${PTHREADS_LIBRARIES} )
target_link_libraries(testbench ${libs} ${PTHREADS_LIBRARIES} )
which produces the following link line:
/usr/bin/g++-4.7 -fPIC -m32 -m32 -m32 -fPIC -m32 -O3 -O3 -DHIDEBUG
-Wl,-Bsymbolic
-shared -Wl,-soname,libtopazhp.so
-o libtopazhp.so
CMakeFiles/csim_dll.dir/dll_main.cpp.o
CMakeFiles/csim_dll.dir/main_common.cpp.o
-lm -lrt -lm -lrt
-Wl,-whole-archive
../mvea/VLC/libVLC.a
../mvea/libmvea.a
../systemCSupport/libsystemc_support.a
../devif_slave/libDevifSlave.a
../systemC/libsystemc.a
../sim_utils/libsim_utils.a
../hwdebug/libhwDebug.a
../mtx_wrapper/libmtx_wrapper.a
../transif/libtransif_slave.a
-Wl,-no-whole-archive
-lpthread -lz
../systemC/libpthreads_dummy.a
../external_mtx/src/external_mtx-build/metag/libmetag.a
../external_mtx/src/external_mtx-build/metagcopro/libmetagcopro.a
../external_mtx/src/external_mtx-build/metac/vmetastub/libvmetastub.a
../external_mtx/src/external_mtx-build/metac/insim/libinsimfpu.a
../external_mtx/src/external_mtx-build/mtx/insim-mtxg/libinsim-mtxg.a
../external_mtx/src/external_mtx-build/mtx/libmtxc.a
-ldl -lm -lrt -lm -lrt
The problem is that the 6 external_mtx libraries should have been
included inside the -whole-archive section. These libraries are specified
in the mtx_wrapper folder with a target_link_libraries(mtx_wrapper
${METASIM_LIBRARIES}) command. I have managed to wrap the direct library
dependencies inside the -whole-archive but I need to ensure that any
sub-dependencies are included as well (and any
Re: [CMake] How to get a list of all the static libraries that a target will link against ?
Don't all shout at once :-) I'm guessing there are no easy solutions
then...
--
Glenn
On 28 June 2014 14:33, Glenn Coombs glenn.coo...@gmail.com wrote:
I have a project which compiles and links into both a stand alone
executable and a dynamic shared library. The library and the executable
link against the same project libraries but have different object files
containing their entry points: main.o for the executable and dll_main.o for
the library. My project heirarchy looks like this (simplified a bit for
brevity):
CMakeLists.txt
mtx_source/CMakeLists.txt
mtx_wrapper/CMakeLists.txt
testbench/CMakeLists.txt
The top level CMakeLists.txt calls add_subdirectory on the various project
specific library folders which each build a static library. The testbench
folder is the one that builds both the executable and the dynamic library.
When building the dynamic library I need to use the linker options
-whole-archive and -no-whole-archive to force my static project libraries
to be included into the dynamic library. The problem is how to insert the
-whole-archive and -no-whole-archive options so that they select the
correct set of libraries. Currently in the testbench CMakeLists.txt file I
have these lines:
set(libs
VLC
mvea
${SYSTEMC_SUPPORT_LIBRARIES}
${DEVIFSLAVE_LIBRARIES}
${SYSTEMC_LIBRARIES}
${SIM_UTILS_LIBRARIES}
${HWDEBUG_LIBRARIES}
)
if (NOT STUB_OUT_MTX)
list(APPEND libs mtx_wrapper)
endif()
set(libs_dll ${libs} transif_slave)
if (UNIX)
list(INSERT libs_dll 0 -Wl,-whole-archive)
list(APPEND libs_dll -Wl,-no-whole-archive)
endif()
add_library ( csim_dll SHARED ${sources_dll} ${headers_dll} )
add_executable( testbench ${sources} ${headers} )
target_link_libraries(csim_dll ${libs_dll} ${PTHREADS_LIBRARIES} )
target_link_libraries(testbench ${libs} ${PTHREADS_LIBRARIES} )
which produces the following link line:
/usr/bin/g++-4.7 -fPIC -m32 -m32 -m32 -fPIC -m32 -O3 -O3 -DHIDEBUG
-Wl,-Bsymbolic
-shared -Wl,-soname,libtopazhp.so
-o libtopazhp.so
CMakeFiles/csim_dll.dir/dll_main.cpp.o
CMakeFiles/csim_dll.dir/main_common.cpp.o
-lm -lrt -lm -lrt
-Wl,-whole-archive
../mvea/VLC/libVLC.a
../mvea/libmvea.a
../systemCSupport/libsystemc_support.a
../devif_slave/libDevifSlave.a
../systemC/libsystemc.a
../sim_utils/libsim_utils.a
../hwdebug/libhwDebug.a
../mtx_wrapper/libmtx_wrapper.a
../transif/libtransif_slave.a
-Wl,-no-whole-archive
-lpthread -lz
../systemC/libpthreads_dummy.a
../external_mtx/src/external_mtx-build/metag/libmetag.a
../external_mtx/src/external_mtx-build/metagcopro/libmetagcopro.a
../external_mtx/src/external_mtx-build/metac/vmetastub/libvmetastub.a
../external_mtx/src/external_mtx-build/metac/insim/libinsimfpu.a
../external_mtx/src/external_mtx-build/mtx/insim-mtxg/libinsim-mtxg.a
../external_mtx/src/external_mtx-build/mtx/libmtxc.a
-ldl -lm -lrt -lm -lrt
The problem is that the 6 external_mtx libraries should have been included
inside the -whole-archive section. These libraries are specified in the
mtx_wrapper folder with a target_link_libraries(mtx_wrapper
${METASIM_LIBRARIES}) command. I have managed to wrap the direct library
dependencies inside the -whole-archive but I need to ensure that any
sub-dependencies are included as well (and any dependencies they might have
recursively). Any system dynamic libaries (-ldl -lm -lrt etc.) must appear
after the -no-whole-archive option otherwise the link fails. The
mtx_wrapper library can be built in two ways and only one of them will add
the extra METASIM libraries as a dependency, the other way fakes that code
internally. Adding the METASIM libraries via target_link_libraries()
inside the mtx_wrapper CMakeLists.txt correctly handles that dependency
when linking the standalone executable but is not working for linking the
dynamic library.
Is there an easy way to get cmake to handle all this ? Is there a way to
get a list of all the static libraries (libXXX.a) that will be included on
the link line for a target ?
--
Glenn
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] How to get a list of all the static libraries that a target will link against ?
I have a project which compiles and links into both a stand alone
executable and a dynamic shared library. The library and the executable
link against the same project libraries but have different object files
containing their entry points: main.o for the executable and dll_main.o for
the library. My project heirarchy looks like this (simplified a bit for
brevity):
CMakeLists.txt
mtx_source/CMakeLists.txt
mtx_wrapper/CMakeLists.txt
testbench/CMakeLists.txt
The top level CMakeLists.txt calls add_subdirectory on the various project
specific library folders which each build a static library. The testbench
folder is the one that builds both the executable and the dynamic library.
When building the dynamic library I need to use the linker options
-whole-archive and -no-whole-archive to force my static project libraries
to be included into the dynamic library. The problem is how to insert the
-whole-archive and -no-whole-archive options so that they select the
correct set of libraries. Currently in the testbench CMakeLists.txt file I
have these lines:
set(libs
VLC
mvea
${SYSTEMC_SUPPORT_LIBRARIES}
${DEVIFSLAVE_LIBRARIES}
${SYSTEMC_LIBRARIES}
${SIM_UTILS_LIBRARIES}
${HWDEBUG_LIBRARIES}
)
if (NOT STUB_OUT_MTX)
list(APPEND libs mtx_wrapper)
endif()
set(libs_dll ${libs} transif_slave)
if (UNIX)
list(INSERT libs_dll 0 -Wl,-whole-archive)
list(APPEND libs_dll -Wl,-no-whole-archive)
endif()
add_library ( csim_dll SHARED ${sources_dll} ${headers_dll} )
add_executable( testbench ${sources} ${headers} )
target_link_libraries(csim_dll ${libs_dll} ${PTHREADS_LIBRARIES} )
target_link_libraries(testbench ${libs} ${PTHREADS_LIBRARIES} )
which produces the following link line:
/usr/bin/g++-4.7 -fPIC -m32 -m32 -m32 -fPIC -m32 -O3 -O3 -DHIDEBUG
-Wl,-Bsymbolic
-shared -Wl,-soname,libtopazhp.so
-o libtopazhp.so
CMakeFiles/csim_dll.dir/dll_main.cpp.o
CMakeFiles/csim_dll.dir/main_common.cpp.o
-lm -lrt -lm -lrt
-Wl,-whole-archive
../mvea/VLC/libVLC.a
../mvea/libmvea.a
../systemCSupport/libsystemc_support.a
../devif_slave/libDevifSlave.a
../systemC/libsystemc.a
../sim_utils/libsim_utils.a
../hwdebug/libhwDebug.a
../mtx_wrapper/libmtx_wrapper.a
../transif/libtransif_slave.a
-Wl,-no-whole-archive
-lpthread -lz
../systemC/libpthreads_dummy.a
../external_mtx/src/external_mtx-build/metag/libmetag.a
../external_mtx/src/external_mtx-build/metagcopro/libmetagcopro.a
../external_mtx/src/external_mtx-build/metac/vmetastub/libvmetastub.a
../external_mtx/src/external_mtx-build/metac/insim/libinsimfpu.a
../external_mtx/src/external_mtx-build/mtx/insim-mtxg/libinsim-mtxg.a
../external_mtx/src/external_mtx-build/mtx/libmtxc.a
-ldl -lm -lrt -lm -lrt
The problem is that the 6 external_mtx libraries should have been included
inside the -whole-archive section. These libraries are specified in the
mtx_wrapper folder with a target_link_libraries(mtx_wrapper
${METASIM_LIBRARIES}) command. I have managed to wrap the direct library
dependencies inside the -whole-archive but I need to ensure that any
sub-dependencies are included as well (and any dependencies they might have
recursively). Any system dynamic libaries (-ldl -lm -lrt etc.) must appear
after the -no-whole-archive option otherwise the link fails. The
mtx_wrapper library can be built in two ways and only one of them will add
the extra METASIM libraries as a dependency, the other way fakes that code
internally. Adding the METASIM libraries via target_link_libraries()
inside the mtx_wrapper CMakeLists.txt correctly handles that dependency
when linking the standalone executable but is not working for linking the
dynamic library.
Is there an easy way to get cmake to handle all this ? Is there a way to
get a list of all the static libraries (libXXX.a) that will be included on
the link line for a target ?
--
Glenn
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How to get find_package(ZLIB) to set ZLIB_LIBRARIES to 32-bit version ?
One of the nice things about cmake is that you can hide any complicated
build options inside the CMakeLists.txt file and present options to the
user via the cmake-gui. Your solution negates that - the user now has to
know which compiler they are using and which options are relevant where as
before all they did was select the option labelled build 32-bit from
inside of cmake-gui. When building using Visual Studio on Windows there
are separate generator options for the 32-bit and 64-bit builds so again
this is presented to the user via cmake-gui.
I'd really like to keep the cmake-gui as the sole interface for configuring
everything. Is there no way to get find_package to use the current value
of the COMPILE_OPTIONS variable as modified inside the top level
CMakeLists.txt file based on options set by the user inside cmake-gui ?
On 25 June 2014 07:18, Rolf Eike Beer e...@sf-mail.de wrote:
Am Dienstag, 24. Juni 2014, 22:32:22 schrieb Glenn Coombs:
This seems to be the recommended way to link against the zlib library:
find_package(ZLIB)if (ZLIB_FOUND)
include_directories(${ZLIB_INCLUDE_DIRS})
target_link_libraries(MyProg ${ZLIB_LIBRARIES})
endif()
When I run this on linux I see that ZLIB_LIBRARIES has the value
/usr/lib64/libz.so. On this machine gcc creates 64-bit binaries by
default. In my CMakeLists.txt I have an option for building 32-bit which
adds -m32 to the compiler and linker command lines. However the
ZLIB_LIBRARIES variable is still returning the 64-bit version
(/usr/lib64/libz.so) instead of the 32-bit version (/usr/lib/libz.so).
That means that CMake doesn't know that it is building a 32 bit executable,
which is a bad idea for reasons you already discovered. Try CC=gcc -m32
cmake ... in a clean build tree.
Eke
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] How to get find_package(ZLIB) to set ZLIB_LIBRARIES to 32-bit version ?
This seems to be the recommended way to link against the zlib library:
find_package(ZLIB)if (ZLIB_FOUND)
include_directories(${ZLIB_INCLUDE_DIRS})
target_link_libraries(MyProg ${ZLIB_LIBRARIES})
endif()
When I run this on linux I see that ZLIB_LIBRARIES has the value
/usr/lib64/libz.so. On this machine gcc creates 64-bit binaries by
default. In my CMakeLists.txt I have an option for building 32-bit which
adds -m32 to the compiler and linker command lines. However the
ZLIB_LIBRARIES variable is still returning the 64-bit version
(/usr/lib64/libz.so) instead of the 32-bit version (/usr/lib/libz.so).
Is there some way for me to let cmake know that I'm building 32-bit so that
the find_package(ZLIB) command sets ZLIB_LIBRARIES to the correct 32-bit
version of the library ?
--
Glenn
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
I thought they probably were. My question was really if the behaviour that results from that was desirable. I can't see any reason why they should be cached as they aren't user configurable variables. Would it break anything badly if they were not stored in the cache ? It would result in more consistent behaviour IMHO. -- Glenn On 28 April 2014 19:33, Matthew Woehlke mw_tr...@users.sourceforge.netwrote: On 2014-04-23 14:18, Glenn Coombs wrote: Are the [Project name]_SOURCE_DIR variables being automatically stored in the cmake cache? Running 'grep _SOURCE_DIR CMakeCache.txt' would answer this question. (And yes, they are.) -- Matthew -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/ opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
What I am saying is that project(foo) should internally execute the equivalent of set(foo_SOURCE_DIR /path/to/source) rather than set(foo /path/to/source CACHE STRING). That way it would fail on every run if you referenced a project source directory variable before you had done the add_subdirectory() for that project. Currently in that situation it fails the first time you run cmake but works as expected on subsequent runs of cmake, which I think is odd behaviour. On 1 May 2014 18:35, John Drescher dresche...@gmail.com wrote: I thought they probably were. My question was really if the behaviour that results from that was desirable. I can't see any reason why they should be cached as they aren't user configurable variables. Would it break anything badly if they were not stored in the cache ? It would result in more consistent behaviour IMHO. Executing cmake . would fail in the bin folder if it had no way to know where the source folder is. John -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
Okay, I think I understand what you're saying. Variables set in a CMakeLists.txt file added by add_subdirectory are only visible in that CMakeLists.txt and any further ones it adds via add_subdirectory. The higher level CMakeLists.txt files would not have the necessary visibility, hence the need to cache the project source directory variable. To make it behave consistently it would be necessary for cmake to be able to set a variable in the scope of the top level CMakeLists.txt. Similar to the PARENT_SCOPE that the set() command already has, something like set(foo_SOURCE_PROJECT path/to/source ROOT_SCOPE). I suspect that the reason cmake is caching these variable is because the set() command doesn't have a ROOT_SCOPE ability and using cache variables was the easiest way to simulate that. And we have to live with the unfortunate side effect that the cached variables don't exist on the first run but do on subsequent runs. On 1 May 2014 19:00, John Drescher dresche...@gmail.com wrote: On Thu, May 1, 2014 at 1:54 PM, Glenn Coombs glenn.coo...@gmail.com wrote: What I am saying is that project(foo) should internally execute the equivalent of set(foo_SOURCE_DIR /path/to/source) rather than set(foo /path/to/source CACHE STRING). That way it would fail on every run if you referenced a project source directory variable before you had done the add_subdirectory() for that project. Currently in that situation it fails the first time you run cmake but works as expected on subsequent runs of cmake, which I think is odd behaviour. I am saying making this change to not cache the source folder would break cmake binfolder and cmake --build buildfolder and several other commands that have worked this way for years. John -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
Ugh ! It gets messier. I'm beginning to understand why it is the way it is. The cmake developers have probably already been round this loop and decided it wasn't worth the effort :-) On 1 May 2014 19:41, Nils Gladitz nilsglad...@gmail.com wrote: On 01.05.2014 20:38, Glenn Coombs wrote: Okay, I think I understand what you're saying. Variables set in a CMakeLists.txt file added by add_subdirectory are only visible in that CMakeLists.txt and any further ones it adds via add_subdirectory. The higher level CMakeLists.txt files would not have the necessary visibility, hence the need to cache the project source directory variable. To make it behave consistently it would be necessary for cmake to be able to set a variable in the scope of the top level CMakeLists.txt. Similar to the PARENT_SCOPE that the set() command already has, something like set(foo_SOURCE_PROJECT path/to/source ROOT_SCOPE). I suspect that the reason cmake is caching these variable is because the set() command doesn't have a ROOT_SCOPE ability and using cache variables was the easiest way to simulate that. And we have to live with the unfortunate side effect that the cached variables don't exist on the first run but do on subsequent runs. I don't think it would be sufficient to set it in the root scope either since I think each scope has its own copy of the variable. It would have to be set for all scopes between the root and the current scope. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?
I'm using cmake version 2.8.12.1 and have just encountered an issue with my
cmake setup where I was using the [Project name]_SOURCE_DIR variable in an
include_directories command and it was being ignored. In my top level
CMakeLists.txt I had:
project(blah)
add_subdirectory(foo)
add_subdirectory(...)
...
add_subdirectory(bar)
and in the CMakeLists.txt in the foo directory:
include_directories(${bar_SOURCE_DIR})
The project failed to build because the foo project couldn't find header
files located in the bar project source directory. The fix was to move the
add_subdirectory(bar) before the add_subdirectory(foo) command. The
interesting thing is that this setup only caused an error when doing a
clean build from scratch. It looks like it only fails after a clean start
and a single run of the cmake generator. If you run cmake-gui and
configure more than once, as you may well do if you need to set some
options, then it appears to get the correct value for ${bar_SOURCE_DIR}.
Are the [Project name]_SOURCE_DIR variables being automatically stored in
the cmake cache, as that would explain what I am seeing ? I would expect
the above scenario to consistently fail every time due to the missing
header files. Having it only fail the first time and then work after
subsequent configure/generate steps is confusing. Is this a bug, or are
there occasions when this is desirable behaviour ?
--
Glenn
P.S. In an ideal world I'd like to see the expansion of the [Project
name]_SOURCE_DIR variables be deferred until after all the CMakeLists.txt
files have been read in so that the order doesn't matter, but I'm guessing
that isn't going to happen :-)
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack: Ignoring files using regex
The regexp you're using matches anything where the last character at the end of the line isn't one of the characters inside the square brackets. I don't think cmake's regexps allow negation of words so specifying a regexp that matches everything except projectA/, README and CMakelists.txt is going to be tricky. You could just list the known items that you do want to ignore. Something like this: set(CPACK_SOURCE_IGNORE_FILES /build/;/extrafiles/;/temp/) will hopefully ignore directories called build, extrafiles and temp. It isn't exactly what you want but might help. On 29 July 2013 19:40, Chris Wood c.c.w...@gmail.com wrote: I'm trying to get my head round CMake's regex implementation; I have a folder containing 4 folder and 2 text files: build/ projectA/ CMakeLists.txt extrafiles/ README temp/ one line of CMakeLists.txt is: set(CPACK_SOURCE_IGNORE_FILES [^projectA]$) in my source package that is ten subsequently generated, `build/` `projectA/` and `extrafiles` are present, but `temp/` and the 2 text files are not. I'm trying to get to a stage where the regex will ignore everything in the folder except for `projectA/`, `README` and `CMakeLists.txt`, but can't work out at the moment how the regex I've supplied is giving those results. Any insight will be greatly appreciated! Chris -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned
I won't bother just yet then. Let me know if I can be of any help in testing your fix. BTW, is your fix likely to make it into the pending 2.8.11 release ? -- Glenn On 5 May 2013 19:33, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Sunday 05 May 2013, Glenn Coombs wrote: Alex, Would you like me to file a bug report on this ? you can do so, but I'm working on a fix already anyway. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned
Alex,
Would you like me to file a bug report on this ?
--
Glenn
On 1 May 2013 08:33, Glenn Coombs glenn.coo...@gmail.com wrote:
I select Clean Solution from the Build menu which is a complete clean.
The output looks like this:
1-- Skipped Clean: Project: INSTALL, Configuration: Debug Win32 --
1Project not selected to build for this solution configuration
2-- Clean started: Project: ALL_BUILD, Configuration: Debug Win32
--
3-- Clean started: Project: yuv_player, Configuration: Debug Win32
--
4-- Clean started: Project: yuv_player_automoc, Configuration: Debug
Win32 --
5-- Clean started: Project: ZERO_CHECK, Configuration: Debug Win32
--
== Clean: 4 succeeded, 0 failed, 1 skipped ==
The yuv_player_automoc project looks like it is being cleaned but the
associated moc_*.cpp and yuv_player_automoc.cpp files are never deleted.
After doing a Clean Solution and manually deleting the
yuv_player_automoc.cpp file a build works as expected:
1-- Build started: Project: ZERO_CHECK, Configuration: Debug Win32
--
2-- Build started: Project: yuv_player_automoc, Configuration: Debug
Win32 --
1 Checking Build System
2 Automoc for target yuv_player
1 CMake does not need to re-run because
C:/data/perforceCheckouts/sim/tools/yuvplayer/DEV/glenn.coombs/cmake/CMakeFiles/generate.stamp
is up-to-date.
2 Generating moc_ctrlBasic.cpp
2 Generating moc_ctrlmenu.cpp
2 Generating moc_infoWin.cpp
2 Generating moc_imageDisplay.cpp
2 Generating moc_imageDisplayGL.cpp
2 Generating moc_imageDisplayQt.cpp
2 Generating moc_multiWindow.cpp
2 Generating moc_videoGeneric.cpp
...
with the moc_*.cpp files being regenerated. If I don't manually delete
the yuv_player_automoc.cpp file then the moc_*.cpp files are never
regenerated even if they are out of date compared to the header files they
are generated from.
--
Glenn
On 29 April 2013 17:15, Alexander Neundorf a.neundorf-w...@gmx.netwrote:
On Monday 29 April 2013, Glenn Coombs wrote:
I added these lines:
set_directory_properties(
PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES
${CMAKE_CURRENT_BINARY_DIR}/abc.txt
)
# check the location where abc.txt is supposed to be deleted from
message(CURRENT_BINARY_DIR: ${CMAKE_CURRENT_BINARY_DIR})
to the end of my CMakeLists.txt and then created abc.txt in the cmake
build
directory. I can confirm that the abc.txt file was not deleted by a
clean
solution. I tried this with Visual Studio 2012 and Visual Studio 2008
(both installs are the Express editions) and the results were identical.
I don't have Windows here so this is kind of hard for me...
Did you do a complete clean or just a clean of some part of the whole
project ?
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned
I select Clean Solution from the Build menu which is a complete clean.
The output looks like this:
1-- Skipped Clean: Project: INSTALL, Configuration: Debug Win32 --
1Project not selected to build for this solution configuration
2-- Clean started: Project: ALL_BUILD, Configuration: Debug Win32
--
3-- Clean started: Project: yuv_player, Configuration: Debug Win32
--
4-- Clean started: Project: yuv_player_automoc, Configuration: Debug
Win32 --
5-- Clean started: Project: ZERO_CHECK, Configuration: Debug Win32
--
== Clean: 4 succeeded, 0 failed, 1 skipped ==
The yuv_player_automoc project looks like it is being cleaned but the
associated moc_*.cpp and yuv_player_automoc.cpp files are never deleted.
After doing a Clean Solution and manually deleting the
yuv_player_automoc.cpp file a build works as expected:
1-- Build started: Project: ZERO_CHECK, Configuration: Debug Win32
--
2-- Build started: Project: yuv_player_automoc, Configuration: Debug
Win32 --
1 Checking Build System
2 Automoc for target yuv_player
1 CMake does not need to re-run because
C:/data/perforceCheckouts/sim/tools/yuvplayer/DEV/glenn.coombs/cmake/CMakeFiles/generate.stamp
is up-to-date.
2 Generating moc_ctrlBasic.cpp
2 Generating moc_ctrlmenu.cpp
2 Generating moc_infoWin.cpp
2 Generating moc_imageDisplay.cpp
2 Generating moc_imageDisplayGL.cpp
2 Generating moc_imageDisplayQt.cpp
2 Generating moc_multiWindow.cpp
2 Generating moc_videoGeneric.cpp
...
with the moc_*.cpp files being regenerated. If I don't manually delete the
yuv_player_automoc.cpp file then the moc_*.cpp files are never regenerated
even if they are out of date compared to the header files they are
generated from.
--
Glenn
On 29 April 2013 17:15, Alexander Neundorf a.neundorf-w...@gmx.net wrote:
On Monday 29 April 2013, Glenn Coombs wrote:
I added these lines:
set_directory_properties(
PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES
${CMAKE_CURRENT_BINARY_DIR}/abc.txt
)
# check the location where abc.txt is supposed to be deleted from
message(CURRENT_BINARY_DIR: ${CMAKE_CURRENT_BINARY_DIR})
to the end of my CMakeLists.txt and then created abc.txt in the cmake
build
directory. I can confirm that the abc.txt file was not deleted by a
clean
solution. I tried this with Visual Studio 2012 and Visual Studio 2008
(both installs are the Express editions) and the results were identical.
I don't have Windows here so this is kind of hard for me...
Did you do a complete clean or just a clean of some part of the whole
project ?
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned
I added these lines:
set_directory_properties(
PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES
${CMAKE_CURRENT_BINARY_DIR}/abc.txt
)
# check the location where abc.txt is supposed to be deleted from
message(CURRENT_BINARY_DIR: ${CMAKE_CURRENT_BINARY_DIR})
to the end of my CMakeLists.txt and then created abc.txt in the cmake build
directory. I can confirm that the abc.txt file was not deleted by a clean
solution. I tried this with Visual Studio 2012 and Visual Studio 2008
(both installs are the Express editions) and the results were identical.
--
Glenn
On 28 April 2013 11:53, Alexander Neundorf a.neundorf-w...@gmx.net wrote:
On Sunday 28 April 2013, Glenn Coombs wrote:
No, cleaning the project didn't remove that file.
Can you manually set the ADDITIONAL_MAKE_CLEAN_FILES directory property to
some file and check whether this file is deleted when you clean ?
Something like
set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES
${CMAKE_CURRENT_BINARY_DIR}/abc.txt )
then just create such a file in the build dir, and clean.
It should be removed then.
If it is not, then this is the reason why clean doesn't clean automoc
properly.
Alex
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned
No, cleaning the project didn't remove that file. -- Glenn On 26 April 2013 17:28, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Friday 26 April 2013, Glenn Coombs wrote: No, the yuv_player_automoc.cpp file is not removed on a clean (nor are the other moc_*.cpp files). Having just modified ctrlBasic.cpp and ctrlBasic.h: $ ls -ltr moc* ../ctrlMenu/ctrlBasic.* -rwxr-xr-x+ 1 glenn.coombs Domain Users 4366 Apr 25 15:04 moc_ctrlBasic.cpp* -rwxr-xr-x+ 1 glenn.coombs Domain Users 11912 Apr 25 15:04 moc_ctrlmenu.cpp* -rwxr-xr-x+ 1 glenn.coombs Domain Users 8203 Apr 25 15:04 moc_infoWin.cpp* -rwxr-xr-x+ 1 glenn.coombs Domain Users 3508 Apr 25 15:04 moc_qglDisplay.cpp* -rwxr-xr-x+ 1 glenn.coombs Domain Users 6493 Apr 25 15:04 moc_qglMultiWindow.cpp* -rwxr-xr-x+ 1 glenn.coombs Domain Users 2529 Apr 25 15:04 moc_qglWindow.cpp* -rwxr-xr-x+ 1 glenn.coombs Domain Users 4242 Apr 25 15:04 moc_videoGeneric.cpp* -rwxr-xr-x+ 1 glenn.coombs Domain Users 8513 Apr 26 08:27 ../ctrlMenu/ctrlBasic.cpp* -rwxr-xr-x+ 1 glenn.coombs Domain Users 1237 Apr 26 08:28 ../ctrlMenu/ctrlBasic.h* I would expect the moc_ctrlBasic.cpp file to be regenerated but it isn't. In fact, if I manually delete moc_ctrlBasic.cpp then the build fails: 1-- Build started: Project: yuv_player, Configuration: Debug Win32 -- 1 yuv_player_automoc.cpp 1yuv_player_automoc.cpp(2): fatal error C1083: Cannot open include file: 'moc_ctrlBasic.cpp': No such file or directory The only way to get moc_ctrlBasic.cpp regenerated that I have found so far is to manually delete both it and yuv_player_automoc.cpp. yuv_player_automoc.cpp is the key file. If you remove it, everything should be regenerated. So cleaning the project did not remove that file ? I'll have a look. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned
No, the yuv_player_automoc.cpp file is not removed on a clean (nor are the other moc_*.cpp files). Having just modified ctrlBasic.cpp and ctrlBasic.h: $ ls -ltr moc* ../ctrlMenu/ctrlBasic.* -rwxr-xr-x+ 1 glenn.coombs Domain Users 4366 Apr 25 15:04 moc_ctrlBasic.cpp* -rwxr-xr-x+ 1 glenn.coombs Domain Users 11912 Apr 25 15:04 moc_ctrlmenu.cpp* -rwxr-xr-x+ 1 glenn.coombs Domain Users 8203 Apr 25 15:04 moc_infoWin.cpp* -rwxr-xr-x+ 1 glenn.coombs Domain Users 3508 Apr 25 15:04 moc_qglDisplay.cpp* -rwxr-xr-x+ 1 glenn.coombs Domain Users 6493 Apr 25 15:04 moc_qglMultiWindow.cpp* -rwxr-xr-x+ 1 glenn.coombs Domain Users 2529 Apr 25 15:04 moc_qglWindow.cpp* -rwxr-xr-x+ 1 glenn.coombs Domain Users 4242 Apr 25 15:04 moc_videoGeneric.cpp* -rwxr-xr-x+ 1 glenn.coombs Domain Users 8513 Apr 26 08:27 ../ctrlMenu/ctrlBasic.cpp* -rwxr-xr-x+ 1 glenn.coombs Domain Users 1237 Apr 26 08:28 ../ctrlMenu/ctrlBasic.h* I would expect the moc_ctrlBasic.cpp file to be regenerated but it isn't. In fact, if I manually delete moc_ctrlBasic.cpp then the build fails: 1-- Build started: Project: yuv_player, Configuration: Debug Win32 -- 1 yuv_player_automoc.cpp 1yuv_player_automoc.cpp(2): fatal error C1083: Cannot open include file: 'moc_ctrlBasic.cpp': No such file or directory The only way to get moc_ctrlBasic.cpp regenerated that I have found so far is to manually delete both it and yuv_player_automoc.cpp. -- Glenn On 25 April 2013 21:23, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Thursday 25 April 2013, Glenn Coombs wrote: Hi, I have a Qt4 program that I'm working on and ran into an issue yesterday with the automoc cpp files. I had added a new slot and connected a comboxbox currentIndexChanged signal to it but when I ran the program I could see messages on stdout complaining that my slot didn't exist. I tracked the problem down to the fact that the moc_ctrlBasic.cpp file was not being regenerated. If I look in my cmake build directory I currently have 8 moc cpp files: ./moc_ctrlBasic.cpp ./moc_ctrlmenu.cpp ./moc_infoWin.cpp ./moc_qglDisplay.cpp ./moc_qglMultiWindow.cpp ./moc_qglWindow.cpp ./moc_videoGeneric.cpp ./yuv_player_automoc.cpp I am using CMake 2.8.10.1 with Visual Studio 11 and when I do a clean solution these 8 moc cpp files are not deleted. That's ok so far. automoc should create a file yuv_player_automoc.cpp, and this file should be removed when you clean. Is that the case ? This missing file should then trigger a rerun of automoc. Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned
Hi,
I have a Qt4 program that I'm working on and ran into an issue yesterday
with the automoc cpp files. I had added a new slot and connected a
comboxbox currentIndexChanged signal to it but when I ran the program I
could see messages on stdout complaining that my slot didn't exist. I
tracked the problem down to the fact that the moc_ctrlBasic.cpp file was
not being regenerated. If I look in my cmake build directory I currently
have 8 moc cpp files:
./moc_ctrlBasic.cpp
./moc_ctrlmenu.cpp
./moc_infoWin.cpp
./moc_qglDisplay.cpp
./moc_qglMultiWindow.cpp
./moc_qglWindow.cpp
./moc_videoGeneric.cpp
./yuv_player_automoc.cpp
I am using CMake 2.8.10.1 with Visual Studio 11 and when I do a clean
solution these 8 moc cpp files are not deleted. In order to get my new
slot recognised I had to manually delete these moc files and then after a
rebuild everything worked as expected. None of my cpp files #include
moc_xxx.cpp but that isn't necessary from my reading of the AUTOMOC
property (i.e. ctrlBasic.cpp only does a #include ctrlBasic.h). What am
I doing wrong in my CMakeLists.txt file which looks like this:
cmake_minimum_required(VERSION 2.8.9 FATAL_ERROR)
project(yuv_player)
find_package(OpenGL REQUIRED)
find_package(Qt4 REQUIRED)
set(QT_USE_QTMAIN true)
set(QT_USE_QTOPENGL true)
include(${QT_USE_FILE})
set(CMAKE_AUTOMOC true)
if (MSVC)
add_definitions(/MP)# build in parallel
# disable the security warnings for fopen, scanf etc.
add_definitions(/D_CRT_SECURE_NO_WARNINGS /D_SCL_SECURE_NO_WARNINGS)
endif()
set(sources
main.cpp
yuv_tools.cpp
ctrlMenu/ctrlBasic.cpp
ctrlMenu/ctrlmenu.cpp
multiWindow/qglMultiWindow.cpp
multiWindow/qglDisplay.cpp
multiWindow/qglWindow.cpp
utils/readYuv.cpp
utils/readOut2.cpp
video_tools.cpp
ctrlMenu/infoWin.cpp
videoGeneric.cpp
)
set(headers
yuv_tools.h
ctrlMenu/ctrlBasic.h
ctrlMenu/ctrlmenu.h
ctrlMenu/infoWin.h
multiWindow/qglDisplay.h
multiWindow/qglMultiWindow.h
multiWindow/qglWindow.h
utils/readYuv.h
utils/readOut2.h
video_tools.h
ctrlMenu/infoWin.h
videoGeneric.h
defs.h
)
include_directories(
.
multiWindow
ctrlMenu
)
add_executable(yuv_player WIN32 ${sources} ${headers})
target_link_libraries(yuv_player ${QT_LIBRARIES} ${OPENGL_LIBRARIES})
--
Glenn
--
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] Bug fix requests for the *next* release of CMake...
http://www.cmake.org/Bug/view.php?id=12437 (do not set default stacksize of 10MB for Visual Studio) -- Glenn -- 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] Bug in find_file() command ?
I've just checked my C:/Windows/SysWOW64 directory and it does not contain
a driver_root directory. It would have been a good catch if that was the
cause.
On 27 September 2012 19:20, Andreas Schenk
andreas_sch...@hms.harvard.eduwrote:
I had the same problem recently. Do you have a *driver_root* directory in*
**C:/Windows/SysWOW64*?
On 64-bit Windows systems the System32 directory contains the 64bit DLLs.
For 32-bit executables (like cmake for example), the WOW64 subsystem
automatically redirects
System32 directory access to SysWOW64, where the 32-bit DLLs are stored.
This has the side effect, that the path reported by find_file() doesn't
correspond to
the actual filesystem path for a file located in SysWOW64.
Cheers,
Andreas
Once the driver project has converted to using cmake that is what I plan to
do - use find_path() to look for driver_root/CMakeLists.txt. But in the
meantime I'm stuck using find_file() instead which works but it looks like
a bug that I need to specify the NO_DEFAULT_PATH option to avoid getting an
incorrect match.
--
Glenn
On 3 September 2012 09:58, Adolfo Rodríguez Tsouroukdissian
adolfo.rodriguez at pal-robotics.com
http://www.cmake.org/mailman/listinfo/cmake wrote:
* On Tue, Aug 28, 2012 at 6:59 PM, Glenn Coombs glenn.coombs at
gmail.com http://www.cmake.org/mailman/listinfo/cmakewrote: I
need to test for the presence of a directory called driver_root. I**
couldn't see a find_directory() command in the help** I cannot
comment about your issues concerning find_file, but if you know** the
name of a file contained in the directory you can use find_path:
http://cmake.org/cmake/help/v2.8.8/cmake.html#command:find_path
Cheers, Adolfo.** so I am using the following lines in
my CMakeLists.txt: message(1 DRV_ROOT_CHECK:
${DRV_ROOT_CHECK})** if (DEFINED ENV{DRV_ROOT})**
find_file(DRV_ROOT_CHECK driver_root $ENV{DRV_ROOT}/..)** message(2
DRV_ROOT_CHECK: ${DRV_ROOT_CHECK})** endif()
message(3 DRV_ROOT_CHECK: ${DRV_ROOT_CHECK})**
find_file(DRV_ROOT_CHECK driver_root** ../CVSFILES**
../..** ../../CVSFILES** ../../..**
../../../CVSFILES** ../../../..** )** message(4
DRV_ROOT_CHECK: ${DRV_ROOT_CHECK}) set(DRV_ROOT
${DRV_ROOT_CHECK} CACHE PATH Location of** driver tree)**
set(DRV_ROOT_CHECK ${DRV_ROOT_CHECK} CACHE INTERNAL Location of**
driver tree) message(5 DRV_ROOT_CHECK:
${DRV_ROOT_CHECK}) if (DRV_ROOT_CHECK)**
message( DRV_ROOT: ${DRV_ROOT})** else()**
message(FATAL_ERROR Unable to locate driver_root directory.** Please
set DRV_ROOT variable.)** endif() It works fine on my
machine but fails on one of our build machines. Both** machines are
Windows 7 (64-bit) and are using CMake 2.8.9. On my machine** it
produces this output: 1 DRV_ROOT_CHECK:** 3
DRV_ROOT_CHECK:** 4 DRV_ROOT_CHECK:
C:/data/perforceCheckouts/sim/vxe/CVSFILES/driver_root** 5
DRV_ROOT_CHECK: C:/data/perforceCheckouts/sim/vxe/CVSFILES/driver_root**
DRV_ROOT:
C:/data/perforceCheckouts/sim/vxe/CVSFILES/driver_root but on the
build machine it produces this output: 1 DRV_ROOT_CHECK:** 3
DRV_ROOT_CHECK:** 4 DRV_ROOT_CHECK: C:/Windows/System32/driver_root**
5 DRV_ROOT_CHECK: C:/Windows/System32/driver_root There is no
file or directory called driver_root in the windows/systsem32** folder.
If I change the find_file() command to this:
find_file(DRV_ROOT_CHECK driver_root PATHS** ../CVSFILES**
../..** ../../CVSFILES** ../../..**
../../../CVSFILES** ../../../..**
NO_DEFAULT_PATH** ) then it works producing this
output: 1 DRV_ROOT_CHECK:** 3 DRV_ROOT_CHECK:** 4
DRV_ROOT_CHECK: C:/glenn/CVSFILES/driver_root** 5 DRV_ROOT_CHECK:
C:/glenn/CVSFILES/driver_root Is this a bug in cmake or can
somebody explain how it found a** non-existant file/folder in the
windows/system32 folder ? --** Glenn**
-- 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** --**
Adolfo Rodríguez Tsouroukdissian** Robotics engineer** adolfo.rodriguez
at pal-robotics.com http://www.cmake.org/mailman/listinfo/cmake**
http://www.pal-robotics.com PAL ROBOTICS S.L** c/ Pujades 77-79,
4º4ª** 08005 Barcelona, Spain.** Tel. +34.93.414.53.47 **
Fax.+34.93.209.11.09 AVISO DE CONFIDENCIALIDAD: Este mensaje y sus
documentos adjuntos, pueden** contener información privilegiada y/o
confidencial que está dirigida** exclusivamente a su
[CMake] How to get cmake --build . to build in parallel ?
I am invoking cmake as part of a jenkins script and am using cmake --build . to kick off the build. This works but does not do the equivalent of make -j4 to take advantage of all 4 cores when run on a linux machine. When run on a windows machine the building in parallel is already taken care of by an add_definitions(/MP$(NUMBER_OF_PROCESSORS)) command in the CMakeLists.txt. Is there a command line option to get cmake --build to invoke make with the appropriate -j option for linux builds ? Or something I can add to my CMakeLists.txt similar to the /MP option for Visual Studio builds ? Or will I have to invoke make -j4 on linux and cmake --build . on windows instead of being able to keep the same build command irrespective of OS ? -- Glenn -- 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] Visual Studio 2012 Express for WD and cmake 2.8.9
Thanks for that - I will try it again with the 2.8.10 release candidate.
--
Glenn
On 18 September 2012 22:17, David Cole david.c...@kitware.com wrote:
On Mon, Sep 17, 2012 at 1:02 PM, Glenn Coombs glenn.coo...@gmail.comwrote:
Hi,
I just installed the Visual Studio 2012 Express edition for Windows
Desktop and cmake 2.8.9 is having some issues with it. Initially when I
ran the cmake configure step it failed to find the devenv or msbuild
program:
CMake was unable to find a build program corresponding to Visual Studio
11. CMAKE_MAKE_PROGRAM is not set. You probably need to select a different
build tool.
I then edited the CMakeVS11FindMake.cmake file to tell it to use the same
MSBuild that the VS2012 command prompt uses
(C:/Windows/Microsoft.NET/Framework/v4.0.30319):
IF(NOT CMAKE_CROSSCOMPILING)
FIND_PROGRAM(CMAKE_MAKE_PROGRAM
NAMES MSBuild
HINTS
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\11.0\\Setup\\VS;ProductDir]
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\WDExpress\\11.0\\Setup\\VS;ProductDir]
$ENV{SYSTEMROOT}/Microsoft.NET/Framework/[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\11.0;CLR
Version]/
c:/WINDOWS/Microsoft.NET/Framework/[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\11.0;CLR
Version]/
$ENV{SYSTEMROOT}/Microsoft.NET/Framework/[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VCExpress\\11.0;CLR
Version]/
C:/Windows/Microsoft.NET/Framework/v4.0.30319
)
ENDIF()
and that gets me a bit further. The error message is now:
Check for working C compiler using: Visual Studio 11
Check for working C compiler using: Visual Studio 11 -- works
Detecting C compiler ABI info
CMake Error at C:/Program Files (x86)/CMake
2.8.9/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:31
(TRY_COMPILE):
Cannot copy output executable
''
to destination specified by COPY_FILE:
'C:/data/perforceCheckouts/sim/vxe/diamond/DEV/glenn.coombs/cmake/CMakeFiles/CMakeDetermineCompilerABI_C.bin'
Unable to find the executable at any of:
C:/data/perforceCheckouts/sim/vxe/diamond/DEV/glenn.coombs/cmake/CMakeFiles/CMakeTmp/cmTryCompileExec66551527.exe
C:/data/perforceCheckouts/sim/vxe/diamond/DEV/glenn.coombs/cmake/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec66551527.exe
C:/data/perforceCheckouts/sim/vxe/diamond/DEV/glenn.coombs/cmake/CMakeFiles/CMakeTmp/Development/cmTryCompileExec66551527.exe
Call Stack (most recent call first):
C:/Program Files (x86)/CMake
2.8.9/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:71
(CMAKE_DETERMINE_COMPILER_ABI)
CMakeLists.txt:3 (project)
Is it possible to hack an existing cmake 2.8.9 install to work with
VS2012 Express or am I going to have to wait for cmake 2.8.10 ?
--
Glenn
--
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
You will need a new build of CMake to fix this problem.
Brad just merged some changes to our 'next' branch today to address this
issue.
If you can build CMake from source, you can try it out right now if you
checkout the 'next' branch and build it.
If not, you could wait till tomorrow morning, and there will hopefully be
a nightly build available that you can download and try.
Or, if it's not urgent, and you can wait till next week: we have
tentatively scheduled our first release candidate for CMake 2.8.10 for next
Wednesday, 9/26/2012.
HTH,
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
[CMake] Visual Studio 2012 Express for WD and cmake 2.8.9
Hi,
I just installed the Visual Studio 2012 Express edition for Windows Desktop
and cmake 2.8.9 is having some issues with it. Initially when I ran the
cmake configure step it failed to find the devenv or msbuild program:
CMake was unable to find a build program corresponding to Visual Studio
11. CMAKE_MAKE_PROGRAM is not set. You probably need to select a different
build tool.
I then edited the CMakeVS11FindMake.cmake file to tell it to use the same
MSBuild that the VS2012 command prompt uses
(C:/Windows/Microsoft.NET/Framework/v4.0.30319):
IF(NOT CMAKE_CROSSCOMPILING)
FIND_PROGRAM(CMAKE_MAKE_PROGRAM
NAMES MSBuild
HINTS
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\11.0\\Setup\\VS;ProductDir]
[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\WDExpress\\11.0\\Setup\\VS;ProductDir]
$ENV{SYSTEMROOT}/Microsoft.NET/Framework/[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\11.0;CLR
Version]/
c:/WINDOWS/Microsoft.NET/Framework/[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\11.0;CLR
Version]/
$ENV{SYSTEMROOT}/Microsoft.NET/Framework/[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VCExpress\\11.0;CLR
Version]/
C:/Windows/Microsoft.NET/Framework/v4.0.30319
)
ENDIF()
and that gets me a bit further. The error message is now:
Check for working C compiler using: Visual Studio 11
Check for working C compiler using: Visual Studio 11 -- works
Detecting C compiler ABI info
CMake Error at C:/Program Files (x86)/CMake
2.8.9/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:31
(TRY_COMPILE):
Cannot copy output executable
''
to destination specified by COPY_FILE:
'C:/data/perforceCheckouts/sim/vxe/diamond/DEV/glenn.coombs/cmake/CMakeFiles/CMakeDetermineCompilerABI_C.bin'
Unable to find the executable at any of:
C:/data/perforceCheckouts/sim/vxe/diamond/DEV/glenn.coombs/cmake/CMakeFiles/CMakeTmp/cmTryCompileExec66551527.exe
C:/data/perforceCheckouts/sim/vxe/diamond/DEV/glenn.coombs/cmake/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec66551527.exe
C:/data/perforceCheckouts/sim/vxe/diamond/DEV/glenn.coombs/cmake/CMakeFiles/CMakeTmp/Development/cmTryCompileExec66551527.exe
Call Stack (most recent call first):
C:/Program Files (x86)/CMake
2.8.9/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:71
(CMAKE_DETERMINE_COMPILER_ABI)
CMakeLists.txt:3 (project)
Is it possible to hack an existing cmake 2.8.9 install to work with VS2012
Express or am I going to have to wait for cmake 2.8.10 ?
--
Glenn
--
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] Bug in find_file() command ?
Once the driver project has converted to using cmake that is what I plan to
do - use find_path() to look for driver_root/CMakeLists.txt. But in the
meantime I'm stuck using find_file() instead which works but it looks like
a bug that I need to specify the NO_DEFAULT_PATH option to avoid getting an
incorrect match.
--
Glenn
On 3 September 2012 09:58, Adolfo Rodríguez Tsouroukdissian
adolfo.rodrig...@pal-robotics.com wrote:
On Tue, Aug 28, 2012 at 6:59 PM, Glenn Coombs glenn.coo...@gmail.comwrote:
I need to test for the presence of a directory called driver_root. I
couldn't see a find_directory() command in the help
I cannot comment about your issues concerning find_file, but if you know
the name of a file contained in the directory you can use find_path:
http://cmake.org/cmake/help/v2.8.8/cmake.html#command:find_path
Cheers,
Adolfo.
so I am using the following lines in my CMakeLists.txt:
message(1 DRV_ROOT_CHECK: ${DRV_ROOT_CHECK})
if (DEFINED ENV{DRV_ROOT})
find_file(DRV_ROOT_CHECK driver_root $ENV{DRV_ROOT}/..)
message(2 DRV_ROOT_CHECK: ${DRV_ROOT_CHECK})
endif()
message(3 DRV_ROOT_CHECK: ${DRV_ROOT_CHECK})
find_file(DRV_ROOT_CHECK driver_root
../CVSFILES
../..
../../CVSFILES
../../..
../../../CVSFILES
../../../..
)
message(4 DRV_ROOT_CHECK: ${DRV_ROOT_CHECK})
set(DRV_ROOT ${DRV_ROOT_CHECK} CACHE PATH Location of
driver tree)
set(DRV_ROOT_CHECK ${DRV_ROOT_CHECK} CACHE INTERNAL Location of
driver tree)
message(5 DRV_ROOT_CHECK: ${DRV_ROOT_CHECK})
if (DRV_ROOT_CHECK)
message( DRV_ROOT: ${DRV_ROOT})
else()
message(FATAL_ERROR Unable to locate driver_root directory.
Please set DRV_ROOT variable.)
endif()
It works fine on my machine but fails on one of our build machines. Both
machines are Windows 7 (64-bit) and are using CMake 2.8.9. On my machine
it produces this output:
1 DRV_ROOT_CHECK:
3 DRV_ROOT_CHECK:
4 DRV_ROOT_CHECK: C:/data/perforceCheckouts/sim/vxe/CVSFILES/driver_root
5 DRV_ROOT_CHECK: C:/data/perforceCheckouts/sim/vxe/CVSFILES/driver_root
DRV_ROOT: C:/data/perforceCheckouts/sim/vxe/CVSFILES/driver_root
but on the build machine it produces this output:
1 DRV_ROOT_CHECK:
3 DRV_ROOT_CHECK:
4 DRV_ROOT_CHECK: C:/Windows/System32/driver_root
5 DRV_ROOT_CHECK: C:/Windows/System32/driver_root
There is no file or directory called driver_root in the windows/systsem32
folder. If I change the find_file() command to this:
find_file(DRV_ROOT_CHECK driver_root PATHS
../CVSFILES
../..
../../CVSFILES
../../..
../../../CVSFILES
../../../..
NO_DEFAULT_PATH
)
then it works producing this output:
1 DRV_ROOT_CHECK:
3 DRV_ROOT_CHECK:
4 DRV_ROOT_CHECK: C:/glenn/CVSFILES/driver_root
5 DRV_ROOT_CHECK: C:/glenn/CVSFILES/driver_root
Is this a bug in cmake or can somebody explain how it found a
non-existant file/folder in the windows/system32 folder ?
--
Glenn
--
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
--
Adolfo Rodríguez Tsouroukdissian
Robotics engineer
adolfo.rodrig...@pal-robotics.com
http://www.pal-robotics.com
PAL ROBOTICS S.L
c/ Pujades 77-79, 4º4ª
08005 Barcelona, Spain.
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden
contener información privilegiada y/o confidencial que está dirigida
exclusivamente a su destinatario. Si usted recibe este mensaje y no es el
destinatario indicado, o el empleado encargado de su entrega a dicha
persona, por favor, notifíquelo inmediatamente y remita el mensaje original
a la dirección de correo electrónico indicada. Cualquier copia, uso o
distribución no autorizados de esta comunicación queda estrictamente
prohibida.
CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
contain confidential information which is privileged and intended only for
the individual or entity to whom they are addressed. If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution or use of this e-mail and/or accompanying document(s) is
strictly prohibited. If you have received this e-mail in error, please
immediately notify the sender at the above e-mail address.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Bug in find_file() command ?
I need to test for the presence of a directory called driver_root. I
couldn't see a find_directory() command in the help so I am using the
following lines in my CMakeLists.txt:
message(1 DRV_ROOT_CHECK: ${DRV_ROOT_CHECK})
if (DEFINED ENV{DRV_ROOT})
find_file(DRV_ROOT_CHECK driver_root $ENV{DRV_ROOT}/..)
message(2 DRV_ROOT_CHECK: ${DRV_ROOT_CHECK})
endif()
message(3 DRV_ROOT_CHECK: ${DRV_ROOT_CHECK})
find_file(DRV_ROOT_CHECK driver_root
../CVSFILES
../..
../../CVSFILES
../../..
../../../CVSFILES
../../../..
)
message(4 DRV_ROOT_CHECK: ${DRV_ROOT_CHECK})
set(DRV_ROOT ${DRV_ROOT_CHECK} CACHE PATH Location of
driver tree)
set(DRV_ROOT_CHECK ${DRV_ROOT_CHECK} CACHE INTERNAL Location of
driver tree)
message(5 DRV_ROOT_CHECK: ${DRV_ROOT_CHECK})
if (DRV_ROOT_CHECK)
message( DRV_ROOT: ${DRV_ROOT})
else()
message(FATAL_ERROR Unable to locate driver_root directory.
Please set DRV_ROOT variable.)
endif()
It works fine on my machine but fails on one of our build machines. Both
machines are Windows 7 (64-bit) and are using CMake 2.8.9. On my machine
it produces this output:
1 DRV_ROOT_CHECK:
3 DRV_ROOT_CHECK:
4 DRV_ROOT_CHECK: C:/data/perforceCheckouts/sim/vxe/CVSFILES/driver_root
5 DRV_ROOT_CHECK: C:/data/perforceCheckouts/sim/vxe/CVSFILES/driver_root
DRV_ROOT: C:/data/perforceCheckouts/sim/vxe/CVSFILES/driver_root
but on the build machine it produces this output:
1 DRV_ROOT_CHECK:
3 DRV_ROOT_CHECK:
4 DRV_ROOT_CHECK: C:/Windows/System32/driver_root
5 DRV_ROOT_CHECK: C:/Windows/System32/driver_root
There is no file or directory called driver_root in the windows/systsem32
folder. If I change the find_file() command to this:
find_file(DRV_ROOT_CHECK driver_root PATHS
../CVSFILES
../..
../../CVSFILES
../../..
../../../CVSFILES
../../../..
NO_DEFAULT_PATH
)
then it works producing this output:
1 DRV_ROOT_CHECK:
3 DRV_ROOT_CHECK:
4 DRV_ROOT_CHECK: C:/glenn/CVSFILES/driver_root
5 DRV_ROOT_CHECK: C:/glenn/CVSFILES/driver_root
Is this a bug in cmake or can somebody explain how it found a non-existant
file/folder in the windows/system32 folder ?
--
Glenn
--
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] Compile flag issues and VS Express
I think 10M is an insanely large default stack size. It just encourages people to create int foo[100][100][100] on the stack instead of learning how to use malloc or new. When creating non-cmake Visual Studio projects the default stack size is way more sensible. I can't see any reason to default to 10M for cmake generated projects and would love to see this default removed. As it is I have to override it for all my projects. -- Glenn On 1 February 2012 10:14, Yuri Timenkov y...@timenkov.ru wrote: I can assume that 10M stack is reasonable for C code, where it's usual to allocate temporary buffers on stack (in C++ it's easier to use heap, e.g. using std::vector). Bad thing is - impact of this flag is detected only at run time. If with /Zm your code just won't compile, with /STACK everything compiles and links perfectly, works fine in simple cases, but you'll receive OOM under load (in C, when stack will be over). That's why I didn't insist on changing behavior when found this bug 3 years ago. On Tue, Jan 31, 2012 at 8:02 PM, Glenn Coombs glenn.coo...@gmail.comwrote: On a related note: http://www.gccxml.org/Bug/view.php?id=12437 can you check if ITK and VTK build fine without the large stack size argument (/STACK:1000) as well ? -- Glenn On 30 January 2012 15:58, Bill Lorensen bill.loren...@gmail.com wrote: ITK and VTK both build fine if I remove the /Zm1000 flag. On Mon, Jan 30, 2012 at 10:44 AM, Bill Hoffman bill.hoff...@kitware.com wrote: On 1/28/2012 10:51 AM, David Cole wrote: Seems reasonable. Is anybody worried that changing the default values of these flags would have a negative impact on any projects out there? (i.e. is it likely that anybody relies on these flags being present and that would somehow break their build without them...? I don't think it's likely, but I'm willing to discuss before making a change in CMake) They were originally put in for VTK/ITK. They would be the projects to try. -Bill -- 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 -- Unpaid intern in BillsBasement at noware dot com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- 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 -E copy with file permission changes
We have recently switched from cvs to perforce and encountered the same problem. In our case the fix was to change the CMakeList.txt file to refer directly to the file in the source tree rather than first copying it to the build tree and then referring to it there. As the clean command only affects the build tree the problem goes away - the read only file remains in the source tree and is not required to be cleaned anymore. -- Glenn On 31 January 2012 17:32, James Bigler jamesbig...@gmail.com wrote: We use perforce for our source control, and perforce typically syncs files as read only until you check them out for editing. During our build process we copy a few scripts from the source tree to the build tree using 'cmake -E copy' in an 'add_custom_command'. This works famously until we try to run a clean command from within Visual Studio. At this point VS complains that it can't remove a read only file. Has anyone else run into this problem? There doesn't seem to be a way to use 'cmake -E' to change permissions. Would I have to create my own cmake script to run 'configure_file COPYONLY'? Thanks, James -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] if (DEFINED $ENV{VAR}) doesn't work as expected
Hi,
I've just had a CMakeLists.txt fail to work as expected because somebody was
testing to see whether an environment variable was set with the syntax: if
(DEFINED $ENV{VAR}). This short example shows the problem:
cmake_minimum_required(VERSION 2.8)
project(foo)
message(HOME: $ENV{HOME})
if (DEFINED $ENV{HOME})
message(HOME is defined)
else()
message(HOME is NOT defined)
endif()
if (DEFINED FOO)
message(At 1: FOO is defined)
else()
message(At 1: FOO is NOT defined)
endif()
set(FOO foo)
if (DEFINED FOO)
message(At 2:FOO is defined)
else()
message(At 2:FOO is NOT defined)
endif()
When run it prints this:
HOME: /user/grc
HOME is NOT defined
At 1: FOO is NOT defined
At 2:FOO is defined
So the test for if a variable is defined works for cmake variables but not
for environment variables. I can work around this by testing if the
environment variable is the empty string I guess. Is the current behaviour
what is wanted, or is this a bug ?
--
Glenn
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about variables, cache, and scope
Doh :-) Thanks for pointing out what should perhaps have been obvious in
retrospect. Cache variables are one of the more confusing areas of cmake.
--
Glenn
On 10 October 2011 22:38, Bill Hoffman bill.hoff...@kitware.com wrote:
On 10/10/2011 3:52 PM, Robert Dailey wrote:
Yes, this works perfectly.
It's a bit disappointing that cache variables are, for all intents and
purposes, read-only in functions. The property approach is a bit more
verbose but it functions! I think 'set' needs a new override
specifically for cases like this. Something similar to PARENT_SCOPE,
but something like CACHE_SCOPE, that forces CMake to first check for
the existance of a cache variable with that name, and it would take
precedence over any identically named variable in function scope.
On another note, you'd think this would work too but it doesn't:
set( project_count ${new_count} CACHE INTERNAL FORCE )
This works:
set( project_count 0 CACHE INTERNAL )
function( define_project )
math( EXPR count ${project_count}+1 )
set( project_count ${count} CACHE INTERNAL )
endfunction()
define_project()
message(${project_count})
define_project()
message(${project_count})
define_project()
message(${project_count})
It prints out
1
2
3
-Bill
--
Powered by www.kitware.com
Visit other Kitware open-source projects at http://www.kitware.com/**
opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] if (DEFINED $ENV{VAR}) doesn't work as expected
Yes, that did help. Works perfectly without the $ character.
--
Glenn
On 11 October 2011 19:55, Michael Wild them...@gmail.com wrote:
On 10/11/2011 06:02 PM, Glenn Coombs wrote:
Hi,
I've just had a CMakeLists.txt fail to work as expected because somebody
was testing to see whether an environment variable was set with the
syntax: if (DEFINED $ENV{VAR}). This short example shows the problem:
cmake_minimum_required(VERSION 2.8)
project(foo)
message(HOME: $ENV{HOME})
if (DEFINED $ENV{HOME})
message(HOME is defined)
else()
message(HOME is NOT defined)
endif()
if (DEFINED FOO)
message(At 1: FOO is defined)
else()
message(At 1: FOO is NOT defined)
endif()
set(FOO foo)
if (DEFINED FOO)
message(At 2:FOO is defined)
else()
message(At 2:FOO is NOT defined)
endif()
When run it prints this:
HOME: /user/grc
HOME is NOT defined
At 1: FOO is NOT defined
At 2:FOO is defined
So the test for if a variable is defined works for cmake variables but
not for environment variables. I can work around this by testing if the
environment variable is the empty string I guess. Is the current
behaviour what is wanted, or is this a bug ?
--
Glenn
That's because it should read
if(DEFINED ENV{VAR})
notice the missing $. Otherwise you are testing whether a variable is
defined whose name is given by the content of the VAR environment variable.
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
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Question about variables, cache, and scope
Calling a function pushs a new variable scope. All variables visible in the
callers scope are copied into the new scope but changes by default only
affect the callee scope. You could try using the PARENT_SCOPE option to the
set command but I'm not sure that will achieve what you want as it only gets
you to the next scope whereas you really want a global variable.
You can use properties instead of variables as those are explicitly scoped.
So something like this:
set_property(GLOBAL PROPERTY project_count 0)
function( define_project ... )
get_property(old_count GLOBAL PROPERTY project_count)
math( EXPR new_count ${old_count}+1 )
set_property(GLOBAL PROPERTY project_count ${new_count}
endfunction()
will probably work.
--
Glenn
On 10 October 2011 17:11, Robert Dailey rcdai...@gmail.com wrote:
I have a function that I define in my top-most CMakeLists.txt file (on
Windows using CMake version 2.8.6) called define_project() that calls
add_executable, sets up compile defintions, etc etc.
For each time define_project() is called *anywhere* in the directory
hierarchy, I need to increment a global project_count variable to keep
track of how many projects were created and print that at the very end of
the root CMakeLists.txt file.
So far my attempts at this have been unsuccessful. I tried creating a cache
variable in the root script:
set( project_count 0 CACHE INTERNAL )
Then inside of my function, I do this:
function( define_project ... )
math( EXPR count ${project_count}+1 )
set( project_count ${count} )
endfunction()
However, 'project_count' is always 0 each time that the function is
executed.
How can I make this work?
-
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
--
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] novice question: modification of FLAGS rule variable?
The set_target_properties() of COMPILE_FLAGS allows you to add the -DDEBUG
just for the mylibd target (although you should really use the
COMPILE_DEFINITIONS property for preprocessor symbols). Why do you need to
mess with the FLAGS part of the compile command ? Can't you add extra
compiler command flags like this:
set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -myFlag)
or even replace the default flags entirely like this:
set(CMAKE_C_FLAGS -foo)
I'm not sure what you are trying to achieve. Can you explain in a bit more
detail ?
--
Glenn
On 8 September 2011 04:35, David Dunkle ddun...@arxan.com wrote:
Thanks, Glenn. That almost works. However, the values of FLAGS is hard to
construct in this case. It looks something like this:
** **
add_library(mylib, STATIC, ${files})
set_target_properties(mylib
PROPERTIES PREFIX “”
COMPILE_FLAGS
${target_compiler_flags})
add_library(mylibd, STATIC, ${files})
set_target_properties(mylibd,
PROPERTIES PREFIX “”
COMPILE_FLAGS “-DDEBUG
${target_compiler_flags}”)
…
set(CMAKE_C_COMPILE_OBJECT ${target_compiler} -c FLAGS -o OBJECT)***
*
** **
I can replace FLAGS with ${target_compiler_flags} yielding this:
** **
set(CMAKE_C_COMPILE_OBJECT “${target_compiler} –c ${target_compiler_flags}
–o OBJECT”)
** **
but then the –DDEBUG is missing for the build of mylibd. I guess both
mylibd and mylib use CMAKE_C_COMPILE_OBJECT and I need a way to pass the
–DDEBUG to the compile of one and not the other.
** **
-David
** **
*From:* Glenn Coombs [mailto:glenn.coo...@gmail.com]
*Sent:* Wednesday, September 07, 2011 4:19 AM
*To:* David Cole
*Cc:* David Dunkle; cmake@cmake.org
*Subject:* Re: [CMake] novice question: modification of FLAGS rule
variable?
** **
What you can do however is set the variable which uses the FLAGS
definition, i.e. CMAKE_C_COMPILE_OBJECT in your example. I have a
CMakeLists.txt file where I override the default assembler flags:
set(CMAKE_ASM-ATT_COMPILE_OBJECT CMAKE_ASM-ATT_COMPILER ${ASM_SYS_FLAGS}
-o OBJECT SOURCE)
to use what is set in my ASM_SYS_FLAGS variable instead of the default
FLAGS one. I'm not sure but I think you are supposed to set these sort of
variables early on in a CMakeList.txt before the project() or
enable_language() commands. Also, I think that later changes to the
ASM_SYS_FLAGS variable are ignored.
--
Glenn
On 5 September 2011 19:53, David Cole david.c...@kitware.com wrote:
On Mon, Sep 5, 2011 at 1:31 PM, David Dunkle ddun...@arxan.com wrote:
Is it possible to read and to set a property/rule variable like FLAGS?
What syntax would I use to do that? I mean FLAGS as it, for example,
appears here:
set(CMAKE_C_COMPILE_OBJECT ${target_compiler} -c FLAGS -o OBJECT)
For example can I do something like this (this is pseudo code)?
#read
set(MY_FLAGS, ${FLAGS} );
…
#set
set(FLAGS, ${MY_FLAGS});
In the documentation, here:
http://cmake.org/Wiki/CMake_Useful_Variables#Expansion_Rules
it hints at this being possible but doesn’t explain, at least not so that
I
understand.
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
The wiki page is simply misleading. You cannot set those from the
CMake language. CMake decides on their values in internal code, and
then substitutes appropriately when generating make files or
solution/project files for the build system.
You can set things the CMAKE_CXX_FLAGS which eventually get
translated into the substitution that CMake performs, but you cannot
alter FLAGS in the rules variables.
HTH,
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
** **
___
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] novice question: modification of FLAGS rule variable?
Is the -m32 flag being provided as a default by cmake, or are you specifying
it yourself ? If the latter, then maybe it has been added to the
COMPILE_DEFINITIONS property instead of the CMAKE_C_FLAGS variable. I have
seen CMakeList.txt files use add_definitions(-m32) rather than adding it to
the CMAKE_C_FLAGS variable. That would explain why explicitly setting
CMAKE_C_FLAGS wasn't removing it. Also, is it C files or C++ files that are
being compiled, because C++ files use CMAKE_CXX_FLAGS instead of
CMAKE_C_FLAGS.
On 8 September 2011 18:16, David Dunkle ddun...@arxan.com wrote:
I inherited this cmake build that builds a complex project with a fairly
large directory tree. Part way through it switches compilers, with code
similar to what is below, and builds a few subdirectories using the new
compilers. The compiler flags for the original compilers (compiler A) bleeds
through to the new compilers (compiler B), because of the FLAGS below. The
code below is in the CMakeLists.txt of the subdirectory that switches to the
new compiler.
** **
Now I need to build on a new platform, which involves adding only one new
compiler flag (-m32) to compiler A. Unfortunately, the –m32 is picked up by
the FLAGS below and passed to compiler B, which does not support this
flag, and gives an error.
** **
So, I am trying to figure out if I can modify the existing code to remove
the –m32 from FLAGS for compiler B, or if I need to basically rewrite the
compiler B part of the build so that the subdirectories using compiler B are
a separate cmake project. The rewrite idea is hard to justify in schedule
sense to remove one flag, and I have to be sure it’s necessary.
** **
While conceptually removing one –m32 flag seems simple, I am having a very
hard time figuring out how to do it in cmake. Removing the single flag from
compiler B can take two forms, as we have discussed. I can obtain the
existing flags and remove the –m32 or I can substitute the new flags
completely.
** **
The removal option has not worked so far, possibly because this removal is
occurring in a subdirectory of the original long after the project is
established, and possibly because I am not sure which variable to modify.
The CMAKE_C_FLAGS is already modified in this case, to no effect on FLAGS,
possibly because its occurring long after the project is established. Can I
get_target_property on COMPILER_FLAGS and modify that?
** **
The second option almost works, but I can’t figure out how to obtain the
–DDEBUG option that is currently established with set_target_properties, as
described below.
** **
-David
** **
*From:* Glenn Coombs [mailto:glenn.coo...@gmail.com]
*Sent:* Thursday, September 08, 2011 3:15 AM
*To:* David Dunkle
*Cc:* David Cole; cmake@cmake.org
*Subject:* Re: [CMake] novice question: modification of FLAGS rule
variable?
** **
The set_target_properties() of COMPILE_FLAGS allows you to add the -DDEBUG
just for the mylibd target (although you should really use the
COMPILE_DEFINITIONS property for preprocessor symbols). Why do you need to
mess with the FLAGS part of the compile command ? Can't you add extra
compiler command flags like this:
set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -myFlag)
or even replace the default flags entirely like this:
set(CMAKE_C_FLAGS -foo)
I'm not sure what you are trying to achieve. Can you explain in a bit more
detail ?
--
Glenn
On 8 September 2011 04:35, David Dunkle ddun...@arxan.com wrote:
Thanks, Glenn. That almost works. However, the values of FLAGS is hard to
construct in this case. It looks something like this:
add_library(mylib, STATIC, ${files})
set_target_properties(mylib
PROPERTIES PREFIX “”
COMPILE_FLAGS
${target_compiler_flags})
add_library(mylibd, STATIC, ${files})
set_target_properties(mylibd,
PROPERTIES PREFIX “”
COMPILE_FLAGS “-DDEBUG
${target_compiler_flags}”)
…
set(CMAKE_C_COMPILE_OBJECT ${target_compiler} -c FLAGS -o OBJECT)***
*
I can replace FLAGS with ${target_compiler_flags} yielding this:
set(CMAKE_C_COMPILE_OBJECT “${target_compiler} –c ${target_compiler_flags}
–o OBJECT”)
but then the –DDEBUG is missing for the build of mylibd. I guess both
mylibd and mylib use CMAKE_C_COMPILE_OBJECT and I need a way to pass the
–DDEBUG to the compile of one and not the other.
-David
*From:* Glenn Coombs [mailto:glenn.coo...@gmail.com]
*Sent:* Wednesday, September 07, 2011 4:19 AM
*To:* David Cole
*Cc:* David Dunkle; cmake@cmake.org
*Subject:* Re: [CMake] novice question: modification of FLAGS rule
variable?
What you can do however is set the variable which uses the FLAGS
Re: [CMake] novice question: modification of FLAGS rule variable?
What you can do however is set the variable which uses the FLAGS
definition, i.e. CMAKE_C_COMPILE_OBJECT in your example. I have a
CMakeLists.txt file where I override the default assembler flags:
set(CMAKE_ASM-ATT_COMPILE_OBJECT CMAKE_ASM-ATT_COMPILER ${ASM_SYS_FLAGS}
-o OBJECT SOURCE)
to use what is set in my ASM_SYS_FLAGS variable instead of the default
FLAGS one. I'm not sure but I think you are supposed to set these sort of
variables early on in a CMakeList.txt before the project() or
enable_language() commands. Also, I think that later changes to the
ASM_SYS_FLAGS variable are ignored.
--
Glenn
On 5 September 2011 19:53, David Cole david.c...@kitware.com wrote:
On Mon, Sep 5, 2011 at 1:31 PM, David Dunkle ddun...@arxan.com wrote:
Is it possible to read and to set a property/rule variable like FLAGS?
What syntax would I use to do that? I mean FLAGS as it, for example,
appears here:
set(CMAKE_C_COMPILE_OBJECT ${target_compiler} -c FLAGS -o OBJECT)
For example can I do something like this (this is pseudo code)?
#read
set(MY_FLAGS, ${FLAGS} );
…
#set
set(FLAGS, ${MY_FLAGS});
In the documentation, here:
http://cmake.org/Wiki/CMake_Useful_Variables#Expansion_Rules
it hints at this being possible but doesn’t explain, at least not so that
I
understand.
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
The wiki page is simply misleading. You cannot set those from the
CMake language. CMake decides on their values in internal code, and
then substitutes appropriately when generating make files or
solution/project files for the build system.
You can set things the CMAKE_CXX_FLAGS which eventually get
translated into the substitution that CMake performs, but you cannot
alter FLAGS in the rules variables.
HTH,
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
___
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 inherit includes from other directories
Could you not create a file in each subdirectory called something like
header-deps.cmake ? This file would contain the include_directory()
commands necessary for using this module, plus include() commands of other
modules that it depends on. So for your example:
# utils/b/header-deps.cmake
include_directories(...)
include(${CMAKE_SOURCE_DIR)/utils/a/header-deps.cmake)
# utils/a/header-deps.cmake
include_directories(${CMAKE_SOURCE_DIR}/common/foo)
Then you can just do include(${CMAKE_SOURCE_DIR}/utils/b/header-deps.cmake)
and it will add everything that B needs including all its dependencies.
--
Glenn
On 7 September 2011 06:53, Raymond Wan r@aist.go.jp wrote:
Hi Victor,
On Wed, Sep 7, 2011 at 05:39, Victor Yankee
victor.whiskey.yan...@gmail.com wrote:
There may 3 or 4 levels. At the top level, I would very much like to
avoid
needing to know all the dependencies at all the lower levels and
exhaustively listing each one in an 'include_directories()' command.
If utils/B.h needs utils/A.h which needs foo/Z.h, then in my top-level
directory (that only needs to know about B.h) what does its
CMakeLists.txt
look like? I would like to just be add_includes(utils/B) and have cmake
figure out it also needs utils/A and foo.
I see what you mean now. David's reply says it better than I ever could...
The only thing I can add is that I have the same problem as you. :-)
Many include_directories (), even for those that are more than one
degree of separation away... I've since given up and just have a long
list of include_directories ()...
Ray
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: [CMake 0012398]: IF infamous variable/string functionality fails to work with macro arguments
On 15 August 2011 20:23, Albert Meltzer buls...@gmail.com wrote:
Maybe the esteemed colleagues would suggest another good and reliable way
to handle situations such as this:
IF (lang STREQUAL perl) ...
ELSEIF(lang STREQUAL python) ...
ELSEIF()
...
ENDIF ()
without having to SET(perl perl) (and all the other cases in this switch)
myself (just in case), but still being afraid that somebody, somewhere else,
would SET(perl 5.10.0), and without resorting to IF (lang MATCHES ^perl$)?
Maybe I'm missing something obvious here but wouldn't the following code
work okay:
if (${lang} STREQUAL perl) ...
elseif (${lang} STREQUAL python) ...
elseif ()
...
endif ()
--
Glenn
___
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] append command
I was thinking of using the exact same variable names as are currently in
use. Currently if I do this:
set(CMAKE_C_FLAGS -foo)
list(APPEND CMAKE_C_FLAGS -bar)
then it will fail as it tries to run the command /usr/bin/gcc -foo;-bar
... but if cmake automatically replaced semicolons with spaces then it
would work fine. Existing scripts that used set(CMAKE_C_FLAGS
${CMAKE_C_FLAGS} -bar) would be unaffected. And given that the cmake
variables that would be treated this way are passed directly to the
compiler/linker it is exceedingly unlikely that they would contain real
semicolons, at least on linux. Is the problem with this idea that real
semicolons in flags are necessary on windows or macosx ?
If real semicolons were required they could be escaped with a backslash
character, i.e. set(CMAKE_C_FLAGS -foo\;-bar) if you didn't want them to
be replaced with a space character. But that would break the backwards
compatibility rule. Are there any cmake variables where real semicolons
need to be passed through to the compiler/linker ?
--
Glenn
On 15 August 2011 12:56, David Cole david.c...@kitware.com wrote:
On Aug 13, 2011, at 5:14 AM, Glenn Coombs glenn.coo...@gmail.com wrote:
Out of all the suggestions so far I'd like to say that my preferred
solution is Michael's one of:
SET(variable value ... CONCAT [SEP sep])
I haven't seen any discussion yet of my 2nd alternative of getting cmake to
automatically convert lists to space separated strings for certain variables
like CMAKE_EXE_LINKER_FLAGS_RELEASE. If cmake did this then there would be
less need for the concat version of set() as one could just use the existing
list(APPEND) functionality. Is this a realistic possibility, or are there
implementation issues with this suggestion ?
No particular implementation issues. Doing any of this stuff is fairly easy
to implement.
But we won't be changing the semantics of any existing variables or
properties to accommodate a feature like this... That would be a backwards
compatibility nightmare.
And that means inventing new variables with the desired semantics, in
addition to supporting the existing ones. Which makes it very much less
likely for us to want to do it without a very strong consensus from all
involved that it really does make things easier, nicer, more maintainable.
___
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] append command
Out of all the suggestions so far I'd like to say that my preferred solution
is Michael's one of:
SET(variable value ... CONCAT [SEP sep])
I haven't seen any discussion yet of my 2nd alternative of getting cmake to
automatically convert lists to space separated strings for certain variables
like CMAKE_EXE_LINKER_FLAGS_RELEASE. If cmake did this then there would be
less need for the concat version of set() as one could just use the existing
list(APPEND) functionality. Is this a realistic possibility, or are there
implementation issues with this suggestion ?
--
Glenn
On 12 August 2011 05:16, Michael Hertling mhertl...@online.de wrote:
On 08/11/2011 10:04 PM, Alexander Neundorf wrote:
On Thursday 11 August 2011, Michael Hertling wrote:
...
Alternatively, one might consider to introduce a new, say,
modifier CONCAT for the SET() command, e.g.
SET(variable value ... CONCAT [SEP sep])
equivalent to
SET(variable ${variable}sepvalue...)
I'm not sure this is actually necessary.
Personally I'm fine with
set(foo ${foo} bar)
It's just one line. For properties more code is needed otherwise.
So far, I also don't need such a string concatenation feature, but
LIST(APPEND ...)
and
SET_PROPERTY(... APPEND/APPEND_STRING ...)
aren't actually necessary, too, but convenient, so I would not be
opposed to another convenience feature for concatenating strings.
Besides, David, due to the same reasons as mentioned above, the new
APPEND_STRING subcommand of SET_PROPERTY() is quite misnamed, IMO -
and quite long. Would it be possible to rename it to CONCAT before
it is released officially? In this way, we would consistently have
APPEND subcommands for list-style variables/properties and CONCAT
subcommands for string-style ones.
We can do that, if other people think also that this would be a better
name.
Or STRING_APPEND instead of APPEND_STRING ?
The crucial point is that the subcommand/modifier for concatenating
strings - regardless for which command(s) it is implemented - should
- not be named APPEND because this term is already in use for lists,
and there's at least one occasion where a list-related and a string-
related += operation are about to coincide, namely SET_PROPERTY().
- be named the same in all commands that provide - or possibly will
provide - this functionality. SET_PROPERTY() is going to name it
APPEND_STRING, a longish and unfortunate misnomer, IMO, that will
result in inconsistent CMakeLists.txt code if there'll be a SET()
or STRING() implementation for concatenating strings: Certainly,
one would not want to call the latter SET(... APPEND_STRING) or
STRING(STRING_APPEND ...), so one ends up with two differently
named subcommands/modifiers for the same kind of operation.
For this reason, I'd recommend to reconsider the APPEND_STRING sub-
command's naming and change it to a term that's also suitable for
a string concatenation feature in other CMake commands - just to
leave the door open. Therefor, my suggestion is CONCAT.
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
___
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] append command
Which is precisely the sort of thing that started this whole discussion :-) In the same way that C/C++ would still work without the += operator it does allow a wonderful conciseness that I miss on occasion. Especially given cmake's propensity for verbose variable names. On 13 August 2011 10:22, Michael Wild them...@gmail.com wrote: To be honest, the only occasion where I miss a more concise command is when I have pretty long variable names and it becomes essentially impossible to stay within a 80-columns line length limit. 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 ___ 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 add additional linker options
Something like this:
if (MSVC)
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS}
/FORCE:Multiply)
endif()
in your top level CMakeLists.txt should do the trick. I think the /W0 flag
will suppress any warnings. This would need to be added to CMAKE_C_FLAGS
and/or CMAKE_CPP_FLAGS in a similar manner.
--
Glenn
On 9 August 2011 17:46, Vinay Raj Hampapur vinayraj.hampa...@gmail.comwrote:
Hello,
I need to add to provide additional linker options to the program from
within my CMakeLists.txt targeted at MSVC platform. In particular, I would
like to add the /FORCE:Multiply option to the linker. How would I go about
doing this?
Also, how would I set the options to suppress any (all) warnings generated?
Thanks,
Vinay
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] append command
The problem is that we currently already have 2 parallel systems. Some of
the variables like CMAKE_EXE_LINKER_FLAGS are passed through as-is to the
compiler or linker. So, by definition, these variables are space separated
lists of options. Attempting to use list(APPEND) on them adds semicolon
characters which causes breakage unless you manually remove them.
Using list(APPEND), followed by string(REGEX REPLACE) is even more verbose
than just using the set(foo ${foo} ...) approach. I see an append()
command as just the equivalent of the += operator in C/C++ and don't think
that adding it would necessarily require adding any more space separated
list functionality. And I agree that you wouldn't really want
An alternative approach (but harder to implement) would be to abandon space
separated lists altogether. Variables like CMAKE_EXE_LINKER_FLAGS would be
stored as lists and then cmake would format them internally as space
separated strings before passing them to the native build tools. You might
have to change the way cmake internally represents lists if you ever wanted
to be able to pass options with semicolons through to the build tools.
--
Glenn
On 9 August 2011 20:34, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
On 2011-08-09 17:19+0100 Glenn Coombs wrote:
Probably too late now and there isn't a bug filed so far as I know, but
one thing I would love to see added to cmake is an append command
so that lines like this:
set(CMAKE_EXE_LINKER_FLAGS_**RELEASE ${CMAKE_EXE_LINKER_FLAGS_**RELEASE}
/INCREMENTAL:NO)
become shorter and easier to understand:
append(CMAKE_EXE_LINKER_FLAGS_**RELEASE /INCREMENTAL:NO)
The existing syntax for the set command is just ugly when appending. I
know you can define a macro or function to do this but I just
feel that it should be supported out of the box as it would make
CMakeLists.txt files more readable.
Hi Glenn:
I am changing the subject line to keep discussion out of the
bugfix thread as requested by Dave.
It appears what you want is the list APPEND command for
blank-delimited strings. But then later someone will want to add
other parts of the list functionality to blank-delimited strings as
well such as removing items from the blank-delimited list. Until you
have two parallel list systems, one for blank delimited strings and
one for semicolon-delimited strings (i.e., the current lists).
I think most would reject the idea of having two parallel list systems
with different delimiters so here is one possibility.
For now just stick to list functionality, e.g.,
list(APPEND CMAKE_EXE_LINKER_FLAGS_RELEASE /INCREMENTAL:NO)
and then change the semicolon delimiters to blanks using
strings(REGEX REPLACE ...)
once you have the list completely assembled. Of course, that will not
work for the corner case where the strings contain semicolons. So in
the long term, the right thing to do with lists might be to allow a
choice of delimiter if you could do that in such a way as to preserve
backwards compatibility.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting
software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
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] Sub dependencies?
Add the sub dependencies that library A has with target_link_libraries():
target_link_libraries(A png)
--
Glenn
On 11 August 2011 10:02, Doug douglas.lin...@gmail.com wrote:
Hrm... this seems like something cmake should be able to do, but I don't
know how to make it work.
If I have library A, that depends on a library and an executable project
that depends on library A, how can the executable project resolve the sub
dependencies from A?
Specifically libpng in my case:
I have a library that depends on libpng.
I run cmake to build the library no problem.
Then I try to compile a program that depends on the library and get a heap
of errors like:
undefined reference to `png_set_read_fn'
etc. etc.
Presumably this is something about how I depend on the library? I'm using
the LibFindMacros, so my cmake module looks like this for the library:
include(LibFindMacros)
find_path(LIBNW_INCLUDE_DIR NAMES nw.h PATHS ${LIBNW_PKGCONF_INCLUDE_DIRS})
find_library(LIBNW_LIBRARY NAMES nw PATHS ${LIBNW_PKGCONF_LIBRARY_DIRS})
set(LIBNW_PROCESS_INCLUDES LIBNW_INCLUDE_DIR)
set(LIBNW_PROCESS_LIBS LIBNW_LIBRARY LIBNW_LIBRARIES)
libfind_process(LIBNW)
I know I can use ADD_SUBDIRECTORY to include stuff for a sub dir, but that
isn't really appropriate in this case.
~
Doug.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Sub dependencies?
The target_link_libraries() command would be in the CMakeLists.txt for
library A, not the one for your executable. The one for your executable
would just say target_link_libraries(myExe A). And cmake would
automatically know that linking with A also means linking with png.
You say that you have 2 different versions of library A. Does this mean
that you have 2 separate CMakeLists.txt files, one for each variant of A.
Or are both variants built by the same CMakeLists.txt ? Either way, I would
have thought that you could add the appropriate target_link_libraries()
command. Can you describe your current setup in a bit more detail to
explain why this approach won't work ?
On 11 August 2011 14:02, Doug douglas.lin...@gmail.com wrote:
How can I achieve that _without_ editing my own cmake file?
What if a swap in a different library for my executable that is abi
compatible but uses a different implemented to load images?
I'm not talking hypotheticals here: I literally have two versions of the
library that use slightly different versions of libpng (one for desktop and
one for android) and it's extremely inconvenient to be messing around with
my cmake file every time I change my build target.
Sure I can do a giant IF(TARGET MATCHES Android) ... ENDIF, which I guess
is what I will do for now, but it seems like a poor solution.
Edit: woops; ment that to go to the list.
~
Doug.
On Thu, Aug 11, 2011 at 7:39 PM, Glenn Coombs glenn.coo...@gmail.comwrote:
Add the sub dependencies that library A has with target_link_libraries():
target_link_libraries(A png)
--
Glenn
On 11 August 2011 10:02, Doug douglas.lin...@gmail.com wrote:
Hrm... this seems like something cmake should be able to do, but I don't
know how to make it work.
If I have library A, that depends on a library and an executable project
that depends on library A, how can the executable project resolve the sub
dependencies from A?
Specifically libpng in my case:
I have a library that depends on libpng.
I run cmake to build the library no problem.
Then I try to compile a program that depends on the library and get a
heap of errors like:
undefined reference to `png_set_read_fn'
etc. etc.
Presumably this is something about how I depend on the library? I'm using
the LibFindMacros, so my cmake module looks like this for the library:
include(LibFindMacros)
find_path(LIBNW_INCLUDE_DIR NAMES nw.h PATHS
${LIBNW_PKGCONF_INCLUDE_DIRS})
find_library(LIBNW_LIBRARY NAMES nw PATHS ${LIBNW_PKGCONF_LIBRARY_DIRS})
set(LIBNW_PROCESS_INCLUDES LIBNW_INCLUDE_DIR)
set(LIBNW_PROCESS_LIBS LIBNW_LIBRARY LIBNW_LIBRARIES)
libfind_process(LIBNW)
I know I can use ADD_SUBDIRECTORY to include stuff for a sub dir, but
that isn't really appropriate in this case.
~
Doug.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
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] Bug fix requests for the *next* release of CMake...
Probably too late now and there isn't a bug filed so far as I know, but one
thing I would love to see added to cmake is an append command so that lines
like this:
set(CMAKE_EXE_LINKER_FLAGS_RELEASE ${CMAKE_EXE_LINKER_FLAGS_RELEASE}
/INCREMENTAL:NO)
become shorter and easier to understand:
append(CMAKE_EXE_LINKER_FLAGS_RELEASE /INCREMENTAL:NO)
The existing syntax for the set command is just ugly when appending. I know
you can define a macro or function to do this but I just feel that it should
be supported out of the box as it would make CMakeLists.txt files more
readable.
--
Glenn
___
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] Assembly language support using gcc or gas
Hi Alex,
I've tested your zip file example and it works as expected: the -I options
are present but not the -D options. After some more testing of what is
different in my setup I think I have isolated the cause. If I change this
one line in your example from this:
add_definitions(-DFOO)
to this:
add_definitions(-DFOO -DBAR)
then I get the same behaviour I was seeing before: the -DFOO -DBAR options
are passed through to the assembler command line. I see from the
documentation that I should really be using add_definitions(-DFOO -DBAR)
without the double quotes but they were harmless before. Should I file this
as a bug - or will it just be marked as not a bug, i.e. don't use double
quotes like that with add_definitions ?
--
Glenn
2011/8/3 Alexander Neundorf a.neundorf-w...@gmx.net
Hi,
On Wednesday 03 August 2011, Glenn Coombs wrote:
I tried changing from ASM to ASM-ATT and that fails like this:
/usr/bin/as -I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src
-I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/kernel
-DNOMINMAX -DUSE_SIM_NAMESPACE -o
CMakeFiles/systemc.dir/src/sysc/qt/md/i386.s.o
/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/qt/md/i386.
s /usr/bin/as: unrecognized option `-NOMINMAX'
I really don't think the -I and -D options should be passed through for
assembler files. They only make sense for C/C++ files. There should be
a
separate variable like CMAKE_ASM_FLAGS that is used instead of
CMAKE_C_FLAGS or CMAKE_CXX_FLAGS. And maybe there needs to be a change
to
the
add_definitions() command to allow an optional LANG argument ? Do
assembers even support preprocessor definitions ?
I was able to get it to work for both 2.8.4 and 2.8.5 with the following
code:
if(UNIX)
list(APPEND sources src/sysc/qt/qt.c)
# see if we are building 32-bit or 64-bit executables
file(WRITE ${CMAKE_BINARY_DIR}/check_32or64bit.cpp int main(int
argc,
char *argv[]) { return 8 * sizeof(char *); }\n)
try_run(
run_result
compile_result
${CMAKE_BINARY_DIR}
${CMAKE_BINARY_DIR}/check_32or64bit.cpp
)
if (${run_result} EQUAL 32)
list(APPEND sources src/sysc/qt/md/i386.s)
if(APPLE)
set(ASM_SYS_FLAGS -arch i386)
else()
set(ASM_SYS_FLAGS -32)
endif()
else()
list(APPEND sources src/sysc/qt/md/iX86_64.s)
if(APPLE)
set(ASM_SYS_FLAGS -arch x86_64)
else()
set(ASM_SYS_FLAGS -64)
endif()
endif()
enable_language(ASM-ATT)
set(CMAKE_ASM-ATT_COMPILE_OBJECT CMAKE_ASM-ATT_COMPILER
${ASM_SYS_FLAGS} -o OBJECT SOURCE)
endif()
I'm not sure if this is the recommended way to do this though. I thought
the documentation said to override CMAKE_ASM-ATT_COMPILE_OBJECT before
the
enable_language() command.
You should not have to override it.
To set flags, there are for every enabled language CMAKE_LANGUAGE_FLAGS
in
the cmake cache, i.e. CMAKE_ASM-ATT_FLAGS in this case.
I tried to reproduce the problem with the attached tiny project, and I
don't
get the problem you describe. This is the output:
as-test/b$ /opt/cmake-HEAD/bin/cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- The ASM-ATT compiler identification is GNU
-- Found assembler: /usr/bin/as
-- Configuring done
-- Generating done
-- Build files have been written to: /home/alex/src/CMake/build dir/CMake-
git/Tests/Assembler/as-test/b
as-test/b$ make VERBOSE=1
...
Scanning dependencies of target hello
make[2]: Leaving directory `/home/alex/src/CMake/build dir/CMake-
git/Tests/Assembler/as-test/b'
make -f CMakeFiles/hello.dir/build.make CMakeFiles/hello.dir/build
make[2]: Entering directory `/home/alex/src/CMake/build dir/CMake-
git/Tests/Assembler/as-test/b'
/opt/cmake-HEAD/bin/cmake -E cmake_progress_report
/home/alex/src/CMake/build
dir/CMake-git/Tests/Assembler/as-test/b/CMakeFiles 1
[ 50%] Building C object CMakeFiles/hello.dir/main.c.o
/usr/bin/gcc -DFOO -DBLUB=blub -DBAR=bar -I/opt/include-o
CMakeFiles/hello.dir/main.c.o -c /home/alex/src/CMake/build dir/CMake-
git/Tests/Assembler/as-test/main.c
/opt/cmake-HEAD/bin/cmake -E cmake_progress_report
/home/alex/src/CMake/build
dir/CMake-git/Tests/Assembler/as-test/b/CMakeFiles 2
[100%] Building ASM-ATT object CMakeFiles/hello.dir/foo.s.o
/usr/bin/as -I/opt/include-o CMakeFiles/hello.dir/foo.s.o
/home/alex/src/CMake/build dir/CMake
Re: [CMake] Include directories for C compile command
CMake deliberately works in a top-down manner for most things. So variable values and preprocessor definitions are inherited in subdirectories from the values they had in the parent. And any subsequent changes made to them in the subdirectory scope are not propogated up to the parent. This is a good thing in my opinion because it allows you to isolate components from one another. If you try to work against this you will find it difficult as CMake doesn't work that way. On 4 August 2011 06:15, Andrei Buzgan andrei.buz...@gmail.com wrote: Hello Glenn and thanks, I found out yesterday the method you describe works. I was trying to use include_directories() before, but unfortunately the statement was after any add_directory() statement and it was a matter of scope (what other variable/property updates add_directory() does?). It works now, but still I'm wondering if there is a method of doing the same thing at module level (leaf CMakeLists.txt files) and propagate the updates upwards in directory hierarchy. Thanks again, Andrei On Wed, Aug 3, 2011 at 8:10 PM, Glenn Coombs glenn.coo...@gmail.comwrote: Have you tried using the include_directories() command ? In your top level CMakeLists.txt add a line like this: include_directories(SWC1 SWC2 SWC3 Common) before you do any add_subdirectory() commands. Does that not add the appropriate -Ixxx flags to the compile command ? It does for me but I'm using Visual Studio and gcc rather than an embedded compiler. On 3 August 2011 07:25, Andrei Buzgan andrei.buz...@gmail.com wrote: Hello everyone, I'm trying to set up an environment for building a pre-existing medium sized embedded software project, by using CMake 2.8 and MinGW. The compiler kit is specific for the target microcontroller and contains C compiler, assembler, linker, all different executables. I do have some restrictions: The project structure looks like this: Sources |-- SWC1 ||-- swc1.c ||-- swc1.h ||--CMakeLists.txt |-- SWC2 ||-- swc2_a.c ||-- swc2_b.c ||-- swc2.h ||--CMakeLists.txt |-- COMMON ||-- config1.h ||-- config2.h ||--CMakeLists.txt |-- UNUSED_DIR |-- SWC3 ||-- swc3.obj ||-- swc3.h - I cannot change the directory structure of the project (i can add but i must not move files around) - each SW module (component) has it own files including interface headers in it's own directory (SW component SWC1 resides in folder SWC1 and contains a source file and a header file) - SW modules may be interfaced with any other module (swc1.c may include swc2.h...) - There are common header files with project scope definitions and configurations which reside in their own directory too (both swc1.c and swc2.c may include headers config1.h and config2.h) - The SW has more variants, some variants use different C source files for a specific SW component but the sources reside in the same directory and interface headers are common for all variants. (For SW variant A the SW component SWC2 uses swc2_a.c source file, for SW variant B it uses swc2_b.c file) - Some SW components are precompiled and provided as object files together with the interface header (SWC3) *These being the conditions, i couldn't manage to gather the relevant folders in order to correctly create the build object command *where flags like -Idir_pah1 -Idir_path2 ... are expected in order to look for included headers. Due to mixed source-precompiled objects I chose to define each component as a static library (add_library(...)) in each CMakeLists.txt file and list there the used source files, being able to use conditions for SW variants and basically add different library definitions for each variant. I intend to add the pre-compiled sources as IMPORTED libraries and in the end just link the libraries with the specific linker command for linking any object files (but i didn't get there yet!) I'm currently use the default CMAKE_C_COMPILE_OBJECT command CMAKE_C_COMPILER DEFINES FLAGS -o OBJECT -c SOURCE, the compiler ignoring the unknown flags (-c in this case). *Without any explicit configuration from my part, it looks like FLAGS variable contains also a -Ipath directive for the current compiled source file* (path is the same directory where the source files about to be compiled resides). I tried to use set( CMAKE_INCLUDE_CURRENT_DIR ON ) in each CMakeLists.txt file but FLAGS variable seems not to be updated this way. I'd like to know if there is an efficient method to build an include directory list in order to pass it to compile flags. It would be very useful to make this in CMakeLists.txt file or link it somehow to add_directory(dir) and use an internal CMake mechanism trying to avoid creating this part of the compiler flags manually in order to be easily maintained in the future. Thanks, Andrei ___ Powered by www.kitware.com Visit
Re: [CMake] Easing the pain with Visual Studio 2010 and CMake
We do much the same but use a batch file called startDevStudio.vs2010.cmake.bat like this in the top level: @echo off if not exist build\cmake mkdir build\cmake cd build\cmake cmake -G Visual Studio 10 ..\..\ IF ERRORLEVEL 1 ( echo. echo CMake configure failed echo. pause exit 1 ) start title your_project_name.sln Using a batch file makes it mostly painless to quit and relaunch Visual Studio. On 4 August 2011 09:05, Thomas Sondergaard t...@medical-insight.com wrote: It is a bit of a pain to work with Visual Studio 2010 and CMake due to this bug: http://gccxml.org/Bug/view.**php?id=11258http://gccxml.org/Bug/view.php?id=11258(VS 2010 CMake plugin is broken). It doesn't look like much progress is being made with fixing this bug, so I'm looking for workarounds. To this point, whenever I've changed anything that I know will cause CMake to rerun I will close the solution, run cmake by hand in a shell and then open the solution again. If someone have developed a better workaround for this I invite them to post it to this thread. Thanks, Thomas __**_ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Assembly language support using gcc or gas
I tried changing from ASM to ASM-ATT and that fails like this:
/usr/bin/as -I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src
-I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/kernel
-DNOMINMAX -DUSE_SIM_NAMESPACE -o
CMakeFiles/systemc.dir/src/sysc/qt/md/i386.s.o
/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/qt/md/i386.s
/usr/bin/as: unrecognized option `-NOMINMAX'
I really don't think the -I and -D options should be passed through for
assembler files. They only make sense for C/C++ files. There should be a
separate variable like CMAKE_ASM_FLAGS that is used instead of CMAKE_C_FLAGS
or CMAKE_CXX_FLAGS. And maybe there needs to be a change to the
add_definitions() command to allow an optional LANG argument ? Do assembers
even support preprocessor definitions ?
I was able to get it to work for both 2.8.4 and 2.8.5 with the following
code:
if(UNIX)
list(APPEND sources src/sysc/qt/qt.c)
# see if we are building 32-bit or 64-bit executables
file(WRITE ${CMAKE_BINARY_DIR}/check_32or64bit.cpp int main(int argc,
char *argv[]) { return 8 * sizeof(char *); }\n)
try_run(
run_result
compile_result
${CMAKE_BINARY_DIR}
${CMAKE_BINARY_DIR}/check_32or64bit.cpp
)
if (${run_result} EQUAL 32)
list(APPEND sources src/sysc/qt/md/i386.s)
if(APPLE)
set(ASM_SYS_FLAGS -arch i386)
else()
set(ASM_SYS_FLAGS -32)
endif()
else()
list(APPEND sources src/sysc/qt/md/iX86_64.s)
if(APPLE)
set(ASM_SYS_FLAGS -arch x86_64)
else()
set(ASM_SYS_FLAGS -64)
endif()
endif()
enable_language(ASM-ATT)
set(CMAKE_ASM-ATT_COMPILE_OBJECT CMAKE_ASM-ATT_COMPILER
${ASM_SYS_FLAGS} -o OBJECT SOURCE)
endif()
I'm not sure if this is the recommended way to do this though. I thought
the documentation said to override CMAKE_ASM-ATT_COMPILE_OBJECT before the
enable_language() command. If I do that then I get the -I and -D flags back
and my ASM_SYS_FLAGS variable is ignored. Is there a cleaner way to do this
or is my current solution okay ?
2011/8/2 Alexander Neundorf a.neundorf-w...@gmx.net
Hi,
On Tuesday 02 August 2011, Glenn Coombs wrote:
Previously with cmake 2.8.4 we were using these lines to compile an
with 2.8.5 there was a major rework of the assembler support (and now it
finally does not say Assembler support is experimental anymore).
Sorry that this causes inconvenience for you.
If you enable ASM, you get support for assembler via your C/C++ compiler.
That's why you get gcc now instead of as.
If the C/C++ compiler does not support processing assembler files, this
language can't be enabled.
If you need a real assembler, you have to enable the respective assembler
dialect. E.g. to get as/gas, you need to enable ASM-ATT.
This should work with both versions.
Let me know if this doesn't work for you.
Alex
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Include directories for C compile command
Have you tried using the include_directories() command ? In your top level CMakeLists.txt add a line like this: include_directories(SWC1 SWC2 SWC3 Common) before you do any add_subdirectory() commands. Does that not add the appropriate -Ixxx flags to the compile command ? It does for me but I'm using Visual Studio and gcc rather than an embedded compiler. On 3 August 2011 07:25, Andrei Buzgan andrei.buz...@gmail.com wrote: Hello everyone, I'm trying to set up an environment for building a pre-existing medium sized embedded software project, by using CMake 2.8 and MinGW. The compiler kit is specific for the target microcontroller and contains C compiler, assembler, linker, all different executables. I do have some restrictions: The project structure looks like this: Sources |-- SWC1 ||-- swc1.c ||-- swc1.h ||--CMakeLists.txt |-- SWC2 ||-- swc2_a.c ||-- swc2_b.c ||-- swc2.h ||--CMakeLists.txt |-- COMMON ||-- config1.h ||-- config2.h ||--CMakeLists.txt |-- UNUSED_DIR |-- SWC3 ||-- swc3.obj ||-- swc3.h - I cannot change the directory structure of the project (i can add but i must not move files around) - each SW module (component) has it own files including interface headers in it's own directory (SW component SWC1 resides in folder SWC1 and contains a source file and a header file) - SW modules may be interfaced with any other module (swc1.c may include swc2.h...) - There are common header files with project scope definitions and configurations which reside in their own directory too (both swc1.c and swc2.c may include headers config1.h and config2.h) - The SW has more variants, some variants use different C source files for a specific SW component but the sources reside in the same directory and interface headers are common for all variants. (For SW variant A the SW component SWC2 uses swc2_a.c source file, for SW variant B it uses swc2_b.c file) - Some SW components are precompiled and provided as object files together with the interface header (SWC3) *These being the conditions, i couldn't manage to gather the relevant folders in order to correctly create the build object command *where flags like -Idir_pah1 -Idir_path2 ... are expected in order to look for included headers. Due to mixed source-precompiled objects I chose to define each component as a static library (add_library(...)) in each CMakeLists.txt file and list there the used source files, being able to use conditions for SW variants and basically add different library definitions for each variant. I intend to add the pre-compiled sources as IMPORTED libraries and in the end just link the libraries with the specific linker command for linking any object files (but i didn't get there yet!) I'm currently use the default CMAKE_C_COMPILE_OBJECT command CMAKE_C_COMPILER DEFINES FLAGS -o OBJECT -c SOURCE, the compiler ignoring the unknown flags (-c in this case). *Without any explicit configuration from my part, it looks like FLAGS variable contains also a -Ipath directive for the current compiled source file* (path is the same directory where the source files about to be compiled resides). I tried to use set( CMAKE_INCLUDE_CURRENT_DIR ON ) in each CMakeLists.txt file but FLAGS variable seems not to be updated this way. I'd like to know if there is an efficient method to build an include directory list in order to pass it to compile flags. It would be very useful to make this in CMakeLists.txt file or link it somehow to add_directory(dir) and use an internal CMake mechanism trying to avoid creating this part of the compiler flags manually in order to be easily maintained in the future. Thanks, Andrei ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Assembly language support using gcc or gas
Previously with cmake 2.8.4 we were using these lines to compile an assembly
language file in our project:
if(UNIX)
enable_language(ASM)
# see if we are building 32-bit or 64-bit executables
file(WRITE ${CMAKE_BINARY_DIR}/check_32or64bit.cpp int main(int argc,
char *argv[]) { return 8 * sizeof(char *); }\n)
try_run(
run_result
compile_result
${CMAKE_BINARY_DIR}
${CMAKE_BINARY_DIR}/check_32or64bit.cpp
)
if (${run_result} EQUAL 32)
list(APPEND sources src/sysc/qt/md/i386.s)
if(APPLE)
set(ASM_SYS_FLAGS -arch i386)
else()
set(ASM_SYS_FLAGS -32)
endif()
else()
list(APPEND sources src/sysc/qt/md/iX86_64.s)
if(APPLE)
set(ASM_SYS_FLAGS -arch x86_64)
else()
set(ASM_SYS_FLAGS -64)
endif()
endif()
set(CMAKE_ASM${ASM_DIALECT}_COMPILE_OBJECT
CMAKE_ASM${ASM_DIALECT}_COMPILER ${ASM_SYS_FLAGS} -o OBJECT SOURCE)
endif()
And this resulted in the appropriate 32-bit or 64-bit assembler file being
compiled like so:
/usr/bin/as -32 -o path snipped/i386.s.o path-snipped/i386.s
/usr/bin/as -64 -o path snipped/iX86_64.s.o path-snipped/iX86_64.s
Now with cmake 2.8.5 it fails when compiling that assembler file as it uses
/usr/bin/gcc rather than /usr/bin/as and gcc wants -m32 and -c instead of
-32. When I tried commenting out the line that overrides the default
setting of CMAKE_ASM${ASM_DIALECT}_COMPILE_OBJECT it fails differently:
/usr/bin/gcc -DEXTERNAL_BUS_WIDTH=128 -DLINUX -DHIDEBUG -O3 -DNDEBUG
-I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src
-I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/kernel
-DNOMINMAX -DUSE_SIM_NAMESPACE -o
CMakeFiles/systemc.dir/src/sysc/qt/md/i386.s.o -c
/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/qt/md/i386.s
i386.s:69: Error: suffix or operands invalid for `push'
This line works if I add the -m32 option using set(CMAKE_ASM_FLAGS -m32)
but should all the preprocessor defines (-DXXX) and include directory
arguments (-IXXX) be present ? I was thinking they were only for C/C++
files, no ?
And what is the recommended way to compile an assembly language file that
will work on both 2.8.4 and 2.8.5 ?
--
Glenn
___
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] Bug fix requests for the *next* release of CMake...
http://public.kitware.com/Bug/view.php?id=6493 configuration dependent COMPILE_FLAGS for SET_TARGET_PROPERTIES http://public.kitware.com/Bug/view.php?id=6269 Some CMake commands should support Debug/Release configurations http://public.kitware.com/Bug/view.php?id=12124http://public.kitware.com/Bug/view.php?id=6269 Need per configuration version of target_link_libraries() or fix IMPORTED_LOCATION to allow empty string -- Glenn ___ 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] Invalid library output directory when VC++ solution is generated
You could set the target property RUNTIME_OUTPUT_DIRECTORY on your library
targets. That would override the CMAKE_RUNTIME_OUTPUT_DIRECTORY variable
just for those targets.
2011/7/27 Laura Autón García laura.au...@gmail.com
Hello Alan,
Thank you very much for your answer.
It woks perfectly using deprecated options, which is kind of funny,
isn't it? As Glenn pointed out in his reply afterwards, newer options
(ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY and
RUNTIME_OUTPUT_DIRECTORY) work differently from deprecated ones, as in
Windows, shared libraries are generated in the runtime directory
instead of the library directory. And static libraries are even
generated in the archive output directory instead of library
directory:
Executables are always treated as runtime targets. -- Static
libraries are always treated as archive targets ---. Module libraries
are always treated as library targets. -- For non-DLL platforms
shared libraries are treated as library targets -- (that's why it
works as expected in Linux). -- For DLL platforms the DLL part of a
shared library is treated as a runtime target -- and the
corresponding import library is treated as an archive target. All
Windows-based systems including Cygwin are DLL platforms.
By the way, we build shared libraries after our project solution is
generated. I mean, we first generate with CMake the solution to be
opened in Visual C++ and then we compile the solution in Visual C++.
At the point of compilation, the dll library is generated. So that,
there is no conflict between when we determine where the dll is to be
generated and when is generated.
I am not really experienced with CMake tool, but it seems their
developers had their reasons to determine that dll's have to be
generated in the runtime directory rather than library one. That's not
what we want though. We may accept the changes unless we figure out
other way to do it.
2011/7/25 Alan W. Irwin ir...@beluga.phys.uvic.ca:
On 2011-07-25 12:19+0100 Laura Autón García wrote:
Hello all,
In the project I am collaborating on, CMake is used in Windows in
order to generate a Visual C++ solution to be compiled afterwards. In
this process, everything seems to work fine as the external
directories and libraries are well included and everything compiles
and so. However, we are experiencing problems with the directory in
which our dll library is to be created.
We specify in CMake that the directory is ../lib but
when checking the configuration in Visual C++ software, it seems to be
../bin/Release directory, so the library is generated there.
The CMake sentences we wrote regarding this issue are as follows:
SET(LIB_DIR ${PROJECT_SOURCE_DIR}/lib)
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LIB_DIR} CACHE PATH Directory
for libraries)
One possibility is you are setting CMAKE_LIBRARY_OUTPUT_DIRECTORY
after your dll's are built.
Just in case that is not the source of the problem, here is
some further discussion.
I cannot spot anything wrong with your command above. However, our
project (PLplot) hasn't tried that recommended variable yet. Instead
we use the deprecated LIBRARY_OUTPUT_PATH variable (mentioned in the
documentation) like the following (because we are a cross-platform
project):
# in windows all created dlls are gathered in the dll directory
# if you add this directory to your PATH all shared libraries are
available
if(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll)
endif(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
This works on Windows according to others, and I have also
personally verified that it works under Wine.
Although a different variable is used, note the differences with
how that variable is set with your case.
(1) The subdirectory is in the build tree rather than the source
tree.
(2) We don't cache the variable.
I don't think any of these differences should matter in terms of
whether the functionality works or not, but you might want to try them
with CMAKE_LIBRARY_OUTPUT_DIRECTORY just in case that might be the
source of your difficulty. You could also set LIBRARY_OUTPUT_PATH
like we do as a test, but it would be better to figure out how to get
CMAKE_LIBRARY_OUTPUT_DIRECTORY to work correctly since our approach is
deprecated. (It wasn't deprecated when we started using CMake years
ago, and we plan to switch over to the recommended method at some point.)
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and
Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting
software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads
of
Linux Links project
Re: [CMake] Invalid library output directory when VC++ solution is generated
Have a look at the documentation for CMAKE_RUNTIME_OUTPUT_DIRECTORY. On
Linux the .so shared library files do go in the LIBRARY_OUTPUT_DIRECTORY.
However, on Windows the DLL files are placed in the runtime directory and
only the import libraries (.LIB files) are placed in the
LIBRARY_OUTPUT_DIRECTORY.
2011/7/25 Laura Autón García laura.au...@gmail.com
Hello all,
In the project I am collaborating on, CMake is used in Windows in
order to generate a Visual C++ solution to be compiled afterwards. In
this process, everything seems to work fine as the external
directories and libraries are well included and everything compiles
and so. However, we are experiencing problems with the directory in
which our dll library is to be created.
We specify in CMake that the directory is ../lib but
when checking the configuration in Visual C++ software, it seems to be
../bin/Release directory, so the library is generated there.
The CMake sentences we wrote regarding this issue are as follows:
SET(LIB_DIR ${PROJECT_SOURCE_DIR}/lib)
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LIB_DIR} CACHE PATH Directory
for libraries)
According to the documentation:
CMAKE_LIBRARY_OUTPUT_DIRECTORY: Where to put all the LIBRARY
targets when built.
This variable is used to initialize the LIBRARY_OUTPUT_DIRECTORY
property on all the targets.
See that target property for additional information.
Also, the documentation regarding LIBRARY_OUTPUT_DIRECTORY shows:
LIBRARY_OUTPUT_DIRECTORY: Output directory in which to build
LIBRARY target files.
This property specifies the directory into which library target
files should be built. There are three
kinds of target files that may be built: archive, library, and
runtime. Executables are always treated
as runtime targets. Static libraries are always treated as archive
targets. Module libraries are always
treated as library targets. For non-DLL platforms shared libraries
are treated as library targets. For
DLL platforms the DLL part of a shared library is treated as a
runtime target and the corresponding
import library is treated as an archive target. All Windows-based
systems including Cygwin are
DLL platforms. This property is initialized by the value of the variable
CMAKE_LIBRARY_OUTPUT_DIRECTORY if it is set when a target is created.
However, when the project is generated, the library output directory
is not the one specified, but the one I mentioned above.
If anyone has any idea why this may be happening, it would be appreciated.
The binaries, on the other hand, as generated in their correct directory.
Thank you in advance.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Build the dependencies tree of an executable
Have you tried using target_link_libraries(A D E F) in A/Deps.cmake instead of add_dependencies ? I think that the add_dependencies command only enforces a build order between targets. I don't think it actually adds libraries to the link line. On 18 July 2011 17:54, Marco Corvo marco.co...@pd.infn.it wrote: Hi all, I'm facing the following problem trying to generate the dependencies tree of an executable. I have a working area /path/to/my/working/area/**MyPackage with, say, one executable I want to build. The relevant CMakeLists.txt line is something like: add_executable(App src/App.cc) target_link_libraries(App A B C D) now these libs (A B C D) are already installed somewhere and they depend on other libraries of my software release. Say they're under /path/to/sw/release/X.Y.Z/lib/**arch/libA.a /path/to/sw/release/X.Y.Z/lib/**arch/libB.a /path/to/sw/release/X.Y.Z/lib/**arch/libC.a /path/to/sw/release/X.Y.Z/lib/**arch/libD.a /path/to/sw/release/X.Y.Z/lib/**arch/libE.a ... and that A depends on D, E and F. When I run my build, cmake only finds that my App has A, B, C and D as dependencies, while actually these libraries have also their own dependencies. I tried to add a .cmake file to each package in the release area /path/to/sw/release/X.Y.Z/**packageA/Deps.cmake /path/to/sw/release/X.Y.Z/**packageB/Deps.cmake /path/to/sw/release/X.Y.Z/**packageD/Deps.cmake with add_library(A STATIC IMPORTED) add_dependencies(A D E F...) which is includeed with my CmakeLists.txt file in order to let cmake know that when I build App it depends on A, B, C D _and_ A itself depends in his turn on D, E and F. This should create a complete dependencies tree for my App. I know that add_dependencies gives Adding dependency to non-existent target with cmake version before 2.8.4 if the target is IMPORTED while with 2.8.4/5 on a Scientific Linux 5 I'm getting a seg fault with the add_dep directive. Is this nevertheless the way to solve this problem? Are there other ways to build the dependencies tree of an executable which depends directly on some libs and indirectly on some other ones? Consider that I build static libraries, so I need to have the full list of libraries when linking the executable. Thanks in advance for your help. Cheers Marco -- Marco Corvo SuperB experiment CNRS - Orsay c/o INFN - Padova __**_ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Appending to the LINK_FLAGS target property ?
Excellent. Do you know if this option was included in the recent cmake
2.8.5 release, or will it not appear officially until 2.8.6 ?
On 22 July 2011 18:39, Johan Björk p...@spotify.com wrote:
Glenn,
An option APPEND_STRING was added, see
http://public.kitware.com/Bug/view.php?id=12342
/Johan
On Mon, Jun 27, 2011 at 4:47 PM, Glenn Coombs glenn.coo...@gmail.com
wrote:
For variables like CMAKE_C_FLAGS one can append to them like this:
set(CMAKE_C_FLAGS ${CMAKE_CFLAGS} -some_option)
For target properties like LINK_FLAGS I was using this command:
set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS
/NODEFAULTLIB:LIBCMT)
to do the append. However, when I append a second time:
set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS
/INCLUDE:_InitLibrary)
then it breaks because the string that Visual Studio sees contains a
semicolon in between the 2 options. I can work round this by writing my
append like this:
get_property(link_flags TARGET myDLL PROPERTY LINK_FLAGS)
set(link_flags ${link_flags} /INCLUDE:_InitLibrary)
set_target_properties(myDLL PROPERTIES LINK_FLAGS ${link_flags})
but that is a bit verbose for my liking. I understand that the
semicolons
are how cmake separates list items from one another but shouldn't cmake
automatically stringify the list (by replacing semicolons with spaces)
before passing it through to the generator code ? The same problem will
occur for any of the XXX_FLAGS properties like COMPILE_FLAGS that are
passed
through unchanged to the makefile or Visual Studio project file.
Is it worth filing a feature request to ask for cmake to stringify lists
for
the appropriate variables ? Or is there a good reason why cmake can't or
shouldn't implement this behaviour ?
--
Glenn
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] External_Project_Add() and custom build configurations ?
On 6 July 2011 17:27, David Cole david.c...@kitware.com wrote:
(Don't know if you meant to omit the CMake mailing list on that, or if that
was on oversight Feel free to put my responses back on list if you
wish.)
Oops, no I didn't mean to omit the mailing list.
One more point: ExternalProject is completely and fully customizable. You
could certainly add a clean step to any ExternalProject that you like. Or
you could define a clean_externals at the top level that goes and cleans
everything. If you can figure out the right clean sub-commands.
I'm not sure but wouldn't getting clean to work with Visual Studio require
changes to the generator code to add hooks in the vcproj files on either the
BeforeClean or AfterClean events ? As far as I can tell Visual Studio cleans
a project by deleting the files it thinks the project creates. For normal
C/C++ projects this works as expected but for external projects the created
files are not known in the external project vcproj file. However, they are
known in the subdirectory external project vcproj file. To clarify, in my
case the external project has these 2 vcproj files:
buildDir/external_proj.vcproj
buildDir/external_proj/src/external_proj-build/myProjName.vcproj
The top level external_proj.vcproj file only contains a folder of
CMakeBuildRules which specify custom build commands for each of the
configure, build, install etc. steps. When this top level project is built
it invokes cmake --build buildDir/external_proj/src/external_proj-build to
do the actual build.
If I clean external_proj then it has no idea what to delete under the
buildDir/external_proj/src/external_proj-build directory. But if cmake
had hooked the AfterClean event on external_proj and then called cmake
--build buildDir/external_proj/src/external_proj-build --target clean then
that would get Visual Studio to clean the lower level myProjName.vcproj
which does know which files to clean because it is a normal C/C++ project.
The top level external_proj is the only one visible in Visual Studio. The
lower level myProjName is not visble in Visual Studio but it is the only one
that knows how to do the clean. If the top level one forwarded the clean to
it then everything would work.
I haven't checked but I suspect the same thing would work for the Makefile
generators. The top level make clean would just call make clean on the
lower level makefile.
--
Glenn
On Wed, Jul 6, 2011 at 12:24 PM, David Cole david.c...@kitware.com wrote:
On Wed, Jul 6, 2011 at 12:17 PM, Glenn Coombs glenn.coo...@gmail.comwrote:
On 5 July 2011 17:13, David Cole david.c...@kitware.com wrote:
It is (intentionally) missing some functionality. You have not
misunderstood.
The general case of ExternalProject is completely arbitrary, although we
do use reasonable default commands for cmake projects and configure/make
projects as they are conventionally used... Since it's completely
arbitrary,
we do not know if there is a 'clean' target at each level.
Don't all projects configured using cmake have a clean target ?
Certainly the makfiles on linux have a clean target, and the Visual Studio
projects can all be individually cleaned. It looks like
ExternalProject_Add() already adds special case targets for test and install
so that they end up calling:
cmake --build ${buildDir} --config ${CMAKE_CFG)INTDIR} --target test
cmake --build ${buildDir} --config ${CMAKE_CFG)INTDIR} --target
install
Would it not make sense to also add a special target for clean in the
same manner ?
It would make sense. But there is no --target clean on Visual Studio
builds. Visual Studio has a clean mechanism, not a clean build target. So
the API for doing a clean operation is inconsistent across all CMake
generators. If it were consistent, I might be inclined to agree with you,
but it's not.
The best 'clean' is starting with an absolutely empty build tree, and
running CMake and your build system from there.
Since the best 'clean' is always going to be better than any
target-based clean we could come up with, I wouldn't even attempt to add
this functionality unless nearly everybody unanimously agreed that we
should
have it. And only then if somebody writes a patch to provide it.
On those grounds why do the cmake generated makefiles provide a clean
target ?
Because it was already here when I got here. :-) I'm pretty sure the
primary motivation is because some projects have ridiculously long initial
configuration times, and avoiding that by keeping the cache while blowing
away the object files is useful to some... Personally, I'd rather see folks
work on minimizing their configure times.
Given that the infrastructure for cleaning is already present in cmake
configured projects what reason is there to deliberately omit the code to
call that funcionality ?
As mentioned above, there is no consistent API that is convenient for
calling from the ExternalProject code
Re: [CMake] External_Project_Add() and custom build configurations ?
On 7 July 2011 15:15, David Cole david.c...@kitware.com wrote: I'm sure that what you want to do is possible. I'm also sure that it's a huge effort to get it to work with all CMake generators. It will also be difficult to write a good test of the functionality. Furthermore, I view it as largely unnecessary work... ...because a full file-system-level clean of deleting the entire build tree, followed by a quick configure with CMake of the top level project, followed by a regular build has largely the same net result with negligible difference in total build time. If the difference in total build time is non-negligible, and really annoying to somebody, then this huge effort may well be worth it to them, at that point in time. Right now, I'm not convinced the extra effort and extra complications in the code are worthwhile additions to CMake. I understand where you're coming from on the resources front. There would obviously be some effort required to get this to work properly. I'm not convinced it is such a huge amount of work as you're suggesting, but then I don't know the source code as well as you do :-) From my point of view this does make using ExternalProject_Add() a less interesting option. Yes, I can tell users that they have to manually delete a sub-tree and re-run the configure step and then rebuild the top level project. But realistically that isn't going to fly for the majority of users, especially the Visual Studio users. They just want to select build, or rebuild and expect it to work. If I get some spare time I will investigate further what would be involved. -- Glenn ___ 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] External_Project_Add() and custom build configurations ?
This had me stumped for a while until I came across the -P command line
option to cmake. I have now added a build command to my external project
like so:
ExternalProject_Add(external_proj
PREFIX${CMAKE_BINARY_DIR}/external_proj
SOURCE_DIR${CMAKE_SOURCE_DIR}/external_proj
CMAKE_ARGS-DCMAKE_BUILD_TYPE:STRING=Release
-DMETAGS_DIR=${METASIM_INSTALL_DIR}
BUILD_COMMAND${CMAKE_COMMAND}
-DBUILD_TARGET:STRING=external_proj
-DBUILD_CONFIG:STRING=${CMAKE_CFG_INTDIR}
-P ${CMAKE_SOURCE_DIR}/ExProjectBuild.cmake
INSTALL_COMMAND
)
And then the ExProjectBuild.cmake file invokes cmake --build with the build
config changed appropriately when necessary:
message(In ExternalProjectBuild:)
message(BUILD_TARGET=${BUILD_TARGET})
message(BUILD_CONFIG=${BUILD_CONFIG})
message(CMAKE_BINARY_DIR=${CMAKE_BINARY_DIR})
set (standardConfigsRelease Debug RelWithDebInfo MinSizeRel)
# map each build config in extraConfigs to the item in the same position in
extraConfigsMap
set (extraConfigsReleaseNoHidebugDebugPthreads
DebugOptimised)
set (extraConfigsMapReleaseDebugDebug)
list(FIND standardConfigs ${BUILD_CONFIG} pos)
if (pos LESS 0)
list(FIND extraConfigs ${BUILD_CONFIG} pos)
if (pos LESS 0)
message(FATAL_ERROR Unknown build config: ${BUILD_CONFIG})
endif()
list(GET extraConfigsMap ${pos} BUILD_CONFIG)
message( MAPPED CONFIG: ${BUILD_CONFIG})
endif()
execute_process(
COMMAND ${CMAKE_COMMAND}
--build ${CMAKE_BINARY_DIR} --config ${BUILD_CONFIG}
)
Is that what you meant when you suggested using a custom BUILD_COMMAND ? Or
was there a simpler way to do it ?
Also, I note that when I clean the external project in Visual Studio it
doesn't really clean it (i.e. after the clean a build still thinks there is
nothing to do). And the clean doesn't invoke my ExProjectBuild script.
If I manually run cmake --build externalProjectDir --target clean from the
command line then it does clean the project properly. Is
ExternalProject_Add() missing some functionality here, or have I
misunderstood something ?
--
Glenn
On 1 July 2011 18:01, David Cole david.c...@kitware.com wrote:
On Fri, Jul 1, 2011 at 7:23 AM, Glenn Coombs glenn.coo...@gmail.comwrote:
I have just started using some externally supplied cmake projects in my
cmake project. To do this I added these lines to my top level
CMakeLists.txt file:
include(ExternalProject)
ExternalProject_Add(external_proj
PREFIX${CMAKE_BINARY_DIR}/external_proj
SOURCE_DIR${CMAKE_SOURCE_DIR}/external/proj/dir
CMAKE_ARGS-DCMAKE_BUILD_TYPE:STRING=Release
-DMETAGS_DIR=${CMAKE_BINARY_DIR}/meta_install
INSTALL_COMMAND
)
And that worked very well. Inside Visual Studio when I build my project
it automatically runs the cmake configure step for the external projects and
builds them as well. The problem I have just discovered is when using a
build configuration other than the default ones. I can build Debug and
Release configurations fine. My project also has a DebugOptimised
configuration but the external projects don't. When I try to build my
project it fails to build the external projects. I used build_command() to
see what commands would be used to build each configuration and I can see
the cause of the problem:
Debug: VCExpress.exe myProj.sln /build Debug /project
external_proj
DebugOptimised: VCExpress.exe myProj.sln /build DebugOptimised /project
external_proj
Is there a way to tell cmake how to map my build configurations onto those
that an external project has ? In this case I would like to build the
external project as Debug when I am building my project as DebugOptimised.
--
Glenn
___
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
With Visual Studio builds, external projects get built (by default) with
the same configuration as the outer project. If you want a different
configuration built, then you will have to customize the BUILD_COMMAND. You
can look in the source for ExternalProject.cmake to see how the default
BUILD_COMMAND is constructed and go from there.
HTH,
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
Re: [CMake] Remove custom targets
If you can modify the subdirectory cmakefiles then maybe you could protect the declaration of the uninstall target like this: if (NOT TARGET uninstall) add_custom_target(uninstall ...) endif() That way if the top level cmakefile declares an uninstall target it should prevent the subdirectory versions from being declared. -- Glenn On 4 July 2011 17:33, Joe H expipipl...@gmail.com wrote: Hi all! I have a project, which pulls in a bunch of sub-projects, using add_subdirectory. The problem is that these projects all create a custom target called uninstall. Obviously, when these projects are pulled together, the uninstall targets clash. An ideal solution would be to ignore the uninstall targets in the subdirectories, and just pay attention to the one at the root. Is this at all possible? Thanks! ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] External_Project_Add() and custom build configurations ?
I have just started using some externally supplied cmake projects in my
cmake project. To do this I added these lines to my top level
CMakeLists.txt file:
include(ExternalProject)
ExternalProject_Add(external_proj
PREFIX${CMAKE_BINARY_DIR}/external_proj
SOURCE_DIR${CMAKE_SOURCE_DIR}/external/proj/dir
CMAKE_ARGS-DCMAKE_BUILD_TYPE:STRING=Release
-DMETAGS_DIR=${CMAKE_BINARY_DIR}/meta_install
INSTALL_COMMAND
)
And that worked very well. Inside Visual Studio when I build my project it
automatically runs the cmake configure step for the external projects and
builds them as well. The problem I have just discovered is when using a
build configuration other than the default ones. I can build Debug and
Release configurations fine. My project also has a DebugOptimised
configuration but the external projects don't. When I try to build my
project it fails to build the external projects. I used build_command() to
see what commands would be used to build each configuration and I can see
the cause of the problem:
Debug: VCExpress.exe myProj.sln /build Debug /project
external_proj
DebugOptimised: VCExpress.exe myProj.sln /build DebugOptimised /project
external_proj
Is there a way to tell cmake how to map my build configurations onto those
that an external project has ? In this case I would like to build the
external project as Debug when I am building my project as DebugOptimised.
--
Glenn
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Appending to the LINK_FLAGS target property ?
For variables like CMAKE_C_FLAGS one can append to them like this:
set(CMAKE_C_FLAGS ${CMAKE_CFLAGS} -some_option)
For target properties like LINK_FLAGS I was using this command:
set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS
/NODEFAULTLIB:LIBCMT)
to do the append. However, when I append a second time:
set_property(TARGET myDLL APPEND PROPERTY LINK_FLAGS
/INCLUDE:_InitLibrary)
then it breaks because the string that Visual Studio sees contains a
semicolon in between the 2 options. I can work round this by writing my
append like this:
get_property(link_flags TARGET myDLL PROPERTY LINK_FLAGS)
set(link_flags ${link_flags} /INCLUDE:_InitLibrary)
set_target_properties(myDLL PROPERTIES LINK_FLAGS ${link_flags})
but that is a bit verbose for my liking. I understand that the semicolons
are how cmake separates list items from one another but shouldn't cmake
automatically stringify the list (by replacing semicolons with spaces)
before passing it through to the generator code ? The same problem will
occur for any of the XXX_FLAGS properties like COMPILE_FLAGS that are passed
through unchanged to the makefile or Visual Studio project file.
Is it worth filing a feature request to ask for cmake to stringify lists for
the appropriate variables ? Or is there a good reason why cmake can't or
shouldn't implement this behaviour ?
--
Glenn
___
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 set a preprocessor define for all build configurations except one ?
Thanks for the clarification - I have a much clearer understanding now. -- Glenn On 18 June 2011 14:30, Michael Hertling mhertl...@online.de wrote: COMPILE_DEFINITIONS is used *always*, i.e. for every generator in every configuration, and COMPILE_DEFINITIONS_CONFIG is used *additionally* in configuration CONFIG, so it can not be used to remove definitions added to COMPILE_DEFINITIONS; in fact, these properties are completely independent from each other. Would that approach have worked for the multi-config generators ? Do they use the concatenation of COMPILE_DEFINITIONS and COMPILE_DEFINITIONS_active config ? All generators use this concatenation, and that's the reason why you must handle NOT CMAKE_CONFIGURATION_TYPES AND NOT CMAKE_BUILD_TYPE separately one way or another if the GEN_OUTFILES definition is to be enabled always except for the RELEASENOOUTFILES 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 ___ 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] Dependencies and libraries..How does it work?
If the library you are trying to build is one that is totally under your
control then really it should be a subdirectory of your MY_APP source tree
so that you can call add_subdirectory() on it. If MY_LIB is shared across
multiple projects then you can always arrange for it to appear as a
subdirectory of MY_APP when you check the code out from your revision
control system. We do this with cvs modules but I'm sure that git and
mercurial have similar capabilities.
If you still can't get MY_LIB to be a subdirectory of MY_APP then you might
be able to build it using add_directory with the second argument:
add_subdirectory(${LIB_SRC} mylib)
I haven't used add_subdirectory like that myself but it appears from the
docs that it might do what you want.
--
Glenn
On 17 June 2011 11:03, David Springate david.spring...@gmail.com wrote:
Thanks for that helpful summary Jacob - and indeed you are correct I was
getting very confused (overtime is getting to me!) and forgetting of course
cmake doesn't actually *build* the product - but I do want it to generate
the makefiles that the project is dependant on, as you outlined.
Now, my setup is basically as you outlined in your example - except that
the library is not located in a subdirectory of the main_tree.
I have an environment variable (let's call it LIB_SRC) that contains the
path to the root of my library source.
How can I inform the app's CMakeLists.txt file that the lib source is
located at LIB_SRC so that the 'target_link_libraries(MY_APP MY_LIB)' call
doesn't fail?
I'm guessing that add_subdirectory isn't ideal in this case..
___
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 set a preprocessor define for all build configurations except one ?
On 13 June 2011 02:53, Michael Hertling mhertl...@online.de wrote:
AFAIK, there's no other approach to take account of single- and multi-
config generators at the same time for this purpose, but perhaps, you
could design the loop a bit smarter:
FOREACH(i IN LISTS CMAKE_CONFIGURATION_TYPES ITEMS ${CMAKE_BUILD_TYPE})
STRING(TOUPPER ${i} j)
IF(NOT j MATCHES RELEASENOOUTFILES)
SET_PROPERTY(...)
ENDIF()
ENDFOREACH()
I wasn't aware of that syntax of the foreach command - that does tidy it up
a bit.
and rely on the assumption that
(1) the FLAGS are mentioned after the COMPILE_DEFINITIONS, and
(2) the last -D/-U argument in the command line will take effect.
At least, GCC guarantees that (2) holds, but I have not found any
explicit assertion in the documentation that CMake guarantees (1),
though it seems to work in this way.
I'm not overly keen on that solution.
BTW, is an inverted logic an option, i.e. a preprocessor definition
NO_GEN_OUTFILES enabled for the RELEASENOOUTFILES configuration only?
This would be much easier and fit that configuration's intent better.
The default is to generate outfiles and the code is littered with blocks
like this:
#ifdef GEN_OUTFILES
...
#endif
Changing them to #ifndef NO_GEN_OUTFILES would work but the double negative
makes the code less readable. I'll stick with what I already have for the
moment, but add your modification to the foreach loop.
Thanks,
--
Glenn
___
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 set a preprocessor define for all build configurations except one ?
On 16 June 2011 15:45, Michael Hertling mhertl...@online.de wrote: IMO, the default should not need to be explicitly enabled but the exception, and readability - though important - is subordinate to functionality, but probably, this is a matter of personal taste. However, if you stick with the GEN_OUTFILES definition, be aware of the single-config generator with an empty build type. In that case, only the COMPILE_DEFINITIONS property is in effect, so you must add the GEN_OUTFILES definition to it, but with a non-empty build type, this config-less property is in effect, too, so you must *not* add GEN_OUTFILE to it. Thus, you need to differentiate these cases: IF(CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE) FOREACH(... IN LISTS ... ITEMS ...) # Set COMPILE_DEFINITIONS_CONFIG. ENDFOREACH() ELSE() # Set COMPILE_DEFINITIONS. ENDIF() Clearly, this cuts down the elegance of the FOREACH loop, while the inverted approach with NO_GEN_OUTFILES would be unalteredly smooth. Luckily I already have this in my CMakeLists.txt: if (NOT CMAKE_CONFIGURATION_TYPES AND NOT CMAKE_BUILD_TYPE) set(CMAKE_BUILD_TYPE Release) endif() to force the default build to use the Release configuration. Otherwise I would have fallen foul of the case you are suggesting. Is COMPILE_DEFINITIONS only used in single-config generators if CMAKE_BUILD_TYPE is not set ? That might explain why my initial attempts to do this failed. I had added GEN_OUTFILES to COMPILE_DEFINITIONS thinking this would apply to all configs. And then when I tried to remove that option from COMPILE_DEFINITIONS_RELEASENOOUTFILES it failed to have the desired effect. Would that approach have worked for the multi-config generators ? Do they use the concatenation of COMPILE_DEFINITIONS and COMPILE_DEFINITIONS_active config ? -- Glenn ___ 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] New build configuration based off existing configuration?
This is what I do:
# Add configuration for ReleaseNoOutfiles builds based on the release
configuration
#
=
set(CMAKE_C_FLAGS_RELEASENOOUTFILES
${CMAKE_C_FLAGS_RELEASE}CACHE STRING Flags used by the
compiler during ReleaseNoOutfiles builds)
set(CMAKE_CXX_FLAGS_RELEASENOOUTFILES
${CMAKE_CXX_FLAGS_RELEASE}CACHE STRING Flags used by the
compiler during ReleaseNoOutfiles builds)
set(CMAKE_EXE_LINKER_FLAGS_RELEASENOOUTFILES
${CMAKE_EXE_LINKER_FLAGS_RELEASE}CACHE STRING Flags used by the
linker for executables during ReleaseNoOutfiles builds)
set(CMAKE_SHARED_LINKER_FLAGS_RELEASENOOUTFILES
${CMAKE_SHARED_LINKER_FLAGS_RELEASE}CACHE STRING Flags used by the
linker for shared libraries during ReleaseNoOutfiles builds)
set(CMAKE_MODULE_LINKER_FLAGS_RELEASENOOUTFILES
${CMAKE_MODULE_LINKER_FLAGS_RELEASE}CACHE STRING Flags used by the
linker for loadable modules during ReleaseNoOutfiles builds)
mark_as_advanced(
CMAKE_C_FLAGS_RELEASENOOUTFILES
CMAKE_CXX_FLAGS_RELEASENOOUTFILES
CMAKE_EXE_LINKER_FLAGS_RELEASENOOUTFILES
CMAKE_SHARED_LINKER_FLAGS_RELEASENOOUTFILES
CMAKE_MODULE_LINKER_FLAGS_RELEASENOOUTFILES
)
# This variable is only set for multi-config IDE generators like MSVC
if(CMAKE_CONFIGURATION_TYPES)
list(APPEND CMAKE_CONFIGURATION_TYPES ReleaseNoOutfiles)
list(REMOVE_DUPLICATES CMAKE_CONFIGURATION_TYPES)
set(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES}
CACHE STRING Semicolon separated list of supported configuration
types [Debug|Release|MinSizeRel|RelWithDebInfo|ReleaseNoOutfiles]
FORCE)
endif()
I don't know if I have set *all* the relevant variables but it seems to work
for me so far. It would definitely be nicer if cmake had a built-in command
to create new build configurations based upon an existing one. Something
like:
create_build_config(ReleaseNoOutfiles Release)
--
Glenn
On 6 June 2011 04:50, Ivan Neeson zzy...@gmail.com wrote:
Is it possible to easily add a new build configuration that is identical to
an existing configuration (for example MinSizeRel2 which has exactly the
same settings as MinSizeRel)?
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Embedding one project inside a second
A simple set of CMAKE_C_FLAGS or CMAKE_CXX_FLAGS will set the value for the
current directory and below:
set(CMAKE_C_FLAGS${CMAKE_C_FLAGS} -m32)
Any add_directory() commands after the above line will inherit the -m32
flag.
--
Glenn
On 5 June 2011 20:36, Richard Offer rich...@whitequeen.com wrote:
I have two distinct projects - A and B - each has its own subversion
repository etc - they are quite independent.
Project A is nw and needs to be built 32bit and itself comprises both
in-house and third party code. The third party code is built using
ExternalProject_Add()
Project B is built 64bit - this is our current project so everyone is
already building that.
Both use Cmake :-)
I'm at the stage where Project B needs access to Projects A's message
definitions - so I thought the easiest way is to embed it via subversion.
How can Project A recognize that its being built as a component of Project
B ? ( I can then only build certain targets in Project A). Project A still
needs to be able to do its normal build outside of Project B. I'm guessing
this could be as simple as SET'ing a variable :-)
However, while I only really need one part of Project A inside Project B,
for the team's convenience I'd really like for them to be able to build
the 32bit Project A components at the same time they are building all of
Project B. (saves having to have multiple virtual environments running for
every task)
There doesn't seem to be an easy way to say here are the FLAGS (-m32) for
this directory and below. Or have I missed something?
And how do I handle building the same EXTERNAL_PROJECT() multiple times
with different flags - it complains that the source directory is already
present. And then correctly reference the 32/64 versions of the libraries
when adding LINK targets ?
Thanks
Richard.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 32-bit mode on 64-bit machine
I do exactly that for my project using these lines:
if(UNIX)
# only build 32-bit binaries
add_definitions(-m32)
set(CMAKE_EXE_LINKER_FLAGS${CMAKE_EXE_LINKER_FLAGS}
-m32)
set(CMAKE_SHARED_LIBRARY_C_FLAGS${CMAKE_SHARED_LIBRARY_C_FLAGS}
-m32)
set(CMAKE_SHARED_LIBRARY_CXX_FLAGS
${CMAKE_SHARED_LIBRARY_CXX_FLAGS} -m32)
endif()
I do it unconditionally but you could easily add an option variable to turn
this behaviour on or off accordingly.
--
Glenn
On 26 May 2011 17:54, Sara Rolfe smro...@u.washington.edu wrote:
Hello,
I'd like to force a 64-bit machine to build a 32-bit program. Can I
control this using CMake?
Thanks,
Sara
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Which variable stores all (sub) directories added sofar?
I think that you can use an environment variable rather than a normal
variable to bypass the normal scoping rules. So:
set(ENV{foo} bar)
will I think allow other CMakeFiles to read it using:
$ENV{foo}
regardless of the sub-directory level. I haven't tried using this so it may
not work but I think it should do what you want.
--
Glenn
On 19 May 2011 13:05, Eric Noulard eric.noul...@gmail.com wrote:
2011/5/19 J.S. van Bethlehem j.s.van.bethle...@astro.rug.nl:
Hello Eike,
Thanks a lot for your reply. I have actually been thinking in the same
direction. I have one problem though: how can you make a truly global
variable in CMake? Whenever you do something to a variable in a directory
that is added using add_subdirectory(), those changes don't propagate to
the
current directory
(well, one could use the PARENT_SCOPE option to set() in the
sub-directory,
but then I won't be able to test that sub-directory seperately because
then
CMake will err that there is no such scope)
How do you deal with this?
I think, that's why Eike uses **property** and not variable.
Property may be at GLOBAL scope:
set_property(GLOBAL|
DIRECTORY [dir] |
TARGET[target1 [target2 ...]] |
SOURCE[src1 [src2 ...]] |
TEST [test1 [test2 ...]] |
CACHE [entry1 [entry2 ...]]
[APPEND]
PROPERTY name [value1 [value2 ...]])
Set one property on zero or more objects of a scope. The first
argument determines the scope in which the property is set. It must
be one of the following:
GLOBAL scope is unique and does not accept a name.
...
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
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] Parameters of functions
I think you probably wanted to write and call your function like this:
FUNCTION(build var)
MESSAGE(STATUS var: ${var})
ENDFUNCTION(build)
SET(var red blue yellow green)
build(${var})
That prints out as you would expect:
-- var: red;blue;yellow;green
--
Glenn
On 12 May 2011 07:27, Rolf Eike Beer e...@sf-mail.de wrote:
This is funny:
FUNCTION(build var)
MESSAGE(STATUS var: ${${var}})
ENDFUNCTION(build)
SET(var red blue yellow green)
build(var)
Output:
-- var: var
SET(varX red blue yellow green)
build(varX)
Output:
-- var: redblueyellowgreen
No, it must be that way. Inside build() var is defined as the variable
that is defined in the interface. build() has no way to see the variable
outside it because it can only find the inner name. It could reference
it's value if you had passed the value or it could reference the variable
by name if it would not be hidden by your interface variable.
int a = 2;
int build(int a)
{
return a;
}
int b = build(42);
b will be 42.
Eike
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] How to add a target link library, but only for a custom configuration ?
On 6 May 2011 01:12, Michael Hertling mhertl...@online.de wrote:
Yes, absolutely. Although setups with libraries which are needed in some
configurations only are quite rare, AFAIK, your case shows that this may
well happen. ;-) Possible - and more appropriate - solutions could be:
- New target properties, say, EXTRA_LINK_LIBRARIES[_CONFIG] that
are just added to the respective targets' link command lines.
- Permission of empty or absent IMPORTED_LOCATION[_CONFIG]
properties; with these, you might just have said
ADD_LIBRARY(pthreads SHARED IMPORTED)
SET_TARGET_PROPERTIES(pthreads PROPERTIES
IMPORTED_LOCATION_DEBUGPTHREADS ${PTHREADS_LIBRARIES})
TARGET_LINK_LIBRARIES(myLib pthreads)
and that's it. Perhaps, this would be worth a feature request.
Regards,
Michael
I've filed a report on the bug tracker:
http://public.kitware.com/Bug/view.php?id=12124
so hopefully something may get done about it sometime.
--
Glenn
___
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 add a target link library, but only for a custom configuration ?
Thanks for that link Michael. It doesn't please me, but I can confirm that
it does work :-) It's a nice hack around a deficiency in cmake. I ended up
using this code:
# First create a dummy library to hang the pthreads
# dependency on via the IMPORTED_LINK_INTERFACE_LIBRARIES property.
file(WRITE ${CMAKE_CURRENT_BINARY_DIR}/pthreads_dummy.c )
add_library(pthreads_dummy STATIC
${CMAKE_CURRENT_BINARY_DIR}/pthreads_dummy.c)
# make sure the dummy library gets built
add_dependencies(systemc pthreads_dummy)
# export the dummy library so we can include it as an imported target
export(TARGETS pthreads_dummy NAMESPACE imported FILE
importedpthreads_dummy.cmake)
include(${CMAKE_CURRENT_BINARY_DIR}/importedpthreads_dummy.cmake)
# use the imported target to add pthread dependency for the DEBUGPTHREADS
config
set_target_properties(importedpthreads_dummy
PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUGPTHREADS ${PTHREADS_LIBRARIES})
target_link_libraries(myLib importedpthreads_dummy)
which is a lot of extra lines when all I really want is something like this:
target_link_libraries(myLib CONFIG DebugPthreads pthreads)
--
Glenn
On 26 April 2011 15:15, Michael Hertling mhertl...@online.de wrote:
There is a possibility with an intermediate empty static library which
gets reimported into the project and equipped with the target property
IMPORTED_LINK_INTERFACE_LIBRARIES_CONFIG, but I don't know if that
approach will please you... ;) Anyway, see [1] for the details.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg34680.html
PS: Empty static libraries aren't allowed on Windows; use
FILE(WRITE ${CMAKE_BINARY_DIR}/dummy.c )
ADD_LIBRARY(dummy STATIC dummy.c)
to satisfy the Visual Studio tools.
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] How to add a target link library, but only for a custom configuration ?
I am using cmake 2.8.2 and I have added a custom configuration to my project
like this:
# Add configuration for debug pthreads builds based on the debug
configuration
#
=
set(CMAKE_C_FLAGS_DEBUGPTHREADS${CMAKE_C_FLAGS_DEBUG}
CACHE STRING Flags used by the compiler during DebugPthreads
builds)
set(CMAKE_CXX_FLAGS_DEBUGPTHREADS${CMAKE_CXX_FLAGS_DEBUG}
CACHE STRING Flags used by the compiler during DebugPthreads
builds)
set(CMAKE_EXE_LINKER_FLAGS_DEBUGPTHREADS
${CMAKE_EXE_LINKER_FLAGS_DEBUG}CACHE STRING Flags used by the
linker for executables during DebugPthreads builds)
set(CMAKE_SHARED_LINKER_FLAGS_DEBUGPTHREADS
${CMAKE_SHARED_LINKER_FLAGS_DEBUG}CACHE STRING Flags used by the linker
for shared libraries during DebugPthreads builds)
set(CMAKE_MODULE_LINKER_FLAGS_DEBUGPTHREADS
${CMAKE_MODULE_LINKER_FLAGS_DEBUG}CACHE STRING Flags used by the linker
for loadable modules during DebugPthreads builds)
# add in the details specific to this configuration
set(CMAKE_C_FLAGS_DEBUGPTHREADS${CMAKE_C_FLAGS_DEBUGPTHREADS}
/DSC_USE_PTHREADS)
set(CMAKE_CXX_FLAGS_DEBUGPTHREADS${CMAKE_CXX_FLAGS_DEBUGPTHREADS}
/DSC_USE_PTHREADS)
mark_as_advanced(
CMAKE_C_FLAGS_DEBUGPTHREADS
CMAKE_CXX_FLAGS_DEBUGPTHREADS
CMAKE_EXE_LINKER_FLAGS_DEBUGPTHREADS
CMAKE_SHARED_LINKER_FLAGS_DEBUGPTHREADS
CMAKE_MODULE_LINKER_FLAGS_DEBUGPTHREADS
)
# This variable is only set for multi-config IDE generators like MSVC
if(CMAKE_CONFIGURATION_TYPES)
list(APPEND CMAKE_CONFIGURATION_TYPES DebugPthreads)
list(REMOVE_DUPLICATES CMAKE_CONFIGURATION_TYPES)
set(CMAKE_CONFIGURATION_TYPES ${CMAKE_CONFIGURATION_TYPES}
CACHE STRING Semicolon separated list of supported configuration
types [Debug|Release|MinSizeRel|RelWithDebInfo|DebugPthreads]
FORCE)
endif()
This works and inside Visual Studio 2008 I now get a DebugPthreads
configuration in addition to the normal 4. As part of my project I build a
library which I now want to add a target dependency for, but only in the
DebugPthreads configuration. Something like this:
add_library(myLib ${sources})
if (activeConfig is DebugPthreads)
target_link_libraries(myLib ${FULL_PATH_TO_PTHREADS_LIB})
endif()
There doesn't seem to be a way to specify target_link_libraries() for
selected configurations. I see that it can be specified for all debug or
all release configurations but that isn't what I need. The Debug and
Release versions of myLib do not depend on the pthreads library but the
DebugPthreads version of myLib does.
Googling for answers has revealed several people with the similar problems
but no clear answers. I have seen recommendations to use an imported
library and the IMPORTED_LOCATION and IMPORTED_CONFIGURATIONS properties. I
tried this code:
add_library(my_pthreads STATIC IMPORTED)
set_target_properties(my_pthreads PROPERTIES
IMPORTED_CONFIGURATIONSDebugPthreads
IMPORTED_LOCATION_DEBUGPTHREADS${PTHREADS_LIBRARIES}
)
target_link_libraries(myLib my_pthreads)
but that includes the pthreads library as a target dependency in all
configurations. If I omit the IMPORTED_CONFIGURATIONS options then I get
the correct result for the DebugPthreads configuration but all other
configurations are trying to find a library called my_pthreads-NOTFOUND.
Is there a way to do what I want in cmake ?
--
Glenn
___
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
