Re: [CMake] Cannot add target-level dependencies to non-existent target

2015-07-03 Thread Glenn Coombs
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

2015-07-03 Thread Glenn Coombs
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

2015-06-30 Thread Glenn Coombs
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

2015-06-12 Thread Glenn Coombs
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 ?

2014-11-14 Thread Glenn Coombs
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 ?

2014-11-14 Thread Glenn Coombs
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 ?

2014-09-24 Thread Glenn Coombs
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 ?

2014-09-23 Thread Glenn Coombs
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

2014-08-14 Thread Glenn Coombs
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

2014-08-07 Thread Glenn Coombs
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 ?

2014-08-07 Thread Glenn Coombs
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

2014-08-03 Thread Glenn Coombs
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 ?

2014-08-02 Thread Glenn Coombs
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

2014-07-29 Thread Glenn Coombs
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 ?

2014-07-23 Thread Glenn Coombs
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 ?

2014-07-21 Thread Glenn Coombs
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 ?

2014-07-19 Thread Glenn Coombs
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 ?

2014-06-28 Thread Glenn Coombs
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 ?

2014-06-25 Thread Glenn Coombs
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 ?

2014-06-24 Thread 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).

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 ?

2014-05-01 Thread Glenn Coombs
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 ?

2014-05-01 Thread Glenn Coombs
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 ?

2014-05-01 Thread Glenn Coombs
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 ?

2014-05-01 Thread Glenn Coombs
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 ?

2014-04-23 Thread Glenn Coombs
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

2013-07-31 Thread Glenn Coombs
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

2013-05-07 Thread Glenn Coombs
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

2013-05-05 Thread Glenn Coombs
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

2013-05-01 Thread Glenn Coombs
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

2013-04-29 Thread Glenn Coombs
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

2013-04-28 Thread Glenn Coombs
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

2013-04-26 Thread Glenn Coombs
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

2013-04-25 Thread Glenn Coombs
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...

2012-11-09 Thread Glenn Coombs
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 ?

2012-10-03 Thread Glenn Coombs
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 ?

2012-10-03 Thread Glenn Coombs
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

2012-09-20 Thread Glenn Coombs
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

2012-09-17 Thread Glenn Coombs
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 ?

2012-09-03 Thread Glenn Coombs
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 ?

2012-08-28 Thread Glenn Coombs
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

2012-02-02 Thread Glenn Coombs
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] Compile flag issues and VS Express

2012-01-31 Thread Glenn Coombs
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

Re: [CMake] cmake -E copy with file permission changes

2012-01-31 Thread Glenn Coombs
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

2011-10-11 Thread Glenn Coombs
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

2011-10-11 Thread Glenn Coombs
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

2011-10-11 Thread Glenn Coombs
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

2011-10-10 Thread Glenn Coombs
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?

2011-09-08 Thread Glenn Coombs
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?

2011-09-08 Thread Glenn Coombs
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?

2011-09-07 Thread Glenn Coombs
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

2011-09-07 Thread Glenn Coombs
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

2011-08-16 Thread Glenn Coombs
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

2011-08-16 Thread Glenn Coombs
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

2011-08-13 Thread Glenn Coombs
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

2011-08-13 Thread Glenn Coombs
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

2011-08-11 Thread Glenn Coombs
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

2011-08-11 Thread Glenn Coombs
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?

2011-08-11 Thread Glenn Coombs
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?

2011-08-11 Thread Glenn Coombs
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...

2011-08-09 Thread Glenn Coombs
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

2011-08-07 Thread Glenn Coombs
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

2011-08-04 Thread Glenn Coombs
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

2011-08-04 Thread Glenn Coombs
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

2011-08-03 Thread Glenn Coombs
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

2011-08-03 Thread Glenn Coombs
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

2011-08-02 Thread Glenn Coombs
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...

2011-07-30 Thread Glenn Coombs
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

2011-07-27 Thread Glenn Coombs
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

2011-07-26 Thread Glenn Coombs
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

2011-07-22 Thread Glenn Coombs
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 ?

2011-07-22 Thread Glenn Coombs
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 ?

2011-07-07 Thread Glenn Coombs
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 ?

2011-07-07 Thread Glenn Coombs
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 ?

2011-07-05 Thread Glenn Coombs
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

2011-07-04 Thread Glenn Coombs
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 ?

2011-07-01 Thread Glenn Coombs
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 ?

2011-06-27 Thread Glenn Coombs
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 ?

2011-06-20 Thread Glenn Coombs
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?

2011-06-17 Thread Glenn Coombs
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 ?

2011-06-16 Thread Glenn Coombs
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 ?

2011-06-16 Thread Glenn Coombs
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] How to set a preprocessor define for all build configurations except one ?

2011-06-12 Thread Glenn Coombs
I don't think CMAKE_BUILD_TYPE is used by the Visual Studio generators so
that would only work for Makefile based build systems.  I need a solution
that works for both Visual Studio on Windows and Makefiles on Linux.

On 12 June 2011 21:32, Raphael Kubo da Costa kub...@gmail.com wrote:

 Glenn Coombs glenn.coo...@gmail.com
 writes:

  Is there a more elegant solution that I am missing ?  Ideally something
  like:
 
  add_definitions(CONFIG=Debug;Release;RelWithDebInfo;MinSizeRel
  -DGEN_OUTFILES)
 
  which I know doesn't exist but I really wish it did :-)

 Isn't it OK to just do something like:

  if (NOT ${CMAKE_BUILD_TYPE} STREQUAL ReleaseNoOutFiles)
add_definitions(-DGEN_OUTFILES)
  endif ()

 ___
 Powered by www.kitware.com

 Visit other Kitware open-source projects at
 http://www.kitware.com/opensource/opensource.html

 Please keep messages on-topic and check 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 set a preprocessor define for all build configurations except one ?

2011-06-07 Thread Glenn Coombs
I want to have a preprocessor symbol (GEN_OUTFILES) defined for all build
configurations except one (ReleaseNoOutfiles).  Before I added the
ReleaseNoOutfiles configuration I just had this line in my top level
CMakeLists.txt:

add_definitions(-DGEN_OUTFILES)

but now I have to have this complicated mess instead:

# Add preprocessor definition for GEN_OUTFILES to all project configurations
except ReleaseNoOutfiles
if (CMAKE_CONFIGURATION_TYPES)
string(TOUPPER ${CMAKE_CONFIGURATION_TYPES}
CMAKE_CONFIGURATION_TYPES_UPPER)
else()
string(TOUPPER ${CMAKE_BUILD_TYPE}
CMAKE_CONFIGURATION_TYPES_UPPER)
endif()

foreach(config ${CMAKE_CONFIGURATION_TYPES_UPPER})
if (NOT (${config} MATCHES RELEASENOOUTFILES))
set_property(DIRECTORY APPEND PROPERTY
COMPILE_DEFINITIONS_${config} GEN_OUTFILES)
endif()
endforeach()

Is there a more elegant solution that I am missing ?  Ideally something
like:

add_definitions(CONFIG=Debug;Release;RelWithDebInfo;MinSizeRel
-DGEN_OUTFILES)

which I know doesn't exist but I really wish it did :-)

Initially I didn't have the if (CMAKE_CONFIGURATION_TYPES) check and it
didn't work on linux.  Why is CMAKE_CONFIGURATION_TYPES empty for linux
targets ?  I know that multiple build configs are not supported in the same
tree like they are under Visual Studio but you can configure multiple build
directories with CMAKE_BUILD_TYPE set to each value in
CMAKE_CONFIGURATION_TYPES.  The code in CMakeLists.txt files would be more
platform agnostic and easier to read if one could iterate over
CMAKE_CONFIGURATION_TYPES on linux to set configuration specific variables
like COMPILE_DEFINITIONS_XXX.

--
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?

2011-06-06 Thread Glenn Coombs
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

2011-06-06 Thread Glenn Coombs
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

2011-05-26 Thread Glenn Coombs
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?

2011-05-19 Thread Glenn Coombs
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

2011-05-12 Thread Glenn Coombs
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 ?

2011-05-06 Thread Glenn Coombs
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 ?

2011-05-05 Thread Glenn Coombs
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 ?

2011-04-26 Thread Glenn Coombs
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