[CMake] How to add a target link library, but only for a custom configuration ?

[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_CONFIGURATIONS"DebugPthreads"
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

Re: [CMake] How to add a target link library, but only for a custom configuration ?

[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  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_, 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

Re: [CMake] How to add a target link library, but only for a custom configuration ?

[Glenn Coombs]

On 6 May 2011 01:12, Michael Hertling  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[_] that
>  are just added to the respective targets' link command lines.
> - Permission of empty or absent IMPORTED_LOCATION[_]
>  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] Parameters of functions

[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  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] Parameters of functions

[Glenn Coombs]

If you really wanted to pass the name of the variable in rather than the
value, then as Rolf says the behaviour you get is as expected.  The only way
round that would be to rename var in the function to something guaranteed
not to be the name of a variable that you ever tried to pass in.

Or you could use a macro instead:

MACRO(buildm var)
   MESSAGE(STATUS "var: " ${${var}})
ENDMACRO()

SET(var red blue yellow green)
buildm(var)

-- var: redblueyellowgreen

--
Glenn


On 12 May 2011 13:21, Micha Renner  wrote:

> Am Donnerstag, den 12.05.2011, 11:50 +0100 schrieb 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
> >
> Both versions are possible.
> My point was, that in the case I described, the name of the parameter of
> the function may not be the same as the name of variable the function is
> called.
>
> With your version you don't have this problem.
> Thanks.
>
> Micha
>
>
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
___
Powered by www.kitware.com

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

Please keep messages on-topic and check the CMake 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?

[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  wrote:

> 2011/5/19 J.S. van Bethlehem :
> >
> > 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(   DIRECTORY [dir]   |
>   TARGET[target1 [target2 ...]] |
>   SOURCE[src1 [src2 ...]]   |
>   TEST  [test1 [test2 ...]] |
>   CACHE [entry1 [entry2 ...]]>
>  [APPEND]
>  PROPERTY  [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] 32-bit mode on 64-bit machine

[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  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] New build configuration based off existing configuration?

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

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

[CMake] How to set a preprocessor define for all build configurations except one ?

[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] How to set a preprocessor define for all build configurations except one ?

[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  wrote:

> Glenn Coombs 
> 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

Re: [CMake] How to set a preprocessor define for all build configurations except one ?

[Glenn Coombs]

On 13 June 2011 02:53, Michael Hertling  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 ?

[Glenn Coombs]

On 16 June 2011 15:45, Michael Hertling  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_.
>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_ ?

--
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] Dependencies and libraries..How does it work?

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

[Glenn Coombs]

Thanks for the clarification - I have a much clearer understanding now.

--
Glenn

On 18 June 2011 14:30, Michael Hertling  wrote:

>
> COMPILE_DEFINITIONS is used *always*, i.e. for every generator in every
> configuration, and COMPILE_DEFINITIONS_ is used *additionally*
> in configuration , 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_ > 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

[CMake] Appending to the LINK_FLAGS target property ?

[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

[CMake] External_Project_Add() and custom build configurations ?

[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

Re: [CMake] One source file, different arch

[Glenn Coombs]

Something like this should do the trick:

add_exectuable(myExe32 A.c B.c C.c)
add_exectuable(myExe64 A.c B.c D.c)

set_target_properties(myExe32 PROPERTIES COMPILE_FLAGS -m32)
set_target_properties(myExe32 PROPERTIES LINK_FLAGS -m32)

That assumes that the default setup would build 64-bit executables and you
just override that default with the necessary gcc switches to force a 32-bit
compile and link for the one target.  You would need something more
complicated to get it to work with both Visual Studio and linux/gcc but the
principle is the same.

--
Glenn


On 1 July 2011 02:14, 邓尧  wrote:

> Hi,
>
> I'm new to CMake. My project is a little different from the projects found
> in the tutorials. I have to compile some of the source files into two
> different archs(32-bit & 64-bit). It's like the following:
>   Given 4 source files: A.c, B.c, C.c, D.c, I need to compile a 32-bit
> executable with source file A.c, B.c and C.c, I also need to compile a
> 64-bit executable with source file A.c B.c and D.c.
> How to write the CMake script in this situation?
>
> Thanks
>
> -Yao
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check 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] Remove custom targets

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

Re: [CMake] External_Project_Add() and custom build configurations ?

[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  wrote:

> On Fri, Jul 1, 2011 at 7:23 AM, Glenn Coombs wrote:
>
>> 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

Re: [CMake] External_Project_Add() and custom build configurations ?

[Glenn Coombs]

On 6 July 2011 17:27, David Cole  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:

/external_proj.vcproj
/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 /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
/external_proj/src/external_proj-build directory.  But if cmake
had hooked the AfterClean event on external_proj and then called cmake
--build /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  wrote:
>
>> On Wed, Jul 6, 2011 at 12:17 PM, Glenn Coombs wrote:
>>
>>> On 5 July 2011 17:13, David Cole  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 mak

Re: [CMake] External_Project_Add() and custom build configurations ?

[Glenn Coombs]

On 7 July 2011 15:15, David Cole  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] Build the dependencies tree of an executable

[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  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 "include"ed 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.html
>
> Please keep messages on-topic and check 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] Appending to the LINK_FLAGS target property ?

[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  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 
> 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] Invalid library output directory when VC++ solution is generated

[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 

> 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] Invalid library output directory when VC++ solution is generated

[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 

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

Re: [CMake] Bug fix requests for the *next* release of CMake...

[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=12124
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

[CMake] Assembly language support using gcc or gas

[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
" ${ASM_SYS_FLAGS} -o  ")
endif()

And this resulted in the appropriate 32-bit or 64-bit assembler file being
compiled like so:

/usr/bin/as  -32 -o /i386.s.o  /i386.s
/usr/bin/as  -64 -o /iX86_64.s.o /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] Assembly language support using gcc or gas

[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 "
${ASM_SYS_FLAGS} -o  ")
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 

> 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

[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  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 -I -I ... 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
>-o-c , the compiler
> ignoring the unknown flags ("-c" in this case). *Without any explicit
> configuration from my part, it looks like  variable contains also a
> -I directive for the current compiled source file* ( 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  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

Re: [CMake] Include directories for C compile command

[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  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 wrote:
>
>> 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  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 -I -I ... 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
>>>-o-c , the c

Re: [CMake] Easing the pain with Visual Studio 2010 and CMake

[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  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=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.html
>
> Please keep messages on-topic and check 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] Assembly language support using gcc or gas

[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 

> 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 "
> > ${ASM_SYS_FLAGS} -o  ")
> > 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__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 

Re: [CMake] Bug fix requests for the *next* release of CMake...

[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] how to add additional linker options

[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 wrote:

> 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

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

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

[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  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 wrote:
>
>> 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  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] append command

[Glenn Coombs]

Out of all the suggestions so far I'd like to say that my preferred solution
is Michael's one of:

SET(  ... CONCAT [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  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(  ... CONCAT [SEP ])
> >>
> >> equivalent to
> >>
> >> SET( "${}...")
> >
> > 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

[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  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] Fwd: [CMake 0012398]: "IF" infamous functionality fails to work with macro arguments

[Glenn Coombs]

On 15 August 2011 20:23, Albert Meltzer  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

[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  wrote:

> On Aug 13, 2011, at 5:14 AM, Glenn Coombs  wrote:
>
> Out of all the suggestions so far I'd like to say that my preferred
> solution is Michael's one of:
>
> SET(  ... CONCAT [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] novice question: modification of FLAGS rule variable?

[Glenn Coombs]

What you can do however is set the variable which uses the 
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 " ${ASM_SYS_FLAGS}
-o  ")

to use what is set in my ASM_SYS_FLAGS variable instead of the default
 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  wrote:

> On Mon, Sep 5, 2011 at 1:31 PM, David Dunkle  wrote:
> > Is it possible to read and to set a property/rule variable like ?
> > What syntax would I use to do that? I mean  as it, for example,
> > appears here:
> >
> >
> >
> > set(CMAKE_C_COMPILE_OBJECT "${target_compiler} -c  -o ")
> >
> >
> >
> > For example can I do something like this (this is pseudo code)?
> >
> >
> >
> > #read
> >
> > set(MY_FLAGS,  ${} );
> >
> >
> >
> > …
> >
> >
> >
> > #set
> >
> > set(, ${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 "" 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

[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  wrote:

> Hi Victor,
>
>
> On Wed, Sep 7, 2011 at 05:39, Victor Yankee
>  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] novice question: modification of FLAGS rule variable?

[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  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  wrote:

> Thanks, Glenn. That almost works. However, the values of  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  -o ")***
> *
>
> ** **
>
> I can replace  with ${target_compiler_flags} yielding this:
>
> ** **
>
> set(CMAKE_C_COMPILE_OBJECT “${target_compiler} –c ${target_compiler_flags}
> –o ”)
>
> ** **
>
> 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 
> 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 " ${ASM_SYS_FLAGS}
> -o  ")
>
> to use what is set in my ASM_SYS_FLAGS variable instead of the default
>  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  wrote:
>
> On Mon, Sep 5, 2011 at 1:31 PM, David Dunkle  wrote:
> > Is it possible to read and to set a property/rule variable like ?
> > What syntax would I use to do that? I mean  as it, for example,
> > appears here:
> >
> >
> >
> > set(CMAKE_C_COMPILE_OBJECT "${target_compiler} -c  -o ")
> >
> >
> >
> > For example can I do something like this (this is pseudo code)?
> >
> >
> >
> > #read
> >
> > set(MY_FLAGS,  ${} );
> >
> >
> >
> > …
> >
> >
> >
> > #set
> >
> > set(, ${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 "" in the rules variables.
>
>
> HTH,

Re: [CMake] novice question: modification of FLAGS rule variable?

[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  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  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  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  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 ,
> 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  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  wrote:
>
> Thanks, Glenn. That almost works. However, the values of  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  -o ")***
> *
>
>  
>
> I can replace  with ${target_compiler_flags} yielding this:
>
>  
>
> set(CMAKE_C_COMPILE_OBJECT “${target_compiler} –c ${target_compiler_flags}
> –o ”)
>
>  
>
> but then the –DDEBUG is missing for the build of mylibd. I guess both
> mylibd and mylib u

Re: [CMake] Question about variables, cache, and scope

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

[CMake] if (DEFINED $ENV{VAR}) doesn't work as expected

[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

[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  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.html
>
> Please keep messages on-topic and check 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] if (DEFINED $ENV{VAR}) doesn't work as expected

[Glenn Coombs]

Yes, that did help.  Works perfectly without the $ character.

--
Glenn

On 11 October 2011 19:55, Michael Wild  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] New type of cache variable: lists

[Glenn Coombs]

How about overloading the existing OPTION command ?

option( "help string describing option" [initial value])

If the initial value supplied is a list then use the first entry.  Or maybe
a new OPTIONLIST command ?

--
Glenn

On 9 December 2011 00:00, David Cole  wrote:

> On Thu, Dec 8, 2011 at 5:43 PM, Robert Dailey  wrote:
> > On Thu, Dec 8, 2011 at 3:53 PM, David Cole 
> wrote:
> >>
> >> The 4th argument to SET (when CACHE is used) is the *type* of the
> >> cache entry itself. I will not call a cache entry a LIST when it is
> >> not actually a list.
> >>
> >> Nor will I accept that the 2nd argument to set should be anything
> >> other than the actual value that the cache entry ends up with after
> >> the set call.
> >>
> >> Those are the two things I have problems with in your proposal.
> >>
> >> One thing that you can do right now, with no changes to CMake, is
> >> write a CMake-language function as a wrapper that "does the right
> >> thing" with a list and a cache entry and its default value and setting
> >> its existing STRINGS property. As a side benefit, you can make the
> >> signature be whatever you want it to be...
> >>
> >> Of course, if we can come to an agreement about a good way to push
> >> this into the built-in set command, that would be ideal.
> >>
> >> But I find myself in a rather inflexible mood regarding my two points
> >> above.
> >>
> >>
> >> Still willing to listen, but not budging yet,
> >
> >
> > I agree with your points. I honestly don't think set() is the right tool
> for
> > the job though. There is already a mechanic in CMake to more conveniently
> > set boolean cache variables with the option() command. Likewise, I think
> we
> > should have one for lists, called choice():
> >
> > choice( BaseName "binary;octal;decimal;hexidecimal" "documentation" 0 )
> >
> > Parameter 1 is the destination variable, which will be stored in the
> cache
> > as a STRING type
> > Parameter 2 is the tuple, or list of choices for the user.
> > Parameter 3 is the documentation string
> > Parameter 4 (optional) is the index of an element in the tuple that
> shall be
> > used as the default value. If omitted, the first item in the list will be
> > used.
> >
> > Concerning parameter 4, this might be eliminated completely since I see
> no
> > reason why you can't just re-order the list to keep the default item as
> the
> > first item in the list.
> >
> > What do you think about this?
>
> Personally, I like the idea of a whole separate function much better
> than cramming it into the already way-overloaded "set".
>
> Not sure if "choice" is a good name, though. One of the problems with
> introducing new function names at the top level like that is we have
> no idea if the name is already used in an existing project as a
> function or macro in some CMakeLists files. So we can't be cavalier
> about deciding to add new top level built-in commands.
>
> You could certainly implement this as a CMake-language function in
> terms of the existing set and STRINGS cache entry property. (And by
> giving this advice, I almost guarantee that somebody will do so...)
>
> I'm gonna sleep on this now. :-)
>
>
> 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] Compile flag issues and VS Express

[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  wrote:

> ITK and VTK both build fine if I remove the /Zm1000 flag.
>
> On Mon, Jan 30, 2012 at 10:44 AM, Bill Hoffman 
> 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

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

Re: [CMake] Compile flag issues and VS Express

[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  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 wrote:
>
>> 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  wrote:
>>
>>> ITK and VTK both build fine if I remove the /Zm1000 flag.
>>>
>>> On Mon, Jan 30, 2012 at 10:44 AM, Bill Hoffman 
>>> 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

[CMake] Are the [Project name]_SOURCE_DIR variables stored in the cache ?

[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] Are the [Project name]_SOURCE_DIR variables stored in the cache ?

[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 wrote:

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

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

[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  wrote:

> On Thu, May 1, 2014 at 1:54 PM, Glenn Coombs 
> 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 ?

[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  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] How to get find_package(ZLIB) to set ZLIB_LIBRARIES to 32-bit version ?

[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] How to get find_package(ZLIB) to set ZLIB_LIBRARIES to 32-bit version ?

[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  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 a list of all the static libraries that a target will link against ?

[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 a list of all the static libraries that a target will link against ?

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

Re: [CMake] How to get a list of all the static libraries that a target will link against ?

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

Re: [CMake] How to get a list of all the static libraries that a target will link against ?

[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

$<$,SHARED_LIBRARY>:-Wl,-whole-archive>
${MTXSIM_LIBRARIES}

$<$,SHARED_LIBRARY>:-Wl,-no-whole-archive>
$<$,GNU>:dl>
$<$,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 
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 
> 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 > > 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 
>>> 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  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 ex

Re: [CMake] Spaces in a command

[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  wrote:

> can try removing the quotes and subst space for semicolon?
>
>
> On Tue, Jul 29, 2014 at 11:13 AM, Bill Newcomb 
> 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 
>> 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/opensourc

Re: [CMake] Is it possible for a dependee to use the dependency LINKER_FLAGS ?

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

[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  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 > <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 > <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
>> 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()

Re: [CMake] Settings different flags in sub projects

[Glenn Coombs]

Something like this should work:

add_compile_options(-std=c99)

set_property(DIRECTORY "/root/p1" PROPERTY COMPILE_OPTIONS "-Os")

set_property(DIRECTORY "/root/p2" PROPERTY COMPILE_OPTIONS "-O1")

or you just use the add_compile_options command in all 3
CMakeLists.txt files.  The CMakeLists.txt files in root/p1 and root/p2
will inherit the compile options set in the parent root/CMakeLists.txt
file.

--

Glenn



On 3 August 2014 23:46, David Zemon  wrote:

>  Hello,
>
> For the simple case of three directories and two projects - /root,
> /root/p1, and /root/p2 - I would like to set some common flags for both
> projects and then other flags should be independent. For instance, p1
> should be compiled with "-std=c99 -Os" and p2 should be compiled with 
> "-std=c99
> -O1". The first flag, -std=c99, is common to all projects and the second,
> -Os, might be changed from project to project. How do I do this?
>
> I thought I could create MyRulesOverride.cmake with the content:
>
> set(CMAKE_C_FLAGS_INIT "-std=c99")
>
> And that would be the end of it, but apparently not. The CMakeLists.txt
> files in each project have a line such as " set(CMAKE_C_FLAGS "-Os")"
> which is apparently overwriting the cached value from
> CMakeCInformation.cmake. I can't write a line like "set(CMAKE_C_FLAGS
> "${CMAKE_C_FLAGS} -Os")" because then the result is "-std=c99 -std=c99 -Os"
> for the second project.
>
> Any help would be greatly appreciated.
>
> David
>
> --
>
> 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] cmake version/feature detection

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

[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  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 --
> 3>LINK : fatal error LNK1104: cannot open file '\FORCE:multiple.obj'
> 4>-- Skipped Build: Project: ALL_BUILD, Configuration: Debug Win32
> --
> 4>Project 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  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"  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  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_exec

Re: [CMake] Resetting CMAKE_Fortran_FLAGS for a specific file

[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  wrote:

> 2014-08-13 16:16 GMT+0200, Mark Abraham :
> > On Wed, Aug 13, 2014 at 7:12 AM, marco restelli 
> > wrote:
> >
> >> 2014-08-13 15:53 GMT+0200, Mark Abraham :
> >> > On Wed, Aug 13, 2014 at 3:18 AM, marco restelli 
> >> > wrote:
> >> >
> >> >> Hi Petr,
> >> >>thanks, very informative!
> >> >>
> >> >> 2014-08-13 9:20 GMT+0200, Petr Kmoch :
> >> >> > 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} $ $)
>
>
> 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/cma

[CMake] How to get custom commands to build in parallel ?

[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] How to get custom commands to build in parallel ?

[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 
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 
> 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] Boost library directory not found unless I explicitly set BOOST_LIBRARYDIR ?

[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 CM

Re: [CMake] Boost library directory not found unless I explicitly set BOOST_LIBRARYDIR ?

[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  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 
> 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/

Re: [CMake] output of add_custom_command as target in Makefile

[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  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 
> 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 
> *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] Cannot add target-level dependencies to non-existent target

[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] Cannot add target-level dependencies to non-existent target

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

[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] Bug in find_file() command ?

[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] Bug in find_file() command ?

[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 wrote:
>
>> 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 inmediata

[CMake] Visual Studio 2012 Express for WD and cmake 2.8.9

[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] Visual Studio 2012 Express for WD and cmake 2.8.9

[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  wrote:

> On Mon, Sep 17, 2012 at 1:02 PM, Glenn Coombs wrote:
>
>> 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

Re: [CMake] Bug in find_file() command ?

[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
wrote:

>  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  >>gmail.com <http://www.cmake.org/mailman/listinfo/cmake>>wrote:*>>**>>>* 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 dire

[CMake] How to get "cmake --build ." to build in parallel ?

[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] Bug fix requests for the *next* release of CMake...

[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

[CMake] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned

[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] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned

[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
1>yuv_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  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

Re: [CMake] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned

[Glenn Coombs]

No, cleaning the project didn't remove that file.

--
Glenn

On 26 April 2013 17:28, Alexander Neundorf  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
> > 1>yuv_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

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

[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 --
1>Project 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  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

[Glenn Coombs]

Alex,

Would you like me to file a bug report on this ?

--
Glenn


On 1 May 2013 08:33, Glenn Coombs  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 --
> 1>Project 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 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

[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  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] CPack: Ignoring files using regex

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