[Cmake-commits] CMake branch, master, updated. v3.9.0-rc6-317-gec04964

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  ec049641c46eb788b25713e5d96ff32c89f0e819 (commit)
  from  2e47dee60a6c0bbc1eb08e9727c4c1d83dc02a3d (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec049641c46eb788b25713e5d96ff32c89f0e819
commit ec049641c46eb788b25713e5d96ff32c89f0e819
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Tue Jul 18 00:01:06 2017 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Tue Jul 18 00:01:06 2017 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 7a10ae1..5dfcd83 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 9)
-set(CMake_VERSION_PATCH 20170717)
+set(CMake_VERSION_PATCH 20170718)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] Append to property COMPILE_DEFINITIONS

[Florian Lindner]

Am 18.07.2017 um 10:59 schrieb Craig Scott:
> You appear to be setting a GLOBAL property where you probably meant 
> DIRECTORY. You could also consider setting the
> target property instead rather than applying it to all targets (unless that's 
> what you want).

I tried to set the property on all targets, therefore I thought GLOBAL is the 
right thing.

However,

set_property(DIRECTORY "${CMAKE_SOURCE_DIR}/src" APPEND
  PROPERTY COMPILE_DEFINITIONS "-DFOO")

hasn't had any effect either.

set_property(TARGET testprecice APPEND
  PROPERTY COMPILE_DEFINITIONS "FOO")

works. But setting it on all targets is exactly what I want. How can I do that?

Best,
Florian

> 
> 
> On Tue, Jul 18, 2017 at 12:56 PM, Florian Lindner  > wrote:
> 
> Hello,
> 
> I want to add compile definitions. Since I want to use generator 
> expressions, I can't use add_definitions, but have to
> use the COMPILE_DEFINITIONS property, but neither:
> 
> set_property(GLOBAL APPEND
>   PROPERTY COMPILE_DEFINITIONS "-DFOO")
> 
> for testing
> 
> or
> 
> set_property(GLOBAL APPEND
>   PROPERTY COMPILE_DEFINITIONS $<$:-DDebug>)
> 
> which should be final result, produces any -DFOO compiler switches.
> 
> I also tried placing it before and after the add_executable call.
> 
> What is wrong with that call?
> 
> Thanks,
> Florian
> --
> 
> 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 
> 
> 
> 
> 
> 
> -- 
> Craig Scott
> Melbourne, Australia
> https://crascit.com
-- 

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] Append to property COMPILE_DEFINITIONS

[Craig Scott]

You appear to be setting a GLOBAL property where you probably meant
DIRECTORY. You could also consider setting the target property instead
rather than applying it to all targets (unless that's what you want).


On Tue, Jul 18, 2017 at 12:56 PM, Florian Lindner 
wrote:

> Hello,
>
> I want to add compile definitions. Since I want to use generator
> expressions, I can't use add_definitions, but have to
> use the COMPILE_DEFINITIONS property, but neither:
>
> set_property(GLOBAL APPEND
>   PROPERTY COMPILE_DEFINITIONS "-DFOO")
>
> for testing
>
> or
>
> set_property(GLOBAL APPEND
>   PROPERTY COMPILE_DEFINITIONS $<$:-DDebug>)
>
> which should be final result, produces any -DFOO compiler switches.
>
> I also tried placing it before and after the add_executable call.
>
> What is wrong with that call?
>
> Thanks,
> Florian
> --
>
> 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
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

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] Append to property COMPILE_DEFINITIONS

[Florian Lindner]

Hello,

I want to add compile definitions. Since I want to use generator expressions, I 
can't use add_definitions, but have to
use the COMPILE_DEFINITIONS property, but neither:

set_property(GLOBAL APPEND
  PROPERTY COMPILE_DEFINITIONS "-DFOO")

for testing

or

set_property(GLOBAL APPEND
  PROPERTY COMPILE_DEFINITIONS $<$:-DDebug>)

which should be final result, produces any -DFOO compiler switches.

I also tried placing it before and after the add_executable call.

What is wrong with that call?

Thanks,
Florian
-- 

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] ExternalProject + PREFIX + CPACK - cannot get the good path

[Alfred Sawaya]

Hello folks,

I am trying to create a package with CPack from an External Project using
the autotools. The make install part try to copy files to /usr/local/lib,
but I do not want to package as root, so it fails. The cpack works because
(I think) it create a temp dir and set it as environment variable before
issuing the make install. But if I do a "make package", then it fails with
permissions denied.

I am not the first to get stuck with this issue (
https://stackoverflow.com/questions/44724281/cpack-building-external-autogen-project-with-bad-output-location
)
So I do not think that there is a direct solution ? Anyway, I can implement
one and send the patch.

I see only one solution to this issue: actually set a prefix on the
external project and implement a boolean variable
CPACK_IGNORE_INSTALL_PREFIX to remove it into the package. I tihnk it is
the most consistent way to resolve this ?
Do you have other ideas before I start implementing it ?

Thank you all,
Alfred

The CMakeLists.txt: (usable as is) <

Re: [CMake] Built-in way to detect if a root script is standalone or not?

[Robert Maynard]

That is about the easiest way to check if you are standalone.

On Mon, Jul 17, 2017 at 10:58 AM, Robert Dailey
 wrote:
> I have logic similar to this in some of my middleware libraries' root
> CMakeLists.txt:
>
> if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR )
> set( STANDALONE TRUE )
> endif()
>
> Is there a built-in way to detect this?
> --
>
> 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] How to get list of generated object-files of OBJECT-library?

[Deniz Bahadir]

Am 17.07.2017 um 17:15 schrieb Nils Gladitz:

On 17.07.2017 17:13, Deniz Bahadir wrote:

Am 17.07.2017 um 16:47 schrieb Nils Gladitz:

On 7/17/2017 3:52 PM, Deniz Bahadir wrote:


This works just fine. However, now I want to add an additional 
build-step after creation of the object-files and before linking the 
shared library. (In particular, I want to compress the debug-symbols 
in the object-files. But that should be irrelevant for my question.)


My first attempt was to add the following between the two 
add_library commands:

```
add_custom_command( TARGET ${PROJECT_NAME}_OBJECTS POST_BUILD
COMMAND objcopy --compress-debug-sections 
$

)
```
But that results in the following error:
```
(add_custom_command):
  Target "MyProject_OBJECTS" is an OBJECT library that may not
  have PRE_BUILD, PRE_LINK, or POST_BUILD commands.
```

So I tried instead to add the following between the two add_library 
commands:

```
add_custom_command( TARGET ${PROJECT_NAME} PRE_LINK
COMMAND objcopy --compress-debug-sections 
$

)
```
This then fails when evaluating the generator-expression:
```
(add_custom_command):
  Error evaluating generator expression:

$

  The evaluation of the TARGET_OBJECTS generator expression is only 
suitable
  for consumption by CMake.  It is not suitable for writing out 
elsewhere.

```

So I am currently out of ideas (which do not make the CMakeLists.txt 
file completely unmaintainable). Therefore my question is:


How can I retrieve the list of generated object-files so that I can 
pass it to another program that should be run as additional 
build-step before linking?


IMHO, the most comfortable (and syntactically cleanest) way would be 
my first attempt. But that is probably more a feature-request than a 
simple question.


FWIW this was implemented in the upcoming 3.9:
https://cmake.org/cmake/help/latest/module/CPackIFW.html#command:cpack_ifw_configure_component 



Thank you for your answer, Nils, but I do not really see how this 
relates.
This command seems to address CPack, while I am still struggling with 
CMake building files (that later might be installed by CPack). 


So sorry about that.
Must have gotten the wrong link in my clipboard.

The correct link is:
 https://cmake.org/cmake/help/latest/release/3.9.html#other


Thanks a lot. That makes more sense now.
So I will wait for CMake 3.9 to automagically fix my problem. :-)




Nils

Thanks again,
Deniz

--

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] problem linking a library and addressing cross dependency

[Zahid Iqbal]

Hi,

I have started using *cmake* recently.  I have the following question:

For building my system, I am working with two directories. Let's call them
*my_application_directory* and *protocol_source_directory. *

The code relating to my application resides under *my_application_directory*.
In fact, my application needs to interact with *protocol_source_directory*.
My application needs some functions from  *protocol_source_directory *as
well as it can provide some functionality to some process that is within
the *protocol_source_directory. *

*protocol_source_directory *is an existing protocol suite with its own
 top-level *makefile *that compiles and builds the protocol and generates a
static library.  The directory structure for *protocol_source_directory *is
as follows:

*protocol_source_directory*
*|*
*|*___ *dir1*
*|*
*|__ config*
*|__ include*
*|__ libs*
*|__ misc*
*|__ src*
*|*
*|__ modules*
*|**   |*
*|**   |__ layerA*
*|**   |__ layerB*
*|**   |__ layerC*
*|**   |__ layerD*
*|*
*|*
*|__ debug_tests*
  *|*
   *   |__ **my_application_directory*

Imagine a scenario in which there was no *my_application_directory. *In
this case, *protocol_source_directory *builds and compiles with the
*makefile* under *protocol_source_directory/**dir1.  *The static library
generated (e.g. protocol_lib.a) is available under
*protocol_source_directory/dir1/libs/. *

Purpose of developing an application is to add some functionality in the
protocol and then develop an application to test that functionality.

To fulfill this purpose, new files are added,


   - Few of new files are added at the location
*protocol_source_directory/dir1/src/modules/layerC/.
   *There is a *local makefile* at this level which is updated to reflect
   these new files.
   - some of the files need some definitions from *my_application_directory.
   *Therefore, I update the *local makefile* to include the needed paths to
   *my_application_directory. *so that I can use necessary headers inside
   ".c" files without path qualifiers.


*Having done this, *

*protocol_source_directory *builds and compiles with the *makefile* under
*protocol_source_directory/**dir1 *and generates the static library e.g.
protocol_lib.a.


   - Remaining functionality is implemented in files that reside under
*my_application_directory.
   *It is important to note that *my_application_directory *can be at
   location 
*protocol_source_directory/dir1/src/debug_tests/my_application_directory/
   *or it can exists separately at the same level as the
   *protocol_source_directory*


Imagine a scenario where, my *my_application_directory *is separate (not
inside) the *protocol_source_directory.  *Here is the* CMakeLists.txt *that
I am using to build my* application *while interacting with* protocol
source. *


project(PS_TEST)

cmake_minimum_required(VERSION 2.8)


# manually adding the sources using the set command as follows:

set(SRC_LIST main.c ISH.c ish_db.c ish_generator.c messages.c
my_string_help.c populate_ish.c

ISH.h ish_db.h ish_generator.h messages.h my_string_help.h
populate_ish.h my_types.h)

add_executable(${PROJECT_NAME} ${SRC_LIST})


# adding c99 style options

set_property(TARGET ${PROJECT_NAME} PROPERTY C_STANDARD 99)



set(FTT_BASE *protocol_source_directory*/*dir1*)


set(CORE_INCLUDES ${FTT_BASE}/src/modules/layerC/include/)

set(ETH_INCLUDES ${FTT_BASE}/src/modules/layerA/include/)

set(CORE_COMMONS ${FTT_BASE}/src/modules/layerC/common/)

set(MASTER_INCLUDES ${FTT_BASE}/src/modules/layerC/master/)



include_directories(include ${FTT_BASE}/config/
${FTT_BASE}/misc/make-rules/ ${FTT_BASE}/misc/arch-ports/
${CORE_INCLUDES} ${ETH_INCLUDES} ${CORE_COMMONS} ${MASTER_INCLUDES})

add_definitions(${FTT_COMPILE_OPT}$)



# linking to the protocl library code

find_library (FTT_LIB protocol_lib.a *protocol_source_directory*/*dir1**/libs/*)

target_link_libraries(${PROJECT_NAME} ${FTT_LIB})


Having done all this,

when I build my application using cmake, it gives me the following error:

my_types.h no such file and directory


please note that* my_types.h*  is in *my_application_directory.  *But,
since, some definitions are needed, I have included this file (i.e.,
include "my_types.h") in some .c files which are at
*protocol_source_directory/dir1/src/modules/layerC/.*

*Question:  *What I am doing wrong here, I have included the needed paths*
to **my_application_directory, *in the* local makefile *at
*protocol_source_directory/dir1/src/modules/layerC/.
**protocol_source_directory
*is compiling ok*, *why I receive this error after I link with static
project libray.




thanks for your help and time.


Regards,

zahid
-- 

Powered by www.kitware.com

Please keep messages 

Re: [CMake] OBJECT libraries and working around lake of target_link_libraries

[Chuck Atkins]

Hi David,


> Supporting OBJECT libraries in
> target_link_libraries calls was mentioned mentioned right back here
> https://cmake.org/pipermail/cmake-developers/2012-March/015422.html but
> sadly seems still to be on the back burner.
>

It's not on the back burner!  There has been progress on desiging the rest
of the implementation to make OBJECT libraries "first class citizens" and
I  can't give you actual dates I do believe you can probably expect it some
time this year.


>
> Not being
> able to use target_link_libraries with thier transitive nature made this
> very painful, many days of work.


I actually just recently went through the exercise of creating a workaround
for this in one of my projects so I can certainly understand the gaping
hole that is currently present.  The workaround I ended up with was to
create three seperate libraries: one for the objects, one for the usage
requirements, and then a third that combines them.

add_library(foo_objects OBJECT foo_src1.cxx foo_src2.cxx ...)

add_library(foo_interface INTERFACE)
target_link_libraries(foo_interface INTERFACE FooDepend1 FooDepend2 ...)
target_include_directories(foo_interface INTERFACE
  $
  $)

add_library(foo INTERFACE)
target_sources(foo INTERFACE $)
target_link_libraries(foo INTERFACE foo_interface)

The interface sources property on "foo" will populate the object files into
whatever uses "foo" in its target_link_libraries and then the usage
requirements in foo_interface will populate transitively.  The only problem
with this approach, and the reason for creating three separate libraries
instead of just adding the objects to the sources on foo_interface, is that
INTERFACE_SOURCES will continue to get propagated transitively potentially
causing duplicate symbols upstream, so it's really only appropriate for
private linking so you want to link publically then add the objects
manually and pass the interface publically.  This essentially means you
need to use it like this:

// Use foo privately, so just put "foo" in TLL and it just works
add_library(bar1 bar1_src1.cxx bar1_src2.cxx)
target_link_libraries(bar1 PRIVATE foo)

// Use foo publicly so we need to separately grab the objects and
// their usage requirements.
add_library(bar2
  bar2_src1.cxx bar2_src2.cxx
  $)
target_link_libraries(bar2 PUBLIC foo_interface)

This is effectively what the current plan is for the upstream
implementation, just all rolled into one; i.e. the objects get added to
whatever is explicitly linking with target_link_libraries, but all
transitive linkage only uses the interface usage requirements.  Plans, of
course, may change but that's what it's looking like right now, we just
need to find the time and funding to implement it.

- Chuck
-- 

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] Transitive behavior of target_link_libraries between shared/static

[Robert Dailey]

Suppose I have the following:

```
add_library( A STATIC ${files} )

add_library( B SHARED ${more_files} )
target_link_libraries( B PUBLIC A )

add_library( C STATIC ${even_more_files} )
target_link_libraries( C PUBLIC B )


add_executable( D ${exe_files} )
target_link_libraries( D PRIVATE C )
```

Does the linker command for target `D` ever see target A's static link
library? I'm hoping the only thing the linker gets is `libB.so` and
`libC.a`, without `libA.a`.

It seems like A to everyone outside of B should just be a set of
public include directories and compile definitions, since the link
file aspect of it should be hidden across shared library boundaries.
Hoping someone can explain how this works. I want to make sure static
libs sitting behind shared libs in the dependency tree do not get
exposed.
-- 

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 list of generated object-files of OBJECT-library?

[Nils Gladitz]

On 17.07.2017 17:13, Deniz Bahadir wrote:

Am 17.07.2017 um 16:47 schrieb Nils Gladitz:

On 7/17/2017 3:52 PM, Deniz Bahadir wrote:


This works just fine. However, now I want to add an additional 
build-step after creation of the object-files and before linking the 
shared library. (In particular, I want to compress the debug-symbols 
in the object-files. But that should be irrelevant for my question.)


My first attempt was to add the following between the two 
add_library commands:

```
add_custom_command( TARGET ${PROJECT_NAME}_OBJECTS POST_BUILD
COMMAND objcopy --compress-debug-sections 
$

)
```
But that results in the following error:
```
(add_custom_command):
  Target "MyProject_OBJECTS" is an OBJECT library that may not
  have PRE_BUILD, PRE_LINK, or POST_BUILD commands.
```

So I tried instead to add the following between the two add_library 
commands:

```
add_custom_command( TARGET ${PROJECT_NAME} PRE_LINK
COMMAND objcopy --compress-debug-sections 
$

)
```
This then fails when evaluating the generator-expression:
```
(add_custom_command):
  Error evaluating generator expression:

$

  The evaluation of the TARGET_OBJECTS generator expression is only 
suitable
  for consumption by CMake.  It is not suitable for writing out 
elsewhere.

```

So I am currently out of ideas (which do not make the CMakeLists.txt 
file completely unmaintainable). Therefore my question is:


How can I retrieve the list of generated object-files so that I can 
pass it to another program that should be run as additional 
build-step before linking?


IMHO, the most comfortable (and syntactically cleanest) way would be 
my first attempt. But that is probably more a feature-request than a 
simple question.


FWIW this was implemented in the upcoming 3.9:
https://cmake.org/cmake/help/latest/module/CPackIFW.html#command:cpack_ifw_configure_component 



Thank you for your answer, Nils, but I do not really see how this 
relates.
This command seems to address CPack, while I am still struggling with 
CMake building files (that later might be installed by CPack). 


So sorry about that.
Must have gotten the wrong link in my clipboard.

The correct link is:
https://cmake.org/cmake/help/latest/release/3.9.html#other

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://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] How to get list of generated object-files of OBJECT-library?

[Deniz Bahadir]

Am 17.07.2017 um 16:47 schrieb Nils Gladitz:

On 7/17/2017 3:52 PM, Deniz Bahadir wrote:


This works just fine. However, now I want to add an additional 
build-step after creation of the object-files and before linking the 
shared library. (In particular, I want to compress the debug-symbols 
in the object-files. But that should be irrelevant for my question.)


My first attempt was to add the following between the two add_library 
commands:

```
add_custom_command( TARGET ${PROJECT_NAME}_OBJECTS POST_BUILD
COMMAND objcopy --compress-debug-sections 
$

)
```
But that results in the following error:
```
(add_custom_command):
  Target "MyProject_OBJECTS" is an OBJECT library that may not
  have PRE_BUILD, PRE_LINK, or POST_BUILD commands.
```

So I tried instead to add the following between the two add_library 
commands:

```
add_custom_command( TARGET ${PROJECT_NAME} PRE_LINK
COMMAND objcopy --compress-debug-sections 
$

)
```
This then fails when evaluating the generator-expression:
```
(add_custom_command):
  Error evaluating generator expression:

$

  The evaluation of the TARGET_OBJECTS generator expression is only 
suitable
  for consumption by CMake.  It is not suitable for writing out 
elsewhere.

```

So I am currently out of ideas (which do not make the CMakeLists.txt 
file completely unmaintainable). Therefore my question is:


How can I retrieve the list of generated object-files so that I can 
pass it to another program that should be run as additional build-step 
before linking?


IMHO, the most comfortable (and syntactically cleanest) way would be 
my first attempt. But that is probably more a feature-request than a 
simple question.


FWIW this was implemented in the upcoming 3.9:
https://cmake.org/cmake/help/latest/module/CPackIFW.html#command:cpack_ifw_configure_component 



Thank you for your answer, Nils, but I do not really see how this relates.
This command seems to address CPack, while I am still struggling with 
CMake building files (that later might be installed by CPack).





Nils


Deniz
--

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] Built-in way to detect if a root script is standalone or not?

[Robert Dailey]

I have logic similar to this in some of my middleware libraries' root
CMakeLists.txt:

if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR )
set( STANDALONE TRUE )
endif()

Is there a built-in way to detect this?
-- 

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 list of generated object-files of OBJECT-library?

[Nils Gladitz]

On 7/17/2017 3:52 PM, Deniz Bahadir wrote:


This works just fine. However, now I want to add an additional 
build-step after creation of the object-files and before linking the 
shared library. (In particular, I want to compress the debug-symbols 
in the object-files. But that should be irrelevant for my question.)


My first attempt was to add the following between the two add_library 
commands:

```
add_custom_command( TARGET ${PROJECT_NAME}_OBJECTS POST_BUILD
COMMAND objcopy --compress-debug-sections 
$

)
```
But that results in the following error:
```
(add_custom_command):
  Target "MyProject_OBJECTS" is an OBJECT library that may not
  have PRE_BUILD, PRE_LINK, or POST_BUILD commands.
```

So I tried instead to add the following between the two add_library 
commands:

```
add_custom_command( TARGET ${PROJECT_NAME} PRE_LINK
COMMAND objcopy --compress-debug-sections 
$

)
```
This then fails when evaluating the generator-expression:
```
(add_custom_command):
  Error evaluating generator expression:

$

  The evaluation of the TARGET_OBJECTS generator expression is only 
suitable
  for consumption by CMake.  It is not suitable for writing out 
elsewhere.

```

So I am currently out of ideas (which do not make the CMakeLists.txt 
file completely unmaintainable). Therefore my question is:


How can I retrieve the list of generated object-files so that I can 
pass it to another program that should be run as additional build-step 
before linking?


IMHO, the most comfortable (and syntactically cleanest) way would be 
my first attempt. But that is probably more a feature-request than a 
simple question.


FWIW this was implemented in the upcoming 3.9:
https://cmake.org/cmake/help/latest/module/CPackIFW.html#command:cpack_ifw_configure_component

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://public.kitware.com/mailman/listinfo/cmake

[Cmake-commits] CMake branch, release, updated. v3.9.0-rc6-12-gf2b05a0

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, release has been updated
   via  f2b05a095ab2ab12d9d82daabdc31e46d36d4fcf (commit)
   via  cfa9a2bd8893349516a2f5ffa51e67e6e0973d1c (commit)
   via  68a64478c51ff6feb3eb939517e53ba3de850642 (commit)
   via  0348383b8ccb943a68cda3ecf1bdd609212ff5ca (commit)
   via  8c7facd69b63f986d8d35c22d7e40cddc7da9467 (commit)
   via  218ce158f2d9b25bc5789a28d742736129cdb088 (commit)
   via  13e9a370d9567d68120396b785c5d9e91a7cc5b8 (commit)
   via  221ffabfad9ed61c6c1aed8b53e5402a943477bd (commit)
  from  9d9085ab3614fa36d8b3e7e337468b53ae646b82 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
---

Summary of changes:
 Help/release/3.9.rst  |7 +++
 Source/cmGlobalXCodeGenerator.cxx |   11 +++
 Source/cmLocalGenerator.cxx   |   12 ++--
 Templates/TestDriver.cxx.in   |4 ++--
 4 files changed, 30 insertions(+), 4 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.9.0-rc6-316-g2e47dee

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  2e47dee60a6c0bbc1eb08e9727c4c1d83dc02a3d (commit)
   via  5401491648c76b61307907633502c78cd2393392 (commit)
   via  94d387a970d628c14ffcbd9e6435e5a3efe94280 (commit)
   via  8ff5aeb7cb7004e48a3cb2f3524b368b77db3075 (commit)
   via  3ce57e3b546cb1f7aec43717ff239cd72428cc5a (commit)
   via  f2b05a095ab2ab12d9d82daabdc31e46d36d4fcf (commit)
   via  cfa9a2bd8893349516a2f5ffa51e67e6e0973d1c (commit)
   via  68a64478c51ff6feb3eb939517e53ba3de850642 (commit)
   via  0348383b8ccb943a68cda3ecf1bdd609212ff5ca (commit)
   via  8c7facd69b63f986d8d35c22d7e40cddc7da9467 (commit)
   via  cef77f06878371cf7615bf4dd3da7cc3ba257878 (commit)
   via  74e337117f839378e284b7edddc8484ce9c683f5 (commit)
   via  fca0546175edf6cae51bbf673fa379899e8c0ea6 (commit)
   via  218ce158f2d9b25bc5789a28d742736129cdb088 (commit)
   via  13e9a370d9567d68120396b785c5d9e91a7cc5b8 (commit)
   via  221ffabfad9ed61c6c1aed8b53e5402a943477bd (commit)
  from  96041907014c9d1f83dc6b2c7fbbdab8aed728ea (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2e47dee60a6c0bbc1eb08e9727c4c1d83dc02a3d
commit 2e47dee60a6c0bbc1eb08e9727c4c1d83dc02a3d
Merge: 5401491 f2b05a0
Author: Brad King 
AuthorDate: Mon Jul 17 10:28:27 2017 -0400
Commit: Brad King 
CommitDate: Mon Jul 17 10:28:27 2017 -0400

Merge branch 'release-3.9'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5401491648c76b61307907633502c78cd2393392
commit 5401491648c76b61307907633502c78cd2393392
Merge: 94d387a cfa9a2b
Author: Brad King 
AuthorDate: Mon Jul 17 14:26:45 2017 +
Commit: Kitware Robot 
CommitDate: Mon Jul 17 10:27:26 2017 -0400

Merge topic 'doc-vs2015-update-relnote'

cfa9a2bd Help: Add a 3.9 release note about the VS GenerateDebugInformation 
update

Acked-by: Kitware Robot 
Merge-request: !1060


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=94d387a970d628c14ffcbd9e6435e5a3efe94280
commit 94d387a970d628c14ffcbd9e6435e5a3efe94280
Merge: 8ff5aeb 221ffab
Author: Brad King 
AuthorDate: Mon Jul 17 14:26:33 2017 +
Commit: Kitware Robot 
CommitDate: Mon Jul 17 10:27:03 2017 -0400

Merge topic 'TestDriver-fix-Wconversion'

221ffabf TestDriver: Fix -Wconversion warning

Acked-by: Kitware Robot 
Merge-request: !1058


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8ff5aeb7cb7004e48a3cb2f3524b368b77db3075
commit 8ff5aeb7cb7004e48a3cb2f3524b368b77db3075
Merge: 3ce57e3 0348383
Author: Brad King 
AuthorDate: Mon Jul 17 14:26:21 2017 +
Commit: Kitware Robot 
CommitDate: Mon Jul 17 10:26:37 2017 -0400

Merge topic 'xcode9support'

0348383b Xcode: Add "outputPaths" to custom command script build phase

Acked-by: Kitware Robot 
Merge-request: !1054


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3ce57e3b546cb1f7aec43717ff239cd72428cc5a
commit 3ce57e3b546cb1f7aec43717ff239cd72428cc5a
Merge: 9604190 cef77f0
Author: Brad King 
AuthorDate: Mon Jul 17 14:25:31 2017 +
Commit: Kitware Robot 
CommitDate: Mon Jul 17 10:25:36 2017 -0400

Merge topic 'fix-lang-std-option-list'

cef77f06 Allow language extensions without any standard to use a list of 
options
74e33711 Merge branch 'backport-fix-lang-std-option-list' into 
fix-lang-std-option-list
fca05461 cmLocalGenerator: Explain standard flag selection logic in comments
218ce158 Features: Fix support for a list of language standard options

Acked-by: Kitware Robot 
Merge-request: !1059


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cef77f06878371cf7615bf4dd3da7cc3ba257878
commit cef77f06878371cf7615bf4dd3da7cc3ba257878
Author: Brad King 
AuthorDate: Fri Jul 14 10:13:19 2017 -0400
Commit: Brad King 
CommitDate: Fri Jul 14 10:20:07 2017 -0400

Allow language extensions without any standard to use a list of options

Fix the logic added by commit a2112257 (Add infrastructure to use
language extensions without any standard, 2017-06-29) to support a list
of options as has been done since commit v3.9.0-rc1~174^2~2
(CompileFeatures: Let STD compile options be a list, 2016-10-05).

diff --git 

[Cmake-commits] CMake branch, master, updated. v3.9.0-rc6-300-g9604190

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  96041907014c9d1f83dc6b2c7fbbdab8aed728ea (commit)
   via  a1b3886556c0c052983fc2c9299f121c04a56b93 (commit)
  from  2d5e494637f9dad13fd0206ac3420e7d26f8b778 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=96041907014c9d1f83dc6b2c7fbbdab8aed728ea
commit 96041907014c9d1f83dc6b2c7fbbdab8aed728ea
Merge: 2d5e494 a1b3886
Author: Brad King 
AuthorDate: Mon Jul 17 14:24:18 2017 +
Commit: Kitware Robot 
CommitDate: Mon Jul 17 10:24:54 2017 -0400

Merge topic 'FindLibXml2-standard-vars'

a1b38865 FindLibXml2: Switch to standard module variable names

Acked-by: Kitware Robot 
Merge-request: !1043


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a1b3886556c0c052983fc2c9299f121c04a56b93
commit a1b3886556c0c052983fc2c9299f121c04a56b93
Author: Vadim Zhukov 
AuthorDate: Tue Jul 11 01:43:47 2017 +0300
Commit: Brad King 
CommitDate: Fri Jul 14 11:25:10 2017 -0400

FindLibXml2: Switch to standard module variable names

* LIBXML2_INCLUDE_DIR talks about libxml2 itself;
* LIBXML2_INCLUDE_DIRS lists also include directories coming from
  libxml2's dependencies and is what libxml2 users should use;
* LIBXML2_LIBRARY talks about libxml2 itself;
* LIBXML2_LIBRARIES is what libxml2 users should link to.

This commit doesn't break existing users of FindLibXml2.cmake,
but provides the way for correct behaviour in future. In particular,
on OpenBSD LIBXML2_INCLUDE_DIR resolves to /usr/local/include/libxml2,
while libiconv (an libxml2 dependency) puts iconv.h
in /usr/local/include, which is not picked up automatically.

diff --git a/Modules/FindLibXml2.cmake b/Modules/FindLibXml2.cmake
index 613f927..f68628d 100644
--- a/Modules/FindLibXml2.cmake
+++ b/Modules/FindLibXml2.cmake
@@ -5,18 +5,37 @@
 # FindLibXml2
 # ---
 #
-# Try to find the LibXml2 xml processing library
+# Find the XML processing library (libxml2).
 #
-# Once done this will define
+# Result variables
+# 
 #
-# ::
+# This module will set the following variables in your project:
 #
-#   LIBXML2_FOUND - System has LibXml2
-#   LIBXML2_INCLUDE_DIR - The LibXml2 include directory
-#   LIBXML2_LIBRARIES - The libraries needed to use LibXml2
-#   LIBXML2_DEFINITIONS - Compiler switches required for using LibXml2
-#   LIBXML2_XMLLINT_EXECUTABLE - The XML checking tool xmllint coming with 
LibXml2
-#   LIBXML2_VERSION_STRING - the version of LibXml2 found (since CMake 2.8.8)
+# ``LIBXML2_FOUND``
+#   true if libxml2 headers and libraries were found
+# ``LIBXML2_INCLUDE_DIR``
+#   the directory containing LibXml2 headers
+# ``LIBXML2_INCLUDE_DIRS``
+#   list of the include directories needed to use LibXml2
+# ``LIBXML2_LIBRARIES``
+#   LibXml2 libraries to be linked
+# ``LIBXML2_DEFINITIONS``
+#   the compiler switches required for using LibXml2
+# ``LIBXML2_XMLLINT_EXECUTABLE``
+#   path to the XML checking tool xmllint coming with LibXml2
+# ``LIBXML2_VERSION_STRING``
+#   the version of LibXml2 found (since CMake 2.8.8)
+#
+# Cache variables
+# ^^^
+#
+# The following cache variables may also be set:
+#
+# ``LIBXML2_INCLUDE_DIR``
+#   the directory containing LibXml2 headers
+# ``LIBXML2_LIBRARY``
+#   path to the LibXml2 library
 
 # use pkg-config to get the directories and then use these values
 # in the find_path() and find_library() calls
@@ -31,7 +50,7 @@ find_path(LIBXML2_INCLUDE_DIR NAMES libxml/xpath.h
PATH_SUFFIXES libxml2
)
 
-find_library(LIBXML2_LIBRARIES NAMES xml2 libxml2
+find_library(LIBXML2_LIBRARY NAMES xml2 libxml2
HINTS
${PC_LIBXML_LIBDIR}
${PC_LIBXML_LIBRARY_DIRS}
@@ -52,9 +71,12 @@ elseif(LIBXML2_INCLUDE_DIR AND EXISTS 
"${LIBXML2_INCLUDE_DIR}/libxml/xmlversion.
 unset(libxml2_version_str)
 endif()
 
+set(LIBXML2_INCLUDE_DIRS ${LIBXML2_INCLUDE_DIR} ${PC_LIBXML_INCLUDE_DIRS})
+set(LIBXML2_LIBRARIES ${LIBXML2_LIBRARY})
+
 include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
 FIND_PACKAGE_HANDLE_STANDARD_ARGS(LibXml2
-  REQUIRED_VARS LIBXML2_LIBRARIES 
LIBXML2_INCLUDE_DIR
+  REQUIRED_VARS LIBXML2_LIBRARY 
LIBXML2_INCLUDE_DIR
   VERSION_VAR LIBXML2_VERSION_STRING)
 
-mark_as_advanced(LIBXML2_INCLUDE_DIR LIBXML2_LIBRARIES 
LIBXML2_XMLLINT_EXECUTABLE)
+mark_as_advanced(LIBXML2_INCLUDE_DIR LIBXML2_LIBRARY 

Re: [cmake-developers] AUTOGEN per-config sources

[Brad King]

On 07/15/2017 08:37 PM, comic fans wrote:
> recent commits shows that QtAutogen is moving to create suffixed files
> and folders for different config, but with this commit,
> my generator test failed on Qt5Autogen as following:
> 
> Target "rccDepends" has source files which vary by configuration.  This is
>  not supported by the "Fastbuild" generator.
> 
>  Config "Debug":
> 
>/working/CMake/Tests/QtAutogen/rccDepends/main.cpp
>/working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res1.qrc
>/working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res2.qrc
>
> /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res1_Debug.cpp
>
> /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res2_Debug.cpp
> 
>  Config "Release":
> 
>/working/CMake/Tests/QtAutogen/rccDepends/main.cpp
>/working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res1.qrc
>/working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/res2.qrc
>
> /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res1_Release.cpp
>
> /working/CMake/fastbuild/Tests/Qt5Autogen/rccDepends/rccDepends_autogen/EJRQKI7XPS/qrc_res2_Release.cpp
> 
> How should I make my generator compatible with this ? or this feature
> didn't complete ,I should wait it complete ?

The goal for Qt AUTOGEN features is to have the generated files use
per-config locations in multi-config generators.  However, our
multi-config generators don't all fully support per-config sources yet.
Your new generator should do so if possible. See GetAllConfigSources
in cmGeneratorTarget.

Sebastian, FYI comic fans is working on a new multi-config generator.

-Brad

-- 

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

[CMake] How to get list of generated object-files of OBJECT-library?

[Deniz Bahadir]

Hi list,


I have a question regarding "add_custom_command" and OBJECT-libraries:

My CMakeLists.txt contains the following (simplified) targets:

```
set ( SOURCE_FILES
# ... several C++-source files
)
add_library( OBJECT ${PROJECT_NAME}_OBJECTS
${SOURCE_FILES}
)
add_library( ${PROJECT_NAME}
   $
)
```

This works just fine. However, now I want to add an additional 
build-step after creation of the object-files and before linking the 
shared library. (In particular, I want to compress the debug-symbols in 
the object-files. But that should be irrelevant for my question.)


My first attempt was to add the following between the two add_library 
commands:

```
add_custom_command( TARGET ${PROJECT_NAME}_OBJECTS POST_BUILD
COMMAND objcopy --compress-debug-sections 
$

)
```
But that results in the following error:
```
(add_custom_command):
  Target "MyProject_OBJECTS" is an OBJECT library that may not
  have PRE_BUILD, PRE_LINK, or POST_BUILD commands.
```

So I tried instead to add the following between the two add_library 
commands:

```
add_custom_command( TARGET ${PROJECT_NAME} PRE_LINK
COMMAND objcopy --compress-debug-sections 
$

)
```
This then fails when evaluating the generator-expression:
```
(add_custom_command):
  Error evaluating generator expression:

$

  The evaluation of the TARGET_OBJECTS generator expression is only 
suitable

  for consumption by CMake.  It is not suitable for writing out elsewhere.
```

So I am currently out of ideas (which do not make the CMakeLists.txt 
file completely unmaintainable). Therefore my question is:


How can I retrieve the list of generated object-files so that I can pass 
it to another program that should be run as additional build-step before 
linking?


IMHO, the most comfortable (and syntactically cleanest) way would be my 
first attempt. But that is probably more a feature-request than a simple 
question.



Thanks for your help.
Deniz Bahadir

--

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] DLL handling under CMake

[Louis-Paul CORDIER]

Hi,

I bump this question again for DLL library handling. Still I have the 
issue with my dependency "scanner" in my previous email that can't 
evaluate if a target with a generator expression is a valid one or not.


if(NOT TARGET "$<$:Foo_lib>")
  # will never go into this statement
endif()

Thanks,

LP

Le 04/07/2017 à 10:19, Louis-Paul CORDIER a écrit :


Hi,

Thank you very much for this code snippet. However I don't like the 
fixup_bundle function, as it takes the first dll that it found to be 
linked against.


I also did a try with a dependency scanning function. It is quiet long 
to write, but I guess it is the cleanest way to handle DLL under Windows.
Note: I still have an issue with this function. Indeed, if user uses 
Generator expressions for library dependencies, it will not work.

e.g:
add_library(Foo_lib IMPORTED GLOBAL)
# ... set location properties
target_link_libraries(${PROJECT_NAME} optimized 
$<$:Foo_lib>)


Any idea for a workaround? What do you think about this CMake code?

Also, I would see a real benefit to add a LINK_DEPENDENT_LIBRARIES 
property (inspired of IMPORTED_LINK_DEPENDENT_LIBRARIES) to each 
target that could be automatically filled by each 
target_link_libraries() calls.




# This function scan all dependencies of a project recursively, and 
retrieve all shared

# library associated with it.
# Prerequisite: your upstream CMakeLists.txt must make use of 
add_library(foo SHARED IMPORTED GLOBAL),

# and fill the following properties on the imported target:
# set_target_properties(foo PROPERTIES IMPORTED_IMPLIB "path_to_foo.lib")
# set_target_properties(foo PROPERTIES IMPORTED_LOCATION 
"path_to_foo.dll")
# set_target_properties(foo PROPERTIES 
IMPORTED_LINK_DEPENDENT_LIBRARIES "path_to_dll_on_which_foo_depends.dll")
# GLOBAL keyword is important as it allows downstream CMakeLists.txt 
to scan dependencies.


# Input parameters:
# dep_to_scan: your downstream project
# config_to_scan: configuration to use for the scanning.
# output_variable: variable in which the function stores the result.

# Usage:
# RECURSIVE_SCAN(my_app Release DLLS)
#  install(FILES ${DLLS}
# DESTINATION release
# CONFIGURATIONS Release)

set(COUNT 0)
function(RECURSIVE_SCAN dep_to_scan config_to_scan output_variable)

  MATH(EXPR COUNT "${COUNT}+1")
  string(RANDOM LENGTH ${COUNT} ALPHABET "-" SPACES)

  message("${SPACES} Scanning ${dep_to_scan}")
  if(NOT TARGET ${dep_to_scan})
MATH(EXPR COUNT "${COUNT}-1")
#message("${dep_to_scan} Is not target")
return()
  endif()


  get_target_property(_is_imported ${dep_to_scan} IMPORTED)
  if(_is_imported)

# We need to check if the imported library rely on other shared 
libraries.
get_target_property(_dependent_dll ${_lib} 
IMPORTED_LINK_DEPENDENT_LIBRARIES_${config_to_scan})

if(NOT _dependent_dll)
  get_target_property(_dependent_dll ${_lib} 
IMPORTED_LINK_DEPENDENT_LIBRARIES)

endif()

if(_dependent_dll)
  list(APPEND ${output_variable} ${_dependent_dll})
endif()


#Otherwise, check if it is a shared library. (LOCATION variable 
can be

# either .lib or DLL regarding of the type of library.)
get_target_property(_TYPE ${dep_to_scan} TYPE)

if(NOT _TYPE STREQUAL STATIC_LIBRARY)
  get_target_property(_dll_found ${dep_to_scan} 
LOCATION_${config_to_scan})

  if(_dll_found)
list(APPEND ${output_variable} ${_dll_found})
  endif()

endif()

message("${SPACES}- DLL found: (${${output_variable}})")

  endif(_is_imported)

  get_target_property(_libraries ${dep_to_scan} INTERFACE_LINK_LIBRARIES)

  if(_libraries)
  foreach(_lib ${_libraries})
RECURSIVE_SCAN(${_lib} ${config_to_scan} ${output_variable})
  endforeach()
  endif()

  # If we reach our first recursion, we need to clean the list of
  # DLL in order to remove duplicates.
  MATH(EXPR COUNT "${COUNT}-1")

  if(${COUNT} EQUAL 0)
list(REMOVE_DUPLICATES ${output_variable})
  endif()

  set(${output_variable} ${${output_variable}} PARENT_SCOPE)

endfunction(RECURSIVE_SCAN)


Best regards,

Louis-Paul CORDIER

Le 04/05/2017 à 09:51, lec...@gmail.com a écrit :


I managed to get it working by using an intermediate script.

One might want to generate the script instead of using the « RUN_IT » 
variable trick.


This was only tested on Windows, but seems to work fine.

Put the following code in a xx.cmake file, include it from your 
CMakeLists.txt and enjoy.


# This is a helper script to run BundleUtilities fixup_bundle as 
postbuild


# for a target. The primary use case is to copy .DLLs to the build 
directory for


# the Windows platform. It allows generator expressions to be used to 
determine


# the binary location

#

# Usage : run_fixup(TARGET LIBS DIRS)

# - TARGET : A cmake target

# - See fixup_bundle for LIBS and DIRS arguments

if(RUN_IT)

# Script ran by the add_custom_command

include(BundleUtilities)

fixup_bundle("${TO_FIXUP_FILE}" "${TO_FIXUP_LIBS}"