From Torsten at Robitzki.de  Fri Feb  1 02:02:42 2019
From: Torsten at Robitzki.de (Torsten at Robitzki.de)
Date: Fri, 1 Feb 2019 08:02:42 +0100
Subject: [CMake] Checking Variables in a tool-chain file
In-Reply-To: <CA+dygYmJKt8aVUtxaNXXvOyebKLum-bzngxZ1G+7KCKjgv8K-A@mail.gmail.com>
References: <4D77F615-3D1A-410F-BA81-08CB6FAF8CAC@Robitzki.de>
 <CAE7Ac0BPkK7KvUB388XogO7_bPaA=B5ON+vE4RXHGyJCH0NrLA@mail.gmail.com>
 <19158EA8-E576-4D64-B245-B366FB37BD11@Robitzki.de>
 <7CA3C5F3-D472-412B-8D55-98F3FC4B1F13@fb.com>
 <CA+dygYmJKt8aVUtxaNXXvOyebKLum-bzngxZ1G+7KCKjgv8K-A@mail.gmail.com>
Message-ID: <7CCB109D-5BD0-4F47-BC67-1D15190EDE37@Robitzki.de>


> Am 31.01.2019 um 21:10 schrieb Craig Scott <craig.scott at crascit.com>:
> 
> This is precisely the scenario that the CMAKE_TRY_COMPILE_PLATFORM_VARIABLES variable is meant for. It allows a toolchain file to specify additional variables that should be passed along to try_compile().

Works like a charm. Thanks a lot!

Torsten

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://cmake.org/pipermail/cmake/attachments/20190201/a5c8a5ff/attachment.sig>

From Torsten at Robitzki.de  Fri Feb  1 02:09:24 2019
From: Torsten at Robitzki.de (Torsten Robitzki)
Date: Fri, 1 Feb 2019 08:09:24 +0100
Subject: [CMake] Syntax to document cmake files, functions and macros
In-Reply-To: <75AF606E-AE0C-4129-9290-0854F395F333@gmail.com>
References: <cc023f8c-3905-b470-a2a6-ad57a00150a0@free.fr>
 <1506c326-ebba-3f1d-32b3-7ac8f0100d4f@gmail.com>
 <75AF606E-AE0C-4129-9290-0854F395F333@gmail.com>
Message-ID: <204B048D-7540-402B-B5E8-081C897C131A@Robitzki.de>



> Am 31.01.2019 um 19:55 schrieb Marc Herbert <marc.herbert at gmail.com>:
> 
> So is there a relatively simple way to run the same tooling on any regular, non-module .cmake files
> too and produce project-specific documentation?

We are working on a larger CMake project and we use Sphinx. We use sphinxcontrib.moderncmakedomain as extension, which adds CMake syntax highlighting and sphinx.ext.intersphinx to allow us, to refer to the original CMake documentation.

regards,

Torsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://cmake.org/pipermail/cmake/attachments/20190201/128b3b2a/attachment.sig>

From frodak17 at gmail.com  Fri Feb  1 11:17:32 2019
From: frodak17 at gmail.com (frodak17)
Date: Fri, 1 Feb 2019 11:17:32 -0500
Subject: [CMake] Checking Variables in a tool-chain file
In-Reply-To: <7CCB109D-5BD0-4F47-BC67-1D15190EDE37@Robitzki.de>
References: <4D77F615-3D1A-410F-BA81-08CB6FAF8CAC@Robitzki.de>
 <CAE7Ac0BPkK7KvUB388XogO7_bPaA=B5ON+vE4RXHGyJCH0NrLA@mail.gmail.com>
 <19158EA8-E576-4D64-B245-B366FB37BD11@Robitzki.de>
 <7CA3C5F3-D472-412B-8D55-98F3FC4B1F13@fb.com>
 <CA+dygYmJKt8aVUtxaNXXvOyebKLum-bzngxZ1G+7KCKjgv8K-A@mail.gmail.com>
 <7CCB109D-5BD0-4F47-BC67-1D15190EDE37@Robitzki.de>
Message-ID: <CAM_JqVnX0uUXKYQKWKD95mp2fWQ6QHp9gwJtOdgQciYPCepziA@mail.gmail.com>

Be aware that CMAKE_TRY_COMPILE_PLATFORM_VARIABLES only works with the
try_compile()
<https://cmake.org/cmake/help/latest/command/try_compile.html#command:try_compile>
command source file signature. Unfortunately it doesn't work with
try_compile() whole projects signature.  The section on Other Behavior
Settings mostly only applies to the source file signature.

On Fri, Feb 1, 2019 at 2:02 AM <Torsten at robitzki.de> wrote:

>
> > Am 31.01.2019 um 21:10 schrieb Craig Scott <craig.scott at crascit.com>:
> >
> > This is precisely the scenario that the
> CMAKE_TRY_COMPILE_PLATFORM_VARIABLES variable is meant for. It allows a
> toolchain file to specify additional variables that should be passed along
> to try_compile().
>
> Works like a charm. Thanks a lot!
>
> Torsten
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190201/6000a9d1/attachment.html>

From andrew.bell.ia at gmail.com  Fri Feb  1 16:18:28 2019
From: andrew.bell.ia at gmail.com (Andrew Bell)
Date: Fri, 1 Feb 2019 16:18:28 -0500
Subject: [CMake] FindOpenSSL.cmake
Message-ID: <CACJ51z2yDeqOYrQrmGCqwvSXcH2CQ2+U1A8Vx4arugdFBJ57fw@mail.gmail.com>

I have a system-provided SSL and I have a newer one that I have installed
via a packaging system.  In my build system I have:
find_package(OPENSSL 1.1) .  This properly finds the version 1.1 header
files for openSSL, but it finds the incompatible system libraries, which
are older than version 1.1.  A look at FindOpenSSL.cmake makes it seem as
if the version is used when finding the header files, but not the
libraries.  Other than overriding cache entries, is there a way to fix the
FindOpenSSL.cmake that would solve the problem?  Other suggestions?

-- 
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190201/b9fd53d7/attachment.html>

From hex7c3 at gmail.com  Fri Feb  1 17:15:26 2019
From: hex7c3 at gmail.com (hex)
Date: Fri, 1 Feb 2019 22:15:26 +0000
Subject: [CMake] undefined reference to `_exit'
Message-ID: <3f3c660f-3996-0bdf-781f-6d1d07f3ca0c@gmail.com>

hello,

I am trying to include a static library that contains the startup code 
for ARM processor to my? CMake project for cross compilation.

I included the linker script and added it to the executable. Flags and 
include files are properly set in the CMake build output. The path to 
the library is also correctly seen.

The linker fails on the startup code:


|Scanning dependencies of target testApp [ 50%] Building CXX object 
CMakeFiles/testApp.dir/src/main.c.obj [100%] Linking CXX executable 
testApp 
/opt/gcc-arm-none-eabi-7-2017-q4-major/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7-ar/fpv3/hard/libc.a(lib_a-exit.o): 
In function `exit': exit.c:(.text.exit+0x1c): undefined reference to 
`_exit' 
/opt/gcc-arm-none-eabi-7-2017-q4-major/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7-ar/fpv3/hard/libc.a(lib_a-fini.o): 
In function `__libc_fini_array': fini.c:(.text.__libc_fini_array+0x2c): 
undefined reference to `_fini' 
/opt/gcc-arm-none-eabi-7-2017-q4-major/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7-ar/fpv3/hard/libc.a(lib_a-init.o): 
In function `__libc_init_array': init.c:(.text.__libc_init_array+0x38): 
undefined reference to `_init' collect2: error: ld returned 1 exit 
status Here is my CMakeLists file: *cmake_minimum_required(VERSION 
3.5.1)****project (hello-world)******set(SOURCE_FILES 
src/main.c)******set (LINKER_SCRIPT 
linker_script.ld)******add_executable(${TARGET_NAME} 
${SOURCE_FILES})******set_target_properties( ${TARGET_NAME} PROPERTIES 
LINK_DEPENDS ${LINKER_SCRIPT})******set(CMAKE_EXE_LINKER_FLAGS 
"${CMAKE_EXE_LINKER_FLAGS} -Wl,-build-id=none -Wl,-T ${LINKER_SCRIPT} " 
CACHE STRING "" FORCE )******set(COMMON_FLAGS "${COMMON_FLAGS} 
-march=armv7-a")****set(COMMON_FLAGS "${COMMON_FLAGS} 
-mfpu=vfpv3")****set(COMMON_FLAGS "${COMMON_FLAGS} 
-mfloat-abi=hard")****set(COMMON_FLAGS "${COMMON_FLAGS} 
-Wall")****set(COMMON_FLAGS "${COMMON_FLAGS} -O0")****set(COMMON_FLAGS 
"${COMMON_FLAGS} -nostartfiles")****set(COMMON_FLAGS "${COMMON_FLAGS} 
-fmessage-length=0")****set(COMMON_FLAGS "${COMMON_FLAGS} 
-fno-exceptions")****set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} 
${COMMON_FLAGS}")****set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} 
${COMMON_FLAGS}")******include_directories( inc 
)******find_library(LIB_C NAMES libc PATHS "lib" 
)******target_link_libraries(${TARGET_NAME} ${LIB_C})*** How can I solve 
this problem? The only dependency here is the library itself... Thank 
you in advance for any response. |

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190201/51056043/attachment.html>

From kyle.edwards at kitware.com  Fri Feb  1 18:03:26 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Fri, 01 Feb 2019 18:03:26 -0500
Subject: [CMake] FindOpenSSL.cmake
In-Reply-To: <CACJ51z2yDeqOYrQrmGCqwvSXcH2CQ2+U1A8Vx4arugdFBJ57fw@mail.gmail.com>
References: <CACJ51z2yDeqOYrQrmGCqwvSXcH2CQ2+U1A8Vx4arugdFBJ57fw@mail.gmail.com>
Message-ID: <1549062206.24928.68.camel@kitware.com>

Andrew,
FindOpenSSL provides an "OPENSSL_ROOT_DIR" variable which allows you to
specify the root directory of your installation (assuming a traditional
layout within that directory.) Hopefully this will do what you need.
Good luck!
Kyle
On Fri, 2019-02-01 at 16:18 -0500, Andrew Bell wrote:
> I have a system-provided SSL and I have a newer one that I have
> installed via a packaging system.? In my build system I have:
> find_package(OPENSSL?1.1) .? This properly finds the version 1.1
> header files for openSSL, but it finds the incompatible system
> libraries, which are older than version 1.1.? A look at
> FindOpenSSL.cmake makes it seem as if the version is used when
> finding the header files, but not the libraries.? Other than
> overriding cache entries, is there a way to fix the
> FindOpenSSL.cmake?that would solve the problem?? Other suggestions?
> 
> --?
> 
> 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/op
> ensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190201/1a4db7d8/attachment.html>

From kyle.edwards at kitware.com  Fri Feb  1 18:17:43 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Fri, 01 Feb 2019 18:17:43 -0500
Subject: [CMake] undefined reference to `_exit'
In-Reply-To: <3f3c660f-3996-0bdf-781f-6d1d07f3ca0c@gmail.com>
References: <3f3c660f-3996-0bdf-781f-6d1d07f3ca0c@gmail.com>
Message-ID: <1549063063.24928.76.camel@kitware.com>

Hex,
Can you see what else is in /opt/arm-none-eabi/lib/thumb/v7-
ar/fpv3/hard (the same directory as libc.a)? There might be another
system library that contains the _exit() implementation that isn't
being linked due to your use of the -nostartfiles flag.
Kyle
On Fri, 2019-02-01 at 22:15 +0000, hex wrote:
> hello,?
> I am trying to include a static library that contains the startup
> code for ARM processor to my? CMake project for cross compilation.?
> I included the linker script and added it to the executable. Flags
> and include files are properly set in the CMake build output. The
> path to the library is also correctly seen.?
> The linker fails on the startup code:
> 
> Scanning dependencies of target testApp
> [ 50%] Building CXX object CMakeFiles/testApp.dir/src/main.c.obj
> [100%] Linking CXX executable testApp
> /opt/gcc-arm-none-eabi-7-2017-q4-major/bin/../lib/gcc/arm-none-
> eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7-
> ar/fpv3/hard/libc.a(lib_a-exit.o): In function `exit':
> exit.c:(.text.exit+0x1c): undefined reference to `_exit'
> /opt/gcc-arm-none-eabi-7-2017-q4-major/bin/../lib/gcc/arm-none-
> eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7-
> ar/fpv3/hard/libc.a(lib_a-fini.o): In function `__libc_fini_array':
> fini.c:(.text.__libc_fini_array+0x2c): undefined reference to `_fini'
> /opt/gcc-arm-none-eabi-7-2017-q4-major/bin/../lib/gcc/arm-none-
> eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7-
> ar/fpv3/hard/libc.a(lib_a-init.o): In function `__libc_init_array':
> init.c:(.text.__libc_init_array+0x38): undefined reference to `_init'
> collect2: error: ld returned 1 exit status
> 
> 
> Here is my CMakeLists file:
> 
> cmake_minimum_required(VERSION 3.5.1)
> project (hello-world)
> 
> set(SOURCE_FILES src/main.c)
> 
> set (LINKER_SCRIPT linker_script.ld)
> 
> add_executable(${TARGET_NAME} ${SOURCE_FILES})
> 
> set_target_properties( ${TARGET_NAME} PROPERTIES LINK_DEPENDS
> ${LINKER_SCRIPT})
> 
> set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-build-
> id=none -Wl,-T ${LINKER_SCRIPT} " CACHE STRING "" FORCE )
> 
> set(COMMON_FLAGS "${COMMON_FLAGS} -march=armv7-a")
> set(COMMON_FLAGS "${COMMON_FLAGS} -mfpu=vfpv3")
> set(COMMON_FLAGS "${COMMON_FLAGS} -mfloat-abi=hard")
> set(COMMON_FLAGS "${COMMON_FLAGS} -Wall")
> set(COMMON_FLAGS "${COMMON_FLAGS} -O0")
> set(COMMON_FLAGS "${COMMON_FLAGS} -nostartfiles")
> set(COMMON_FLAGS "${COMMON_FLAGS} -fmessage-length=0")
> set(COMMON_FLAGS "${COMMON_FLAGS} -fno-exceptions")
> set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${COMMON_FLAGS}")
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${COMMON_FLAGS}")
> 
> include_directories( inc )
> 
> find_library(LIB_C NAMES libc PATHS "lib" )
> 
> target_link_libraries(${TARGET_NAME} ${LIB_C})
> 
> 
> How can I solve this problem? The only dependency here is the library
> itself...
> 
> Thank you in advance for any response.?
> --?
> 
> 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/op
> ensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190201/4425b80f/attachment-0001.html>

From frodak17 at gmail.com  Sat Feb  2 00:26:56 2019
From: frodak17 at gmail.com (frodak17)
Date: Sat, 2 Feb 2019 00:26:56 -0500
Subject: [CMake] undefined reference to `_exit'
In-Reply-To: <1549063063.24928.76.camel@kitware.com>
References: <3f3c660f-3996-0bdf-781f-6d1d07f3ca0c@gmail.com>
 <1549063063.24928.76.camel@kitware.com>
Message-ID: <CAM_JqVm=rr-YdneAcBwtuVkr+y2Ykbqie9t7TmZ4zB3bLXCTtw@mail.gmail.com>

If I follow you correctly you are trying to replace the startup files that
are normally used with your own versions.

You don't mention what the new library is that you are using to replace the
startup files.
The standard startup files provide _init and _fini.

You are also missing _exit which I thought would have been taken care of if
"-specs=nosys.specs" was being used.  It's not shown which specs option is
being used.

Any reason you aren't just using the standard startup files and follow the
retarget example to do any special initialization before main() is called?

On Fri, Feb 1, 2019 at 6:17 PM Kyle Edwards via CMake <cmake at cmake.org>
wrote:

> Hex,
>
> Can you see what else is in /opt/arm-none-eabi/lib/thumb/v7-ar/fpv3/hard
> (the same directory as libc.a)? There might be another system library that
> contains the _exit() implementation that isn't being linked due to your use
> of the -nostartfiles flag.
>
> Kyle
>
> On Fri, 2019-02-01 at 22:15 +0000, hex wrote:
>
> hello,
>
> I am trying to include a static library that contains the startup code for
> ARM processor to my  CMake project for cross compilation.
>
> I included the linker script and added it to the executable. Flags and
> include files are properly set in the CMake build output. The path to the
> library is also correctly seen.
>
> The linker fails on the startup code:
>
>
> Scanning dependencies of target testApp
> [ 50%] Building CXX object CMakeFiles/testApp.dir/src/main.c.obj
> [100%] Linking CXX executable testApp
> /opt/gcc-arm-none-eabi-7-2017-q4-major/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7-ar/fpv3/hard/libc.a(lib_a-exit.o): In function `exit':
> exit.c:(.text.exit+0x1c): undefined reference to `_exit'
> /opt/gcc-arm-none-eabi-7-2017-q4-major/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7-ar/fpv3/hard/libc.a(lib_a-fini.o): In function `__libc_fini_array':
> fini.c:(.text.__libc_fini_array+0x2c): undefined reference to `_fini'
> /opt/gcc-arm-none-eabi-7-2017-q4-major/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7-ar/fpv3/hard/libc.a(lib_a-init.o): In function `__libc_init_array':
> init.c:(.text.__libc_init_array+0x38): undefined reference to `_init'
> collect2: error: ld returned 1 exit status
>
>
> Here is my CMakeLists file:
> *cmake_minimum_required(VERSION 3.5.1)**project (hello-world)**set(SOURCE_FILES src/main.c)**set (LINKER_SCRIPT linker_script.ld)**add_executable(${TARGET_NAME} ${SOURCE_FILES})**set_target_properties( ${TARGET_NAME} PROPERTIES LINK_DEPENDS ${LINKER_SCRIPT})**set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-build-id=none -Wl,-T ${LINKER_SCRIPT} " CACHE STRING "" FORCE )**set(COMMON_FLAGS "${COMMON_FLAGS} -march=armv7-a")**set(COMMON_FLAGS "${COMMON_FLAGS} -mfpu=vfpv3")**set(COMMON_FLAGS "${COMMON_FLAGS} -mfloat-abi=hard")**set(COMMON_FLAGS "${COMMON_FLAGS} -Wall")**set(COMMON_FLAGS "${COMMON_FLAGS} -O0")**set(COMMON_FLAGS "${COMMON_FLAGS} -nostartfiles")**set(COMMON_FLAGS "${COMMON_FLAGS} -fmessage-length=0")**set(COMMON_FLAGS "${COMMON_FLAGS} -fno-exceptions")**set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${COMMON_FLAGS}")**set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${COMMON_FLAGS}")**include_directories( inc )**find_library(LIB_C NAMES libc PATHS "lib" )**target_link_libraries(${TARGET_NAME} ${LIB_C})*
>
> How can I solve this problem? The only dependency here is the library itself...
>
> Thank you in advance for any response.
>
> --
>
> 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:https://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:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190202/7a6e3541/attachment.html>

From andrew.pennebaker at gmail.com  Sun Feb  3 22:21:37 2019
From: andrew.pennebaker at gmail.com (Andrew Pennebaker)
Date: Sun, 3 Feb 2019 21:21:37 -0600
Subject: [CMake] patches for MirOS
Message-ID: <CAHXt_SWS2ejKix4oAC0DW+ZnFZS-WGmj+_pxd20dNUcrzMUmQg@mail.gmail.com>

Hiya!

I got cmake to build in MirOS (also known as MirBSD) v10 this weekend,
painting over gaps in POSIX support. Here's my patchset:

https://github.com/mcandre/vagrant-miros-cmake/tree/master/i386

Virtual machines are included for testing the patched build, and for
testing the final cmake binary.

Note, this patchset targets cmake v3.9.0-. That's the first version I
happened to snag that doesn't depend on C++11 support. Evidently MirOS's
standard compiler, mgcc, has not offered C++11 support since it was
released way back during the 2008 financial crisis (!)

Could we add these fixes to the 3.9 series so that MirOS users get better
access to cmake?

-- 
Cheers,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190203/30cc3738/attachment.html>

From Torsten at Robitzki.de  Mon Feb  4 01:42:58 2019
From: Torsten at Robitzki.de (Torsten at Robitzki.de)
Date: Mon, 4 Feb 2019 07:42:58 +0100
Subject: [CMake] Checking Variables in a tool-chain file
In-Reply-To: <CAM_JqVnX0uUXKYQKWKD95mp2fWQ6QHp9gwJtOdgQciYPCepziA@mail.gmail.com>
References: <4D77F615-3D1A-410F-BA81-08CB6FAF8CAC@Robitzki.de>
 <CAE7Ac0BPkK7KvUB388XogO7_bPaA=B5ON+vE4RXHGyJCH0NrLA@mail.gmail.com>
 <19158EA8-E576-4D64-B245-B366FB37BD11@Robitzki.de>
 <7CA3C5F3-D472-412B-8D55-98F3FC4B1F13@fb.com>
 <CA+dygYmJKt8aVUtxaNXXvOyebKLum-bzngxZ1G+7KCKjgv8K-A@mail.gmail.com>
 <7CCB109D-5BD0-4F47-BC67-1D15190EDE37@Robitzki.de>
 <CAM_JqVnX0uUXKYQKWKD95mp2fWQ6QHp9gwJtOdgQciYPCepziA@mail.gmail.com>
Message-ID: <50ECA6EB-4EA4-477A-A0F3-28369115C85B@Robitzki.de>

Hi,

> Am 01.02.2019 um 17:17 schrieb frodak17 <frodak17 at gmail.com>:
> 
> Be aware that CMAKE_TRY_COMPILE_PLATFORM_VARIABLES only works with the try_compile() command source file signature. Unfortunately it doesn't work with try_compile() whole projects signature.  The section on Other Behavior Settings mostly only applies to the source file signature.

can you give me some details on the consequences? I?ve inserted following test into my tool-chain file (https://github.com/TorstenRobitzki/bluetoe/pull/39/commits/6067e808486c8421e6f3bf3a5dd9c14ab8aa6474):


        set(CMAKE_TRY_COMPILE_PLATFORM_VARIABLES ARM_GCC_TOOL_PATH)

	if (NOT DEFINED ARM_GCC_TOOL_PATH)
	    message(FATAL_ERROR "To configure the arm-none-eabi-gcc correctly, please set ARM_GCC_TOOL_PATH to the path that contains the bin directory of your GCC installation.")
	elseif(NOT EXISTS ${tools}/bin)
	    message(FATAL_ERROR "To configure the arm-none-eabi-gcc correctly, please set ARM_GCC_TOOL_PATH to the path that contains the bin directory of your GCC installation.")
	endif()

Will this fail eventually?

kind regards,

Torsten

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://cmake.org/pipermail/cmake/attachments/20190204/c6121579/attachment.sig>

From robert.maynard at kitware.com  Mon Feb  4 08:19:46 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 4 Feb 2019 08:19:46 -0500
Subject: [CMake] [ANNOUNCE] CMake 3.13.4 available for download
Message-ID: <CAFzjYVqORZZ=CB41hBVokdjtGMZBV9zZAQpJ_+BMbj67zHHFwQ@mail.gmail.com>

We are pleased to announce that CMake 3.13.4 is now available for download.

Please use the latest release from our download page:
  https://cmake.org/download/

Thanks for your support!

-------------------------------------------------------------------------
Changes in 3.13.4 since 3.13.3:

Ben Boeckel (2):
  Tests: add cases for providing Qt5Core_VERSION manually
  AutoGen: query Qt5 version from directory properties

Brad King (5):
  Revert "file: Allow DOWNLOAD/UPLOAD using alternate authentication methods"
  Intel: Record support for relaxed constexpr by version 18.0.5
  macOS: Restore compatibility for setting FRAMEWORK after install()
  FindLAPACK: Distinguish check result variable name from FindBLAS
  CMake 3.13.4

Chuck Atkins (1):
  macOS: Add missing explicit dependency on CoreServices framework

Craig Scott (3):
  cmake: Convert no source/build dir error to warning
  Help: Add 3.13.4 release note for no source/build dir error/warning
  FindDoxygen: Escape backslashes in default values

From Felix.Ramold at kuka.com  Mon Feb  4 10:09:21 2019
From: Felix.Ramold at kuka.com (Ramold, Felix)
Date: Mon, 4 Feb 2019 15:09:21 +0000
Subject: [CMake] --warn-uninitialized works in only first configuration
Message-ID: <7126da2cd50e4c4f97216dee94f39a8a@DEAU1SVMAIL03.kuka.int.kuka.com>

Hi,

I configure a project with --warn-uninitialized and get a lot of warnings. I successfully run the build.
Then I change any CMakeLists.txt file. I run the build again. CMake checks its dependencies and reconfigures before the actual build.
Those warnings (or at least those in the edited file) don't appear again.
Is this the standard behavior?

Thanks,
Felix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190204/394a3e62/attachment.html>

From hex7c3 at gmail.com  Mon Feb  4 10:35:43 2019
From: hex7c3 at gmail.com (hex)
Date: Mon, 4 Feb 2019 15:35:43 +0000
Subject: [CMake] undefined reference to `_exit'
In-Reply-To: <CAM_JqVm=rr-YdneAcBwtuVkr+y2Ykbqie9t7TmZ4zB3bLXCTtw@mail.gmail.com>
References: <3f3c660f-3996-0bdf-781f-6d1d07f3ca0c@gmail.com>
 <1549063063.24928.76.camel@kitware.com>
 <CAM_JqVm=rr-YdneAcBwtuVkr+y2Ykbqie9t7TmZ4zB3bLXCTtw@mail.gmail.com>
Message-ID: <19295795-7d15-c162-bf06-3835c57fcb72@gmail.com>

dear community,

This question has originally been placed in another community [1].
I did read the mailing list netiquette before posting here but I was not 
aware this behaviour is discouraged.
Therefore, I want to apologize. Good etiquette is important, I am 
grateful for any advice on how I can make the Internet a better place.

The solution to the undefined reference errors is to set the

-specs=nosys.specs flag as mentioned here [2]
in combination with not using the -nostartfiles flag which made the 
_exit referenced in nosys.specs not being used.

Since this is also making this question a duplicate of [2] I decided to 
delete it in stackoverflow.

Thank you for your help.


[1] 
https://stackoverflow.com/questions/54487747/cmake-undefined-reference-to-exit-while-including-startup-code-as-a-library
[2] 
https://stackoverflow.com/questions/19419782/exit-c-text0x18-undefined-reference-to-exit-when-using-arm-none-eabi-gcc



From robert.maynard at kitware.com  Mon Feb  4 12:15:37 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Mon, 4 Feb 2019 12:15:37 -0500
Subject: [CMake] --warn-uninitialized works in only first configuration
In-Reply-To: <7126da2cd50e4c4f97216dee94f39a8a@DEAU1SVMAIL03.kuka.int.kuka.com>
References: <7126da2cd50e4c4f97216dee94f39a8a@DEAU1SVMAIL03.kuka.int.kuka.com>
Message-ID: <CAFzjYVoTHj79UNGepbkE0pOcHYqmHTuVi+7LNkzVBA8QdZvWoQ@mail.gmail.com>

This generally occurs with CACHE variables as for non first runs they
exist in the cache and therefore are initialized.

On Mon, Feb 4, 2019 at 10:16 AM Ramold, Felix <Felix.Ramold at kuka.com> wrote:
>
> Hi,
>
>
>
> I configure a project with --warn-uninitialized and get a lot of warnings. I successfully run the build.
>
> Then I change any CMakeLists.txt file. I run the build again. CMake checks its dependencies and reconfigures before the actual build.
>
> Those warnings (or at least those in the edited file) don?t appear again.
>
> Is this the standard behavior?
>
>
>
> Thanks,
>
> Felix
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake

From djobet at tower-research.com  Tue Feb  5 05:05:55 2019
From: djobet at tower-research.com (David Jobet)
Date: Tue, 5 Feb 2019 10:05:55 +0000
Subject: [CMake] Building a repo with multiple applications and install
 process
Message-ID: <CAAV-JT7MCD3=2ToYgSw225vnm0E=QYb=pmct3qNPpaEwFKCZtg@mail.gmail.com>

Hello,

at work, we have a mono-repo with multiple applications/libs (dozens).
The build phase is ok, but I'm not sure about the release process.

When we release, we release one application at a time.
(CMAKE_SKIP_INSTALL_ALL_DEPENDENCY is true)
In order to speed up releases, we always perform an incremental build.

Unfortunately, we don't have one unique release process :
process 1 :
- a Jenkins pipeline executes some automatic tests then release the
binary to production. This Jenkins pipeline only builds this single
application, then executes the install step, then packages the binary
with some auxiliary files for deployment in prod.
process 2 :
- the whole source tree is built regularly through Jenkins, then, from
another Jenkins pipeline, an install step will be performed in the
last built directory to deploy only the required application

Both process 1 and process 2 are built in our CMakeLists.txt.

Process 1 just uses regular install directives + ninja install
Pros : simple
Cons : install step can be costly

Install step can be costly because, as the build directory is not
emptied, the install step will install every single binaries left over
from a previous build that have an install rule.
Also, we have install directives for non binary files (python files
for example) which will be installed unconditionally every time.

Process 2 is not triggered through the install step but as a regular
build target. Under the hood, the build step will add a POST_BUILD
step attached to the target that will invoke "cmake -P
${CMAKE_BINARY_DIR}/cmake_install.cmake -DCOMPONENT=${component}"
Pros : more "chirurgical", only install what's required
Cons : - if an application depends on several components, we need to
describe this in cmake (dependencies are described twice : once for
the build, once for the install)
       - need to maintain an extra "non standard" layer (albeit a small layer)

At this point, I'd like to ask if you see simple steps we could take
to stay as simple and standard as possible without paying the cons
(lenghty install step, double description of dependencies, extra layer
to maintain).

I have a proposal of my own, I'm just not sure this is technically
feasible. I will definitively run a POC sometime, but I thought I
would run it by you first to get your advice/experience.

So maybe the problem is we have one monolithic CMake system where all
apps are described.
What if every single application had its own independent CMake system
(while still being able to depend on common libs, that needs to be
built only once) ?
One app would describe its dependencies, the install step would then
stay simple, and only the reachable install directives would be
triggered in a per-app build.

Is it something which is feasible ? How would you implement it ? (I
thought about ExternalProject_Add but have no experience with it and
I'm not sure it would work in that case ?)

Also, we would still need to be able to build all applications in one
single command.
Do you think creating a "meta" cmake, equivalent to what we have right
now, but on top of those independent, per-app cmake, is feasible ?
(Again, I guess using ExternalProject_Add) ?

Thanks very much for your help

David

From pseyfert.cern.hsf.cwp at gmail.com  Tue Feb  5 05:44:19 2019
From: pseyfert.cern.hsf.cwp at gmail.com (Paul Seyfert)
Date: Tue, 5 Feb 2019 11:44:19 +0100
Subject: [CMake] manipulating tests that are defined in a subdir
Message-ID: <CAFToWva1hN_+xSG90jbTz5axi_tuAS6NPCQZTEUDPjnRc3kSGw@mail.gmail.com>

Dear all,
(essentially asking what I already posted on SO
https://stackoverflow.com/questions/54447765)

I have a my_project/CMakeLists.txt file under my control. In its directory
there is also a git submodule (say 'my_project/sub' for now), and I add the
git-submodule on the cmake level though add_subdirectory(sub). The
submodule is not under my control (well, I can fork it of cause, but we'd
prefer not to have diverging branches, and the other way around, we don't
want to pollute the submodule with my-project specific stuff).
Because of my (admittedly strange) production platform, the tests from sub
fail in my project.

I can fix that by changing properties of the tests with
`set_tests_properties(test_in_sub PROPERTIES ...)`.

However since the tests are defined in my_project/sub/CMakeLists.txt and I
don't want to have my_project specific bodges in sub, I would like to call
set_tests_properties from my_project/CMakeLists.txt.

When trying to do so, cmake reports that the test I'm trying to manipulate
wouldn't exist. Things work when I call `add_test` and
`set_tests_properties` from the same CMakeLists.txt file.

My question thus is: Is it possible to call `set_tests_properties` for a
test that is `add_test`ed in a different CMakeLists.txt file, and if so
how? (Well, and if not, I'm happy for other suggestions)

Thanks in advance,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190205/3341b3a8/attachment.html>

From Felix.Ramold at kuka.com  Tue Feb  5 12:08:28 2019
From: Felix.Ramold at kuka.com (Ramold, Felix)
Date: Tue, 5 Feb 2019 17:08:28 +0000
Subject: [CMake] --warn-uninitialized works in only first configuration
In-Reply-To: <CAFzjYVoTHj79UNGepbkE0pOcHYqmHTuVi+7LNkzVBA8QdZvWoQ@mail.gmail.com>
References: <7126da2cd50e4c4f97216dee94f39a8a@DEAU1SVMAIL03.kuka.int.kuka.com>
 <CAFzjYVoTHj79UNGepbkE0pOcHYqmHTuVi+7LNkzVBA8QdZvWoQ@mail.gmail.com>
Message-ID: <bd9d2e5155fc401294aecb8cd85a8376@DEAU1SVMAIL03.kuka.int.kuka.com>

It is not a cache variable. Here is an example:

cmake_minimum_required(VERSION 3.10)
project(TEST_UNINITIALIZED)

file(WRITE dummy.cpp "")
add_library(dummy dummy.cpp ${UNINITIALIZED})

Also UNINITIALIZED is not added to CMakeCache.txt.
Calling cmake twice (even without a change to the list) also shows this warning.

-----Urspr?ngliche Nachricht-----
Von: Robert Maynard [mailto:robert.maynard at kitware.com] 
Gesendet: Montag, 4. Februar 2019 18:16
An: Ramold, Felix
Cc: cmake at cmake.org
Betreff: Re: [CMake] --warn-uninitialized works in only first configuration

This generally occurs with CACHE variables as for non first runs they
exist in the cache and therefore are initialized.

On Mon, Feb 4, 2019 at 10:16 AM Ramold, Felix <Felix.Ramold at kuka.com> wrote:
>
> Hi,
>
>
>
> I configure a project with --warn-uninitialized and get a lot of warnings. I successfully run the build.
>
> Then I change any CMakeLists.txt file. I run the build again. CMake checks its dependencies and reconfigures before the actual build.
>
> Those warnings (or at least those in the edited file) don?t appear again.
>
> Is this the standard behavior?
>
>
>
> Thanks,
>
> Felix
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: terminal.txt
URL: <https://cmake.org/pipermail/cmake/attachments/20190205/67eeab5e/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CMakeLists.txt
URL: <https://cmake.org/pipermail/cmake/attachments/20190205/67eeab5e/attachment-0001.txt>

From robert.maynard at kitware.com  Tue Feb  5 13:21:19 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 5 Feb 2019 13:21:19 -0500
Subject: [CMake] --warn-uninitialized works in only first configuration
In-Reply-To: <bd9d2e5155fc401294aecb8cd85a8376@DEAU1SVMAIL03.kuka.int.kuka.com>
References: <7126da2cd50e4c4f97216dee94f39a8a@DEAU1SVMAIL03.kuka.int.kuka.com>
 <CAFzjYVoTHj79UNGepbkE0pOcHYqmHTuVi+7LNkzVBA8QdZvWoQ@mail.gmail.com>
 <bd9d2e5155fc401294aecb8cd85a8376@DEAU1SVMAIL03.kuka.int.kuka.com>
Message-ID: <CAFzjYVoW3ow4Gu+oGx6UAVnR-+=FjBTFpGSOkgtf=Au+GVd3wg@mail.gmail.com>

Okay now I understand.

Yes this is the intended behavior of `--warn-uninitialized`.

It is designed so that it will only generate warnings for the explicit
invocation of cmake that includes the flag. Subsequent calls to
`cmake` without `--warn-uninitialized` will generate no warnings.

On Tue, Feb 5, 2019 at 12:08 PM Ramold, Felix <Felix.Ramold at kuka.com> wrote:
>
> It is not a cache variable. Here is an example:
>
> cmake_minimum_required(VERSION 3.10)
> project(TEST_UNINITIALIZED)
>
> file(WRITE dummy.cpp "")
> add_library(dummy dummy.cpp ${UNINITIALIZED})
>
> Also UNINITIALIZED is not added to CMakeCache.txt.
> Calling cmake twice (even without a change to the list) also shows this warning.
>
> -----Urspr?ngliche Nachricht-----
> Von: Robert Maynard [mailto:robert.maynard at kitware.com]
> Gesendet: Montag, 4. Februar 2019 18:16
> An: Ramold, Felix
> Cc: cmake at cmake.org
> Betreff: Re: [CMake] --warn-uninitialized works in only first configuration
>
> This generally occurs with CACHE variables as for non first runs they
> exist in the cache and therefore are initialized.
>
> On Mon, Feb 4, 2019 at 10:16 AM Ramold, Felix <Felix.Ramold at kuka.com> wrote:
> >
> > Hi,
> >
> >
> >
> > I configure a project with --warn-uninitialized and get a lot of warnings. I successfully run the build.
> >
> > Then I change any CMakeLists.txt file. I run the build again. CMake checks its dependencies and reconfigures before the actual build.
> >
> > Those warnings (or at least those in the edited file) don?t appear again.
> >
> > Is this the standard behavior?
> >
> >
> >
> > Thanks,
> >
> > Felix
> >
> > --
> >
> > 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:
> > https://cmake.org/mailman/listinfo/cmake

From frodak17 at gmail.com  Tue Feb  5 13:28:19 2019
From: frodak17 at gmail.com (frodak17)
Date: Tue, 5 Feb 2019 13:28:19 -0500
Subject: [CMake] --warn-uninitialized works in only first configuration
In-Reply-To: <bd9d2e5155fc401294aecb8cd85a8376@DEAU1SVMAIL03.kuka.int.kuka.com>
References: <7126da2cd50e4c4f97216dee94f39a8a@DEAU1SVMAIL03.kuka.int.kuka.com>
 <CAFzjYVoTHj79UNGepbkE0pOcHYqmHTuVi+7LNkzVBA8QdZvWoQ@mail.gmail.com>
 <bd9d2e5155fc401294aecb8cd85a8376@DEAU1SVMAIL03.kuka.int.kuka.com>
Message-ID: <CAM_JqV=VrUK0k=_-7407ENJdVzqp1b4L0NeXixs15dkM=TtiaQ@mail.gmail.com>

When you run `cmake --build Build` it doesn't run cmake with the
--warn-uninitialized
if the build files need to be regenerated.  Therefore you don't get the
warnings.

On Tue, Feb 5, 2019 at 12:15 PM Ramold, Felix <Felix.Ramold at kuka.com> wrote:

> It is not a cache variable. Here is an example:
>
> cmake_minimum_required(VERSION 3.10)
> project(TEST_UNINITIALIZED)
>
> file(WRITE dummy.cpp "")
> add_library(dummy dummy.cpp ${UNINITIALIZED})
>
> Also UNINITIALIZED is not added to CMakeCache.txt.
> Calling cmake twice (even without a change to the list) also shows this
> warning.
>
> -----Urspr?ngliche Nachricht-----
> Von: Robert Maynard [mailto:robert.maynard at kitware.com]
> Gesendet: Montag, 4. Februar 2019 18:16
> An: Ramold, Felix
> Cc: cmake at cmake.org
> Betreff: Re: [CMake] --warn-uninitialized works in only first configuration
>
> This generally occurs with CACHE variables as for non first runs they
> exist in the cache and therefore are initialized.
>
> On Mon, Feb 4, 2019 at 10:16 AM Ramold, Felix <Felix.Ramold at kuka.com>
> wrote:
> >
> > Hi,
> >
> >
> >
> > I configure a project with --warn-uninitialized and get a lot of
> warnings. I successfully run the build.
> >
> > Then I change any CMakeLists.txt file. I run the build again. CMake
> checks its dependencies and reconfigures before the actual build.
> >
> > Those warnings (or at least those in the edited file) don?t appear again.
> >
> > Is this the standard behavior?
> >
> >
> >
> > Thanks,
> >
> > Felix
> >
> > --
> >
> > 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:
> > https://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:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190205/c700d2ef/attachment-0001.html>

From jasteph at sandia.gov  Tue Feb  5 14:20:10 2019
From: jasteph at sandia.gov (Stephens, J. Adam)
Date: Tue, 5 Feb 2019 19:20:10 +0000
Subject: [CMake] Linking to boost on OS X 10.12
Message-ID: <F3952296-66F1-4BE1-B54D-EE932B2511DA@contoso.com>

Hello,

The project I work on links to several shared boost libraries. After our organization disallowed use of OS X 10.11 and we upgraded our built/test slave to 10.12, we encountered a problem with our testing. Executables in the build tree that were built as part of our project now fail to run with the error that boost libraries can?t be found.

Superficially, the problem is that (I think) Apple strengthened the SIP between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any effect ? previously the linker was able to locate the boost libs for our build tree executables that way.

The deeper problem is twofold: First, the build tree executables don?t include the boost lib folder in their RPATHs. Second, the install names embedded in boost libs themselves are just the bare filenames with no @rpath. (My understanding is, the boost project does that deliberately because they can?t know what users of their libraries will want.)

Recent versions of CMake (3.8+) have the property BUILD_RPATH that we could use to embed the path to the boost libs into the build tree executables. That doesn?t solve the second part of the problem, though. Without embedding install names that look like @rpath/libboost_foo.dylib in the build tree executables, I think the linker will still be unable to find them.

What is the best (or least bad) way to fix this?

Thanks!

Adam

--
J. Adam Stephens, Ph.D.
Dakota Support Analyst
https://dakota.sandia.gov/
Optimization and UQ
Sandia National Laboratories
Albuquerque, NM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190205/fad35a3b/attachment.html>

From robert.maynard at kitware.com  Tue Feb  5 16:52:50 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 5 Feb 2019 16:52:50 -0500
Subject: [CMake] patches for MirOS
In-Reply-To: <CAHXt_SWS2ejKix4oAC0DW+ZnFZS-WGmj+_pxd20dNUcrzMUmQg@mail.gmail.com>
References: <CAHXt_SWS2ejKix4oAC0DW+ZnFZS-WGmj+_pxd20dNUcrzMUmQg@mail.gmail.com>
Message-ID: <CAFzjYVpOX=LByBZtxrkQuHdnw5kjXKnWV+XGFEnPVN-1Rh1oOA@mail.gmail.com>

As a general policy CMake doesn't offer patch releases of older
versions, and instead recommends updating to the latest CMake version.


On Sun, Feb 3, 2019 at 10:21 PM Andrew Pennebaker
<andrew.pennebaker at gmail.com> wrote:
>
> Hiya!
>
> I got cmake to build in MirOS (also known as MirBSD) v10 this weekend, painting over gaps in POSIX support. Here's my patchset:
>
> https://github.com/mcandre/vagrant-miros-cmake/tree/master/i386
>
> Virtual machines are included for testing the patched build, and for testing the final cmake binary.
>
> Note, this patchset targets cmake v3.9.0-. That's the first version I happened to snag that doesn't depend on C++11 support. Evidently MirOS's standard compiler, mgcc, has not offered C++11 support since it was released way back during the 2008 financial crisis (!)
>
> Could we add these fixes to the 3.9 series so that MirOS users get better access to cmake?
>
> --
> Cheers,
> Andrew
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake

From robert.maynard at kitware.com  Tue Feb  5 16:56:00 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 5 Feb 2019 16:56:00 -0500
Subject: [CMake] Linking to boost on OS X 10.12
In-Reply-To: <F3952296-66F1-4BE1-B54D-EE932B2511DA@contoso.com>
References: <F3952296-66F1-4BE1-B54D-EE932B2511DA@contoso.com>
Message-ID: <CAFzjYVrsHZsb=Ds+77KAt8GFHuOSdpXZGuRi1VWH8=9ja4pt7g@mail.gmail.com>

My general approach for the second problem is to run a tool such as
install_name_tool to change the library names to have @rpath when
constructing the package.

On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake
<cmake at cmake.org> wrote:
>
> Hello,
>
>
>
> The project I work on links to several shared boost libraries. After our organization disallowed use of OS X 10.11 and we upgraded our built/test slave to 10.12, we encountered a problem with our testing. Executables in the build tree that were built as part of our project now fail to run with the error that boost libraries can?t be found.
>
>
>
> Superficially, the problem is that (I think) Apple strengthened the SIP between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any effect ? previously the linker was able to locate the boost libs for our build tree executables that way.
>
>
>
> The deeper problem is twofold: First, the build tree executables don?t include the boost lib folder in their RPATHs. Second, the install names embedded in boost libs themselves are just the bare filenames with no @rpath. (My understanding is, the boost project does that deliberately because they can?t know what users of their libraries will want.)
>
>
>
> Recent versions of CMake (3.8+) have the property BUILD_RPATH that we could use to embed the path to the boost libs into the build tree executables. That doesn?t solve the second part of the problem, though. Without embedding install names that look like @rpath/libboost_foo.dylib in the build tree executables, I think the linker will still be unable to find them.
>
>
>
> What is the best (or least bad) way to fix this?
>
>
>
> Thanks!
>
>
>
> Adam
>
>
>
> --
>
> J. Adam Stephens, Ph.D.
>
> Dakota Support Analyst
>
> https://dakota.sandia.gov/
>
> Optimization and UQ
>
> Sandia National Laboratories
>
> Albuquerque, NM
>
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake

From jasteph at sandia.gov  Tue Feb  5 17:00:36 2019
From: jasteph at sandia.gov (Stephens, J. Adam)
Date: Tue, 5 Feb 2019 22:00:36 +0000
Subject: [CMake] [EXTERNAL] Re:  Linking to boost on OS X 10.12
In-Reply-To: <CAFzjYVrsHZsb=Ds+77KAt8GFHuOSdpXZGuRi1VWH8=9ja4pt7g@mail.gmail.com>
References: <F3952296-66F1-4BE1-B54D-EE932B2511DA@contoso.com>
 <CAFzjYVrsHZsb=Ds+77KAt8GFHuOSdpXZGuRi1VWH8=9ja4pt7g@mail.gmail.com>
Message-ID: <8F1E6D72-F7FD-4D05-805C-BB59EC5E2009@sandia.gov>

Hi Robert,

Thanks for your reply. We do use install_name_tool and the like when installing/packaging, and our packages continue to work fine on OS X 10.12. My question is about what to do with executables before packaging, while they are still just in the build tree. We need them to work for purposes of testing via CTest.

Adam
 

?On 2/5/19, 2:56 PM, "Robert Maynard" <robert.maynard at kitware.com> wrote:

    My general approach for the second problem is to run a tool such as
    install_name_tool to change the library names to have @rpath when
    constructing the package.
    
    On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake
    <cmake at cmake.org> wrote:
    >
    > Hello,
    >
    >
    >
    > The project I work on links to several shared boost libraries. After our organization disallowed use of OS X 10.11 and we upgraded our built/test slave to 10.12, we encountered a problem with our testing. Executables in the build tree that were built as part of our project now fail to run with the error that boost libraries can?t be found.
    >
    >
    >
    > Superficially, the problem is that (I think) Apple strengthened the SIP between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any effect ? previously the linker was able to locate the boost libs for our build tree executables that way.
    >
    >
    >
    > The deeper problem is twofold: First, the build tree executables don?t include the boost lib folder in their RPATHs. Second, the install names embedded in boost libs themselves are just the bare filenames with no @rpath. (My understanding is, the boost project does that deliberately because they can?t know what users of their libraries will want.)
    >
    >
    >
    > Recent versions of CMake (3.8+) have the property BUILD_RPATH that we could use to embed the path to the boost libs into the build tree executables. That doesn?t solve the second part of the problem, though. Without embedding install names that look like @rpath/libboost_foo.dylib in the build tree executables, I think the linker will still be unable to find them.
    >
    >
    >
    > What is the best (or least bad) way to fix this?
    >
    >
    >
    > Thanks!
    >
    >
    >
    > Adam
    >
    >
    >
    > --
    >
    > J. Adam Stephens, Ph.D.
    >
    > Dakota Support Analyst
    >
    > https://dakota.sandia.gov/
    >
    > Optimization and UQ
    >
    > Sandia National Laboratories
    >
    > Albuquerque, NM
    >
    >
    >
    > --
    >
    > 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:
    > https://cmake.org/mailman/listinfo/cmake
    


From robert.maynard at kitware.com  Tue Feb  5 17:05:30 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 5 Feb 2019 17:05:30 -0500
Subject: [CMake] [EXTERNAL] Re:  Linking to boost on OS X 10.12
In-Reply-To: <8F1E6D72-F7FD-4D05-805C-BB59EC5E2009@sandia.gov>
References: <F3952296-66F1-4BE1-B54D-EE932B2511DA@contoso.com>
 <CAFzjYVrsHZsb=Ds+77KAt8GFHuOSdpXZGuRi1VWH8=9ja4pt7g@mail.gmail.com>
 <8F1E6D72-F7FD-4D05-805C-BB59EC5E2009@sandia.gov>
Message-ID: <CAFzjYVr7GWUpZ+S84kKvUEGdDRL7h+pXepn7ZGQdi47X_2FYbQ@mail.gmail.com>

The version of the libraries that you load from your build directory
would need to be fixed up to.

On Tue, Feb 5, 2019 at 5:00 PM Stephens, J. Adam <jasteph at sandia.gov> wrote:
>
> Hi Robert,
>
> Thanks for your reply. We do use install_name_tool and the like when installing/packaging, and our packages continue to work fine on OS X 10.12. My question is about what to do with executables before packaging, while they are still just in the build tree. We need them to work for purposes of testing via CTest.
>
> Adam
>
>
> ?On 2/5/19, 2:56 PM, "Robert Maynard" <robert.maynard at kitware.com> wrote:
>
>     My general approach for the second problem is to run a tool such as
>     install_name_tool to change the library names to have @rpath when
>     constructing the package.
>
>     On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake
>     <cmake at cmake.org> wrote:
>     >
>     > Hello,
>     >
>     >
>     >
>     > The project I work on links to several shared boost libraries. After our organization disallowed use of OS X 10.11 and we upgraded our built/test slave to 10.12, we encountered a problem with our testing. Executables in the build tree that were built as part of our project now fail to run with the error that boost libraries can?t be found.
>     >
>     >
>     >
>     > Superficially, the problem is that (I think) Apple strengthened the SIP between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any effect ? previously the linker was able to locate the boost libs for our build tree executables that way.
>     >
>     >
>     >
>     > The deeper problem is twofold: First, the build tree executables don?t include the boost lib folder in their RPATHs. Second, the install names embedded in boost libs themselves are just the bare filenames with no @rpath. (My understanding is, the boost project does that deliberately because they can?t know what users of their libraries will want.)
>     >
>     >
>     >
>     > Recent versions of CMake (3.8+) have the property BUILD_RPATH that we could use to embed the path to the boost libs into the build tree executables. That doesn?t solve the second part of the problem, though. Without embedding install names that look like @rpath/libboost_foo.dylib in the build tree executables, I think the linker will still be unable to find them.
>     >
>     >
>     >
>     > What is the best (or least bad) way to fix this?
>     >
>     >
>     >
>     > Thanks!
>     >
>     >
>     >
>     > Adam
>     >
>     >
>     >
>     > --
>     >
>     > J. Adam Stephens, Ph.D.
>     >
>     > Dakota Support Analyst
>     >
>     > https://dakota.sandia.gov/
>     >
>     > Optimization and UQ
>     >
>     > Sandia National Laboratories
>     >
>     > Albuquerque, NM
>     >
>     >
>     >
>     > --
>     >
>     > 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:
>     > https://cmake.org/mailman/listinfo/cmake
>
>

From robert.maynard at kitware.com  Tue Feb  5 17:08:41 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 5 Feb 2019 17:08:41 -0500
Subject: [CMake] [SPAM] Re: resource installation
In-Reply-To: <763DC666-977D-4873-A4DC-7FD6DE12CE7E@datalogics.com>
References: <FCE08CDB-2FEB-466B-BA76-41AA4AD675D1@datalogics.com>
 <763DC666-977D-4873-A4DC-7FD6DE12CE7E@datalogics.com>
Message-ID: <CAFzjYVp5AghsbhMepScWuxAf5VWLkVmWQvvmKBZKTsG+-0s5Aw@mail.gmail.com>

If you add 'OUTPUT_VARIABLE' and 'ERROR_VARIABLE' information to the
execute_process call you should be able to dump the information using
'message' and see if the execute_process is running.


On Tue, Jan 29, 2019 at 3:04 PM Rob Boehne <robb at datalogics.com> wrote:
>
> I?m still not getting this script executed.  I can copy the ?message? output and run it ? and it does what I want, and I see it in cmake_install.cmake ? the message() and execute_process() calls are inside of identical conditionals, but there?s no indication that it is executing, or that there was any sort of problem.
>
> How do I get it to actually execute?
>
>
>
> In cmake_install.cmake:
>
>
>
> if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
>
>   message("running C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release")
>
> endif()
>
>
>
> if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
>
>   execute_process(COMMAND "C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release")
>
> endif()
>
>
>
>
>
> From: CMake <cmake-bounces at cmake.org> on behalf of Rob Boehne <robb at datalogics.com>
> Date: Thursday, January 24, 2019 at 9:49 AM
> To: "cmake at cmake.org" <cmake at cmake.org>
> Subject: [SPAM] Re: [CMake] resource installation
>
>
>
> Maybe because I misspelled it?  Yes.  Because I misspelled the script name.
>
>
>
> From: CMake <cmake-bounces at cmake.org> on behalf of Rob Boehne <robb at datalogics.com>
> Date: Thursday, January 24, 2019 at 9:40 AM
> To: "cmake at cmake.org" <cmake at cmake.org>
> Subject: [SPAM] [CMake] resource installation
>
>
>
> All,
>
>
>
> I?m attempting to install resource files (Fonts, etc.) into my product.  To that end, I have added this chunk of code to run a batch file that will copy resources into the tree:
>
>
>
> if(WIN32)
>
>     #
>
>     # run the script to install the resources
>
>     #
>
>     install(CODE "message(\"running ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")")
>
>     install(CODE "execute_process(COMMAND \"${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")")
>
> endif()
>
>
>
> I see the output of the first line when I run the INSTALL target in VS 2013, but it seems as though the script isn?t run.
>
> 1>  -- Install configuration: "RelWithDebInfo"
>
> 1>  running C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release
>
> 1>  -- Installing: C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/cmake_build/../dist/x64/release/CPlusPlus/Binaries/DL150BIBUtils.lib
>
>
>
> So the message is there, but the script isn?t run.
>
>
>
> I?m I missing a dependency, or formatting the string incorrectly?  How do I debug this?
>
>
>
> Thanks,
>
>
>
> Rob
>
>
>
>
>
> Rob Boehne
>
> Senior Software Architect | Datalogics, Inc.
>
> +1.312.853.8351 | robb at datalogics.com
>
> datalogics.com | blogs.datalogics.com
>
> Connect with us: Facebook | Twitter | LinkedIn | YouTube
>
>
>
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake

From robert.maynard at kitware.com  Tue Feb  5 17:12:07 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 5 Feb 2019 17:12:07 -0500
Subject: [CMake] cmake with vscode
In-Reply-To: <2c455381-3487-d362-836a-24113f7a6625@numalliance.com>
References: <2c455381-3487-d362-836a-24113f7a6625@numalliance.com>
Message-ID: <CAFzjYVooyxKX8_NxsS4Ueg1SA+vZ=qxWtcUFXKv91zLRW2MvLg@mail.gmail.com>

CMAKE_FIND_ROOT_PATH isn't meant to be used like that, you should use
CMAKE_PREFIX_PATH I expect.

ROOT_PATH represents the root of a new file-system/OS basically and is
meant for cross-compilation. While what you want is extra directories
to start searching from which is what CMAKE_PREFIX_PATH is designed
for.

On Tue, Jan 22, 2019 at 8:51 AM St?phane Ancelot
<sancelot at numalliance.com> wrote:
>
> Hi,
>
> I have got some problems finding packages under windows platform.
>
> I made a toolchain for VSCode and cmake 3.13 , but I don't understand why it fails to find almost all of my packages dependencies
>
> It is not able to find packages in the CMAKE_FIND_ROOT_PATH itself.
>
> If I try setting xx_LIBRARY and xx_INCLUDE_DIRS, if finds libs,  but this does not sound the right Way .
>
>
> Here is my toolchain :
>
> # the name of the target operating system
> SET(CMAKE_SYSTEM_NAME Windows)
>
> message(STATUS "bin dir ${CMAKE_BINARY_DIR}")
>
> # here is the target environment located
> SET(CMAKE_FIND_ROOT_PATH
>                         ${CMAKE_BINARY_DIR}\\WIN32DEPS\\xerces\\xerces-c-3.1.1-bin
>                         ${CMAKE_BINARY_DIR}\\WIN32DEPS\\JPEGLIB\\jpegsrc-9c
>                         ${CMAKE_BINARY_DIR}\\WIN32DEPS\\zlib-1.2.3-lib
>                         ${CMAKE_BINARY_DIR}\\WIN32DEPS\\libpng-1.2.37-lib
>                         ${CMAKE_BINARY_DIR}\\WIN32DEPS\\ftgl-binary
>                         ${CMAKE_BINARY_DIR}\\WIN32DEPS\\freetype-dev_2.4.2-1
>                         ${CMAKE_BINARY_DIR}\\WIN32DEPS\\iconv-1.9.2.1
>                         ${CMAKE_BINARY_DIR}\\WIN32DEPS\\Python26
>                         E:\\Qt\\5.9.5
>                         )
>
> # cmake 3.13
> set(FREETYPE_LIBRARY E:\\freetype-windows-binaries-master\\lib)
> set(FREETYPE_INCLUDE_DIRS E:\\freetype-windows-binaries-master\\include)
>
> set(FTGL_LIBRARY ${CMAKE_BINARY_DIR}\\WIN32DEPS\\ftgl-binary\\lib)
> set(FTGL_INCLUDE_DIRS ${CMAKE_BINARY_DIR}\\WIN32DEPS\\ftgl-binary\\include)
>
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake

From craig.scott at crascit.com  Tue Feb  5 17:20:30 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Wed, 6 Feb 2019 09:20:30 +1100
Subject: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12
In-Reply-To: <8F1E6D72-F7FD-4D05-805C-BB59EC5E2009@sandia.gov>
References: <F3952296-66F1-4BE1-B54D-EE932B2511DA@contoso.com>
 <CAFzjYVrsHZsb=Ds+77KAt8GFHuOSdpXZGuRi1VWH8=9ja4pt7g@mail.gmail.com>
 <8F1E6D72-F7FD-4D05-805C-BB59EC5E2009@sandia.gov>
Message-ID: <CA+dygY=-kHi_-bvSkGgzmkPBSHaYprpSMcu_AFktmF4NGTfjkg@mail.gmail.com>

I don't know if it is an option in your case, but you could build boost
yourself as static libraries. Then the whole build/install rpath situation
goes away. In case it is helpful, I recently gave an example of how I'm
currently doing this with a FetchContent-based solution. It won't suit
everyone, but the approach might be relevant for your particular case.

https://gitlab.kitware.com/cmake/cmake/issues/18831#note_509194


On Wed, Feb 6, 2019 at 9:00 AM Stephens, J. Adam via CMake <cmake at cmake.org>
wrote:

> Hi Robert,
>
> Thanks for your reply. We do use install_name_tool and the like when
> installing/packaging, and our packages continue to work fine on OS X 10.12.
> My question is about what to do with executables before packaging, while
> they are still just in the build tree. We need them to work for purposes of
> testing via CTest.
>
> Adam
>
>
> ?On 2/5/19, 2:56 PM, "Robert Maynard" <robert.maynard at kitware.com> wrote:
>
>     My general approach for the second problem is to run a tool such as
>     install_name_tool to change the library names to have @rpath when
>     constructing the package.
>
>     On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake
>     <cmake at cmake.org> wrote:
>     >
>     > Hello,
>     >
>     >
>     >
>     > The project I work on links to several shared boost libraries. After
> our organization disallowed use of OS X 10.11 and we upgraded our
> built/test slave to 10.12, we encountered a problem with our testing.
> Executables in the build tree that were built as part of our project now
> fail to run with the error that boost libraries can?t be found.
>     >
>     >
>     >
>     > Superficially, the problem is that (I think) Apple strengthened the
> SIP between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any
> effect ? previously the linker was able to locate the boost libs for our
> build tree executables that way.
>     >
>     >
>     >
>     > The deeper problem is twofold: First, the build tree executables
> don?t include the boost lib folder in their RPATHs. Second, the install
> names embedded in boost libs themselves are just the bare filenames with no
> @rpath. (My understanding is, the boost project does that deliberately
> because they can?t know what users of their libraries will want.)
>     >
>     >
>     >
>     > Recent versions of CMake (3.8+) have the property BUILD_RPATH that
> we could use to embed the path to the boost libs into the build tree
> executables. That doesn?t solve the second part of the problem, though.
> Without embedding install names that look like @rpath/libboost_foo.dylib in
> the build tree executables, I think the linker will still be unable to find
> them.
>     >
>     >
>     >
>     > What is the best (or least bad) way to fix this?
>     >
>     >
>     >
>     > Thanks!
>     >
>     >
>     >
>     > Adam
>     >
>     >
>     >
>     > --
>     >
>     > J. Adam Stephens, Ph.D.
>     >
>     > Dakota Support Analyst
>     >
>     > https://dakota.sandia.gov/
>     >
>     > Optimization and UQ
>     >
>     > Sandia National Laboratories
>     >
>     > Albuquerque, NM
>

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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190206/3df8ffdc/attachment-0001.html>

From juan.e.sanchez at gmail.com  Tue Feb  5 17:36:23 2019
From: juan.e.sanchez at gmail.com (Juan Sanchez)
Date: Tue, 5 Feb 2019 16:36:23 -0600
Subject: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12
In-Reply-To: <8F1E6D72-F7FD-4D05-805C-BB59EC5E2009@sandia.gov>
References: <F3952296-66F1-4BE1-B54D-EE932B2511DA@contoso.com>
 <CAFzjYVrsHZsb=Ds+77KAt8GFHuOSdpXZGuRi1VWH8=9ja4pt7g@mail.gmail.com>
 <8F1E6D72-F7FD-4D05-805C-BB59EC5E2009@sandia.gov>
Message-ID: <CAEHOsR0kPQ+HfkUd07+=+YdsT3xL57Uin2ULuGBz_WmiNzpjiw@mail.gmail.com>

Hello,

Are you able to use BUILD_WITH_INSTALL_RPATH:
https://cmake.org/cmake/help/v3.13/prop_tgt/BUILD_WITH_INSTALL_RPATH.html
https://cmake.org/cmake/help/v3.13/prop_tgt/INSTALL_RPATH.html#prop_tgt:INSTALL_RPATH

Regards,

Juan


On Tue, Feb 5, 2019 at 4:00 PM Stephens, J. Adam via CMake <cmake at cmake.org>
wrote:

> Hi Robert,
>
> Thanks for your reply. We do use install_name_tool and the like when
> installing/packaging, and our packages continue to work fine on OS X 10.12.
> My question is about what to do with executables before packaging, while
> they are still just in the build tree. We need them to work for purposes of
> testing via CTest.
>
> Adam
>
>
> ?On 2/5/19, 2:56 PM, "Robert Maynard" <robert.maynard at kitware.com> wrote:
>
>     My general approach for the second problem is to run a tool such as
>     install_name_tool to change the library names to have @rpath when
>     constructing the package.
>
>     On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake
>     <cmake at cmake.org> wrote:
>     >
>     > Hello,
>     >
>     >
>     >
>     > The project I work on links to several shared boost libraries. After
> our organization disallowed use of OS X 10.11 and we upgraded our
> built/test slave to 10.12, we encountered a problem with our testing.
> Executables in the build tree that were built as part of our project now
> fail to run with the error that boost libraries can?t be found.
>     >
>     >
>     >
>     > Superficially, the problem is that (I think) Apple strengthened the
> SIP between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any
> effect ? previously the linker was able to locate the boost libs for our
> build tree executables that way.
>     >
>     >
>     >
>     > The deeper problem is twofold: First, the build tree executables
> don?t include the boost lib folder in their RPATHs. Second, the install
> names embedded in boost libs themselves are just the bare filenames with no
> @rpath. (My understanding is, the boost project does that deliberately
> because they can?t know what users of their libraries will want.)
>     >
>     >
>     >
>     > Recent versions of CMake (3.8+) have the property BUILD_RPATH that
> we could use to embed the path to the boost libs into the build tree
> executables. That doesn?t solve the second part of the problem, though.
> Without embedding install names that look like @rpath/libboost_foo.dylib in
> the build tree executables, I think the linker will still be unable to find
> them.
>     >
>     >
>     >
>     > What is the best (or least bad) way to fix this?
>     >
>     >
>     >
>     > Thanks!
>     >
>     >
>     >
>     > Adam
>     >
>     >
>     >
>     > --
>     >
>     > J. Adam Stephens, Ph.D.
>     >
>     > Dakota Support Analyst
>     >
>     > https://dakota.sandia.gov/
>     >
>     > Optimization and UQ
>     >
>     > Sandia National Laboratories
>     >
>     > Albuquerque, NM
>     >
>     >
>     >
>     > --
>     >
>     > 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:
>     > https://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:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190205/af9bcd61/attachment.html>

From gagiuntoli at gmail.com  Tue Feb  5 17:55:32 2019
From: gagiuntoli at gmail.com (Guido Giuntoli)
Date: Tue, 5 Feb 2019 23:55:32 +0100
Subject: [CMake] Can't open module file *.mod
Message-ID: <CADOH_Gcm5hZPqb0geovZbS5GZvMj+CiG+DfOsAnYyZFF5fANew@mail.gmail.com>

Hi I have a Fortran project with the following order

src/module_1.f90     (Fortran Modules)
src/module_2.f90
src/... (more files)

file(GLOB SOURCES src/*.f90)
add_executable(MyExec SOURCES)

module_1 depends on module_2 and when is compiling module_1.f90 I get the
dependency error :

Fatal Error: Can't open module file ?module_2.mod? :for reading at (1):  No
existe el fichero o el directorio (*The file does not exist*).

Thanks, Guido.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190205/d9814a8d/attachment.html>

From penzin.dev at gmail.com  Tue Feb  5 21:29:38 2019
From: penzin.dev at gmail.com (Petr Penzin)
Date: Tue, 5 Feb 2019 18:29:38 -0800
Subject: [CMake] Can't open module file *.mod
In-Reply-To: <CADOH_Gcm5hZPqb0geovZbS5GZvMj+CiG+DfOsAnYyZFF5fANew@mail.gmail.com>
References: <CADOH_Gcm5hZPqb0geovZbS5GZvMj+CiG+DfOsAnYyZFF5fANew@mail.gmail.com>
Message-ID: <1a0be2d7-b1d5-5d7b-117a-8fd0803939a9@gmail.com>

When I ran into the same issue, my workaround was to use file properties 
to set dependencies between files, but I don't think it is very robust 
solution. Would be curious to hear if there is a better way to do it.

Best,

Petr


On 2/5/19 2:55 PM, Guido Giuntoli wrote:
> Hi I have a Fortran project with the following order
>
> src/module_1.f90???? (Fortran Modules)
> src/module_2.f90
> src/... (more files)
>
> file(GLOB SOURCES src/*.f90)
> add_executable(MyExec SOURCES)
>
> module_1 depends on module_2 and when is compiling module_1.f90 I get 
> the dependency error :
>
> Fatal Error: Can't open module file ?module_2.mod? :for reading at 
> (1):? No existe el fichero o el directorio (*The file does not exist*).
>
> Thanks, Guido.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190205/dc200748/attachment.html>

From juan.e.sanchez at gmail.com  Wed Feb  6 00:16:46 2019
From: juan.e.sanchez at gmail.com (Juan E. Sanchez)
Date: Tue, 5 Feb 2019 23:16:46 -0600
Subject: [CMake] Can't open module file *.mod
In-Reply-To: <1a0be2d7-b1d5-5d7b-117a-8fd0803939a9@gmail.com>
References: <CADOH_Gcm5hZPqb0geovZbS5GZvMj+CiG+DfOsAnYyZFF5fANew@mail.gmail.com>
 <1a0be2d7-b1d5-5d7b-117a-8fd0803939a9@gmail.com>
Message-ID: <0e375bfc-9f7e-cfaf-ae21-65d25d2b111b@gmail.com>

It has been several months since I looked at this.  I seem to remember 
setting dependencies between libraries containing modules, using 
something like target_link_libraries.  I think that cmake was capable of 
detecting dependencies between files in the same library.  I think it 
relied on the use of the USE statement.

I think

Regards,

Juan


On 2/5/19 8:29 PM, Petr Penzin wrote:
> When I ran into the same issue, my workaround was to use file properties 
> to set dependencies between files, but I don't think it is very robust 
> solution. Would be curious to hear if there is a better way to do it.
> 
> Best,
> 
> Petr
> 
> 
> On 2/5/19 2:55 PM, Guido Giuntoli wrote:
>> Hi I have a Fortran project with the following order
>>
>> src/module_1.f90???? (Fortran Modules)
>> src/module_2.f90
>> src/... (more files)
>>
>> file(GLOB SOURCES src/*.f90)
>> add_executable(MyExec SOURCES)
>>
>> module_1 depends on module_2 and when is compiling module_1.f90 I get 
>> the dependency error :
>>
>> Fatal Error: Can't open module file ?module_2.mod? :for reading at 
>> (1):? No existe el fichero o el directorio (*The file does not exist*).
>>
>> Thanks, Guido.
>>
>>
> 


From djobet at tower-research.com  Wed Feb  6 12:26:17 2019
From: djobet at tower-research.com (David Jobet)
Date: Wed, 6 Feb 2019 17:26:17 +0000
Subject: [CMake] Building a repo with multiple applications and install
 process
In-Reply-To: <CAAV-JT7MCD3=2ToYgSw225vnm0E=QYb=pmct3qNPpaEwFKCZtg@mail.gmail.com>
References: <CAAV-JT7MCD3=2ToYgSw225vnm0E=QYb=pmct3qNPpaEwFKCZtg@mail.gmail.com>
Message-ID: <CAAV-JT7DiOJbgcbNCFVb945noh9twVJmGhATXGT6zeNpUyZmYQ@mail.gmail.com>

Hello,

so I didn't get a lot of answers, here's a quick POC which only uses
add_subdirectory() / include_guard() for more questions.

/CMakeLists.txt
/app1/CMakeLists.txt
/app2/CMakeLists.txt
/common/CMakeLists.txt

We have app1 depending on common, and app2 depending on common.
All 3 projects are living in the same mono-repo.

With those CMakeLists.txt, I'm able to build/install app1, app2, and
common as standalone projects with the following command line
e.g for app1 :
mkdir build_app1 && cd build_app1 && cmake -DCMAKE_INSTALL_PREFIX=
/path/to/app1 && make && DESTDIR=dist make install

I'm also able to build all apps at once using the following
mkdir build_all && cd build_all && cmake -DCMAKE_INSTALL_PREFIX=
/path/to/root && make && DESTDIR=dist make install

See below for the content of the files.

Now the question :
Do you think it would be possible to use the "build all" approach to
populate all .o, libs and executables, then to reconfigure the build
dir, say for app1 so I can then issue "make install" only for app1 ?
This would involve the "build all" project to have the same layout as
the "app1" project which currently is not the case.
In the "build all" project, app1 is a directory
In the "app1" project, app1 is a binary

Thanks for your help

David

---------------------------------------------------
/CMakeLists.txt
cmake_minimum_required(VERSION 3.10 FATAL_ERROR)

project(main-klib CXX)

add_subdirectory(app1)
add_subdirectory(app2)
add_subdirectory(common)

---------------------------------------------------
/app1/CMakeLists.txt
cmake_minimum_required(VERSION 3.10 FATAL_ERROR)
include_guard(GLOBAL)

project(app1 CXX)

add_subdirectory(../common common)

add_executable(app1 main.cc)
target_link_libraries(app1 common::lib)

install(
   TARGETS app1
   RUNTIME DESTINATION bin
)

---------------------------------------------------
/app2/CMakeLists.txt
cmake_minimum_required(VERSION 3.10 FATAL_ERROR)
include_guard(GLOBAL)

project(app2 CXX)

add_subdirectory(../common common)

add_executable(app2 main.cc)
target_link_libraries(app2 common::lib)

install(
   TARGETS app2
   RUNTIME DESTINATION bin
)

---------------------------------------------------
/common/CMakeLists.txt
cmake_minimum_required(VERSION 3.10 FATAL_ERROR)
include_guard(GLOBAL)

project(common CXX)

add_library(common common.cc)
add_library(common::lib ALIAS common)
target_include_directories(common PUBLIC ${PROJECT_SOURCE_DIR})

install(
   FILES common.py
   DESTINATION site-packages
)

On Tue, Feb 5, 2019 at 10:05 AM David Jobet <djobet at tower-research.com> wrote:
>
> Hello,
>
> at work, we have a mono-repo with multiple applications/libs (dozens).
> The build phase is ok, but I'm not sure about the release process.
>
> When we release, we release one application at a time.
> (CMAKE_SKIP_INSTALL_ALL_DEPENDENCY is true)
> In order to speed up releases, we always perform an incremental build.
>
> Unfortunately, we don't have one unique release process :
> process 1 :
> - a Jenkins pipeline executes some automatic tests then release the
> binary to production. This Jenkins pipeline only builds this single
> application, then executes the install step, then packages the binary
> with some auxiliary files for deployment in prod.
> process 2 :
> - the whole source tree is built regularly through Jenkins, then, from
> another Jenkins pipeline, an install step will be performed in the
> last built directory to deploy only the required application
>
> Both process 1 and process 2 are built in our CMakeLists.txt.
>
> Process 1 just uses regular install directives + ninja install
> Pros : simple
> Cons : install step can be costly
>
> Install step can be costly because, as the build directory is not
> emptied, the install step will install every single binaries left over
> from a previous build that have an install rule.
> Also, we have install directives for non binary files (python files
> for example) which will be installed unconditionally every time.
>
> Process 2 is not triggered through the install step but as a regular
> build target. Under the hood, the build step will add a POST_BUILD
> step attached to the target that will invoke "cmake -P
> ${CMAKE_BINARY_DIR}/cmake_install.cmake -DCOMPONENT=${component}"
> Pros : more "chirurgical", only install what's required
> Cons : - if an application depends on several components, we need to
> describe this in cmake (dependencies are described twice : once for
> the build, once for the install)
>        - need to maintain an extra "non standard" layer (albeit a small layer)
>
> At this point, I'd like to ask if you see simple steps we could take
> to stay as simple and standard as possible without paying the cons
> (lenghty install step, double description of dependencies, extra layer
> to maintain).
>
> I have a proposal of my own, I'm just not sure this is technically
> feasible. I will definitively run a POC sometime, but I thought I
> would run it by you first to get your advice/experience.
>
> So maybe the problem is we have one monolithic CMake system where all
> apps are described.
> What if every single application had its own independent CMake system
> (while still being able to depend on common libs, that needs to be
> built only once) ?
> One app would describe its dependencies, the install step would then
> stay simple, and only the reachable install directives would be
> triggered in a per-app build.
>
> Is it something which is feasible ? How would you implement it ? (I
> thought about ExternalProject_Add but have no experience with it and
> I'm not sure it would work in that case ?)
>
> Also, we would still need to be able to build all applications in one
> single command.
> Do you think creating a "meta" cmake, equivalent to what we have right
> now, but on top of those independent, per-app cmake, is feasible ?
> (Again, I guess using ExternalProject_Add) ?
>
> Thanks very much for your help
>
> David

From jasteph at sandia.gov  Wed Feb  6 12:30:49 2019
From: jasteph at sandia.gov (Stephens, J. Adam)
Date: Wed, 6 Feb 2019 17:30:49 +0000
Subject: [CMake] [EXTERNAL] Re:  Linking to boost on OS X 10.12
In-Reply-To: <CAFzjYVr7GWUpZ+S84kKvUEGdDRL7h+pXepn7ZGQdi47X_2FYbQ@mail.gmail.com>
References: <F3952296-66F1-4BE1-B54D-EE932B2511DA@contoso.com>
 <CAFzjYVrsHZsb=Ds+77KAt8GFHuOSdpXZGuRi1VWH8=9ja4pt7g@mail.gmail.com>
 <8F1E6D72-F7FD-4D05-805C-BB59EC5E2009@sandia.gov>
 <CAFzjYVr7GWUpZ+S84kKvUEGdDRL7h+pXepn7ZGQdi47X_2FYbQ@mail.gmail.com>
Message-ID: <5B1C8D88-F5EF-47D5-9A78-38460D85ED14@sandia.gov>

Robert,

We unfortunately can't just modify the boost libraries where they are installed because our customers need to be able to build our project from source, and they would need to do the same thing. We could perhaps do something more radical like copy those libraries into the build tree and modify them, or build our own boost as part of our project.

Alternatively, we could use install_name_tool  to edit the build tree executables and change their dependencies from libboost_foo.dylib to @rpath/libboost_foo.dylib, just like we do for the executables we install. Can you think of a mechanism in CMake that would allow us to run install_name_tool on our executables as a final step in the build process?

Thanks again for your help.

Adam

--
J. Adam Stephens, Ph.D.
Dakota Support Analyst
https://dakota.sandia.gov/
Optimization and UQ
Sandia National Laboratories
Albuquerque, NM

 

?On 2/5/19, 3:06 PM, "Robert Maynard" <robert.maynard at kitware.com> wrote:

    The version of the libraries that you load from your build directory
    would need to be fixed up to.
    
    On Tue, Feb 5, 2019 at 5:00 PM Stephens, J. Adam <jasteph at sandia.gov> wrote:
    >
    > Hi Robert,
    >
    > Thanks for your reply. We do use install_name_tool and the like when installing/packaging, and our packages continue to work fine on OS X 10.12. My question is about what to do with executables before packaging, while they are still just in the build tree. We need them to work for purposes of testing via CTest.
    >
    > Adam
    >
    >
    > On 2/5/19, 2:56 PM, "Robert Maynard" <robert.maynard at kitware.com> wrote:
    >
    >     My general approach for the second problem is to run a tool such as
    >     install_name_tool to change the library names to have @rpath when
    >     constructing the package.
    >
    >     On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake
    >     <cmake at cmake.org> wrote:
    >     >
    >     > Hello,
    >     >
    >     >
    >     >
    >     > The project I work on links to several shared boost libraries. After our organization disallowed use of OS X 10.11 and we upgraded our built/test slave to 10.12, we encountered a problem with our testing. Executables in the build tree that were built as part of our project now fail to run with the error that boost libraries can?t be found.
    >     >
    >     >
    >     >
    >     > Superficially, the problem is that (I think) Apple strengthened the SIP between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any effect ? previously the linker was able to locate the boost libs for our build tree executables that way.
    >     >
    >     >
    >     >
    >     > The deeper problem is twofold: First, the build tree executables don?t include the boost lib folder in their RPATHs. Second, the install names embedded in boost libs themselves are just the bare filenames with no @rpath. (My understanding is, the boost project does that deliberately because they can?t know what users of their libraries will want.)
    >     >
    >     >
    >     >
    >     > Recent versions of CMake (3.8+) have the property BUILD_RPATH that we could use to embed the path to the boost libs into the build tree executables. That doesn?t solve the second part of the problem, though. Without embedding install names that look like @rpath/libboost_foo.dylib in the build tree executables, I think the linker will still be unable to find them.
    >     >
    >     >
    >     >
    >     > What is the best (or least bad) way to fix this?
    >     >
    >     >
    >     >
    >     > Thanks!
    >     >
    >     >
    >     >
    >     > Adam
    >     >
    >     >
    >     >
    >     > --
    >     >
    >     > J. Adam Stephens, Ph.D.
    >     >
    >     > Dakota Support Analyst
    >     >
    >     > https://dakota.sandia.gov/
    >     >
    >     > Optimization and UQ
    >     >
    >     > Sandia National Laboratories
    >     >
    >     > Albuquerque, NM
    >     >
    >     >
    >     >
    >     > --
    >     >
    >     > 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:
    >     > https://cmake.org/mailman/listinfo/cmake
    >
    >
    


From jasteph at sandia.gov  Wed Feb  6 12:32:20 2019
From: jasteph at sandia.gov (Stephens, J. Adam)
Date: Wed, 6 Feb 2019 17:32:20 +0000
Subject: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12
In-Reply-To: <CAEHOsR0kPQ+HfkUd07+=+YdsT3xL57Uin2ULuGBz_WmiNzpjiw@mail.gmail.com>
References: <F3952296-66F1-4BE1-B54D-EE932B2511DA@contoso.com>
 <CAFzjYVrsHZsb=Ds+77KAt8GFHuOSdpXZGuRi1VWH8=9ja4pt7g@mail.gmail.com>
 <8F1E6D72-F7FD-4D05-805C-BB59EC5E2009@sandia.gov>
 <CAEHOsR0kPQ+HfkUd07+=+YdsT3xL57Uin2ULuGBz_WmiNzpjiw@mail.gmail.com>
Message-ID: <6E0C6F62-264C-48DC-95C4-5442F06BB51B@sandia.gov>

Hi Juan,

I believe BUILD_WITH_INSTALL_RPATH would place the correct RPATH in the executables. It?s a potentially easier alternative to using the BUILD_RPATH property for that purpose. However, I think it?s only half of what needs to happen. The linker still would be unable to find the boost libraries because their install names do not contain @rpath. Thanks for the suggestion.

--
J. Adam Stephens, Ph.D.
Dakota Support Analyst
https://dakota.sandia.gov/
Optimization and UQ
Sandia National Laboratories
Albuquerque, NM


From: Juan Sanchez <juan.e.sanchez at gmail.com>
Date: Tuesday, February 5, 2019 at 3:37 PM
To: "Stephens, J. Adam" <jasteph at sandia.gov>
Cc: "Maynard, Robert (External Contact)" <robert.maynard at kitware.com>, "cmake at cmake.org" <cmake at cmake.org>
Subject: Re: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12

Hello,

Are you able to use BUILD_WITH_INSTALL_RPATH:
https://cmake.org/cmake/help/v3.13/prop_tgt/BUILD_WITH_INSTALL_RPATH.html
https://cmake.org/cmake/help/v3.13/prop_tgt/INSTALL_RPATH.html#prop_tgt:INSTALL_RPATH

Regards,

Juan


On Tue, Feb 5, 2019 at 4:00 PM Stephens, J. Adam via CMake <cmake at cmake.org<mailto:cmake at cmake.org>> wrote:
Hi Robert,

Thanks for your reply. We do use install_name_tool and the like when installing/packaging, and our packages continue to work fine on OS X 10.12. My question is about what to do with executables before packaging, while they are still just in the build tree. We need them to work for purposes of testing via CTest.

Adam


On 2/5/19, 2:56 PM, "Robert Maynard" <robert.maynard at kitware.com<mailto:robert.maynard at kitware.com>> wrote:

    My general approach for the second problem is to run a tool such as
    install_name_tool to change the library names to have @rpath when
    constructing the package.

    On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake
    <cmake at cmake.org<mailto:cmake at cmake.org>> wrote:
    >
    > Hello,
    >
    >
    >
    > The project I work on links to several shared boost libraries. After our organization disallowed use of OS X 10.11 and we upgraded our built/test slave to 10.12, we encountered a problem with our testing. Executables in the build tree that were built as part of our project now fail to run with the error that boost libraries can?t be found.
    >
    >
    >
    > Superficially, the problem is that (I think) Apple strengthened the SIP between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any effect ? previously the linker was able to locate the boost libs for our build tree executables that way.
    >
    >
    >
    > The deeper problem is twofold: First, the build tree executables don?t include the boost lib folder in their RPATHs. Second, the install names embedded in boost libs themselves are just the bare filenames with no @rpath. (My understanding is, the boost project does that deliberately because they can?t know what users of their libraries will want.)
    >
    >
    >
    > Recent versions of CMake (3.8+) have the property BUILD_RPATH that we could use to embed the path to the boost libs into the build tree executables. That doesn?t solve the second part of the problem, though. Without embedding install names that look like @rpath/libboost_foo.dylib in the build tree executables, I think the linker will still be unable to find them.
    >
    >
    >
    > What is the best (or least bad) way to fix this?
    >
    >
    >
    > Thanks!
    >
    >
    >
    > Adam
    >
    >
    >
    > --
    >
    > J. Adam Stephens, Ph.D.
    >
    > Dakota Support Analyst
    >
    > https://dakota.sandia.gov/
    >
    > Optimization and UQ
    >
    > Sandia National Laboratories
    >
    > Albuquerque, NM
    >
    >
    >
    > --
    >
    > Powered by www.kitware.com<http://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:
    > https://cmake.org/mailman/listinfo/cmake


--

Powered by www.kitware.com<http://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:
https://cmake.org/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190206/8097dd1d/attachment-0001.html>

From juan.e.sanchez at gmail.com  Wed Feb  6 12:58:59 2019
From: juan.e.sanchez at gmail.com (Juan Sanchez)
Date: Wed, 6 Feb 2019 11:58:59 -0600
Subject: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12
In-Reply-To: <6E0C6F62-264C-48DC-95C4-5442F06BB51B@sandia.gov>
References: <F3952296-66F1-4BE1-B54D-EE932B2511DA@contoso.com>
 <CAFzjYVrsHZsb=Ds+77KAt8GFHuOSdpXZGuRi1VWH8=9ja4pt7g@mail.gmail.com>
 <8F1E6D72-F7FD-4D05-805C-BB59EC5E2009@sandia.gov>
 <CAEHOsR0kPQ+HfkUd07+=+YdsT3xL57Uin2ULuGBz_WmiNzpjiw@mail.gmail.com>
 <6E0C6F62-264C-48DC-95C4-5442F06BB51B@sandia.gov>
Message-ID: <CAEHOsR3uWAwqw6nuJy26R2v1G=NsJvxDpKZ3s_PFCe=s=nCwew@mail.gmail.com>

Hello,

How are you adding the library?  Are you using "-L /path/to/boost/libs
-lboost_foo" syntax when using target_link_libraries?  What do you see when
running "otool -L" on the resulting executable?  If you still need to run
install_name_tool, I suppose you can do it using a POST_BUILD cmake command.
https://cmake.org/cmake/help/v3.13/command/add_custom_command.html

Regards,

Juan


On Wed, Feb 6, 2019 at 11:32 AM Stephens, J. Adam <jasteph at sandia.gov>
wrote:

> Hi Juan,
>
>
>
> I believe BUILD_WITH_INSTALL_RPATH would place the correct RPATH in the
> executables. It?s a potentially easier alternative to using the BUILD_RPATH
> property for that purpose. However, I think it?s only half of what needs to
> happen. The linker still would be unable to find the boost libraries
> because their install names do not contain @rpath. Thanks for the
> suggestion.
>
>
>
> --
>
> J. Adam Stephens, Ph.D.
>
> Dakota Support Analyst
>
> https://dakota.sandia.gov/
>
> Optimization and UQ
>
> Sandia National Laboratories
>
> Albuquerque, NM
>
>
>
>
>
> *From: *Juan Sanchez <juan.e.sanchez at gmail.com>
> *Date: *Tuesday, February 5, 2019 at 3:37 PM
> *To: *"Stephens, J. Adam" <jasteph at sandia.gov>
> *Cc: *"Maynard, Robert (External Contact)" <robert.maynard at kitware.com>, "
> cmake at cmake.org" <cmake at cmake.org>
> *Subject: *Re: [CMake] [EXTERNAL] Re: Linking to boost on OS X 10.12
>
>
>
> Hello,
>
>
>
> Are you able to use BUILD_WITH_INSTALL_RPATH:
>
> https://cmake.org/cmake/help/v3.13/prop_tgt/BUILD_WITH_INSTALL_RPATH.html
>
>
> https://cmake.org/cmake/help/v3.13/prop_tgt/INSTALL_RPATH.html#prop_tgt:INSTALL_RPATH
>
>
>
> Regards,
>
>
>
> Juan
>
>
>
>
>
> On Tue, Feb 5, 2019 at 4:00 PM Stephens, J. Adam via CMake <
> cmake at cmake.org> wrote:
>
> Hi Robert,
>
> Thanks for your reply. We do use install_name_tool and the like when
> installing/packaging, and our packages continue to work fine on OS X 10.12.
> My question is about what to do with executables before packaging, while
> they are still just in the build tree. We need them to work for purposes of
> testing via CTest.
>
> Adam
>
>
> On 2/5/19, 2:56 PM, "Robert Maynard" <robert.maynard at kitware.com> wrote:
>
>     My general approach for the second problem is to run a tool such as
>     install_name_tool to change the library names to have @rpath when
>     constructing the package.
>
>     On Tue, Feb 5, 2019 at 2:25 PM Stephens, J. Adam via CMake
>     <cmake at cmake.org> wrote:
>     >
>     > Hello,
>     >
>     >
>     >
>     > The project I work on links to several shared boost libraries. After
> our organization disallowed use of OS X 10.11 and we upgraded our
> built/test slave to 10.12, we encountered a problem with our testing.
> Executables in the build tree that were built as part of our project now
> fail to run with the error that boost libraries can?t be found.
>     >
>     >
>     >
>     > Superficially, the problem is that (I think) Apple strengthened the
> SIP between 10.11 and 10.12 to prevent DYLD_LIBRARY_PATH from having any
> effect ? previously the linker was able to locate the boost libs for our
> build tree executables that way.
>     >
>     >
>     >
>     > The deeper problem is twofold: First, the build tree executables
> don?t include the boost lib folder in their RPATHs. Second, the install
> names embedded in boost libs themselves are just the bare filenames with no
> @rpath. (My understanding is, the boost project does that deliberately
> because they can?t know what users of their libraries will want.)
>     >
>     >
>     >
>     > Recent versions of CMake (3.8+) have the property BUILD_RPATH that
> we could use to embed the path to the boost libs into the build tree
> executables. That doesn?t solve the second part of the problem, though.
> Without embedding install names that look like @rpath/libboost_foo.dylib in
> the build tree executables, I think the linker will still be unable to find
> them.
>     >
>     >
>     >
>     > What is the best (or least bad) way to fix this?
>     >
>     >
>     >
>     > Thanks!
>     >
>     >
>     >
>     > Adam
>     >
>     >
>     >
>     > --
>     >
>     > J. Adam Stephens, Ph.D.
>     >
>     > Dakota Support Analyst
>     >
>     > https://dakota.sandia.gov/
>     >
>     > Optimization and UQ
>     >
>     > Sandia National Laboratories
>     >
>     > Albuquerque, NM
>     >
>     >
>     >
>     > --
>     >
>     > 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:
>     > https://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:
> https://cmake.org/mailman/listinfo/cmake
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190206/3b22218f/attachment.html>

From hex7c3 at gmail.com  Wed Feb  6 13:56:34 2019
From: hex7c3 at gmail.com (hex)
Date: Wed, 6 Feb 2019 18:56:34 +0000
Subject: [CMake] Dependee "DependInfo.cmake" is newer than depender
 "depend.internal".
Message-ID: <9038fe1b-ffc7-2f88-d4f4-798dc728d5bb@gmail.com>

hello community,

During compilation, cmake shows the information message

*Dependee "DependInfo.cmake" is newer than depender "depend.internal".*

to explain why a file needs to be recompiled.

imediately after

*??? -- Build files have been written to: ./build**
**??? /usr/bin/cmake -H. -B./build --check-build-system 
CMakeFiles/Makefile.cmake 0**
**??? /usr/bin/cmake -E cmake_progress_start ./build/CMakeFiles 
./build/CMakeFiles/progress.marks**
*

Can this be optimized?

Which files do I have to look at? There is a file 
"build/CMakeFiles/Makefile.cmake" which sets dependency order:

*# The generator used is:**
**set(CMAKE_DEPENDS_GENERATOR "Unix Makefiles")**
**
**# The top level Makefile was generated from the following files:**
**set(CMAKE_MAKEFILE_DEPENDS**
**? "CMakeCache.txt"**
**? "utils.cmake"**
**? "../CMakeLists.txt"**
**? "../Toolchains/tc.cmake"**
**? "CMakeFiles/3.5.1/CMakeCCompiler.cmake"**
**? "CMakeFiles/3.5.1/CMakeCXXCompiler.cmake"**
**? "CMakeFiles/3.5.1/CMakeSystem.cmake"**
**? "/usr/share/cmake-3.5/Modules/CMakeCCompiler.cmake.in"**
**? "/usr/share/cmake-3.5/Modules/CMakeCInformation.cmake"**
**? "/usr/share/cmake-3.5/Modules/CMakeCXXCompiler.cmake.in"**
**? "/usr/share/cmake-3.5/Modules/CMakeCXXInformation.cmake"**
**"/usr/share/cmake-3.5/Modules/CMakeCommonLanguageInclude.cmake"**
**"/usr/share/cmake-3.5/Modules/CMakeDetermineCCompiler.cmake"**
**"/usr/share/cmake-3.5/Modules/CMakeDetermineCXXCompiler.cmake"**
**? "/usr/share/cmake-3.5/Modules/CMakeDetermineCompiler.cmake"**
**? "/usr/share/cmake-3.5/Modules/CMakeDetermineSystem.cmake"**
**? "/usr/share/cmake-3.5/Modules/CMakeFindBinUtils.cmake"**
**? "/usr/share/cmake-3.5/Modules/CMakeForceCompiler.cmake"**
**? "/usr/share/cmake-3.5/Modules/CMakeGenericSystem.cmake"**
**"/usr/share/cmake-3.5/Modules/CMakeLanguageInformation.cmake"**
**? "/usr/share/cmake-3.5/Modules/CMakeSystem.cmake.in"**
**"/usr/share/cmake-3.5/Modules/CMakeSystemSpecificInformation.cmake"**
**"/usr/share/cmake-3.5/Modules/CMakeSystemSpecificInitialize.cmake"**
**? "/usr/share/cmake-3.5/Modules/CMakeTestCCompiler.cmake"**
**? "/usr/share/cmake-3.5/Modules/CMakeTestCXXCompiler.cmake"**
**? "/usr/share/cmake-3.5/Modules/CMakeUnixFindMake.cmake"**
**? "/usr/share/cmake-3.5/Modules/Compiler/GNU-C.cmake"**
**? "/usr/share/cmake-3.5/Modules/Compiler/GNU-CXX.cmake"**
**? "/usr/share/cmake-3.5/Modules/Compiler/GNU.cmake"**
**? "/usr/share/cmake-3.5/Modules/MultiArchCross.cmake"**
**? "/usr/share/cmake-3.5/Modules/Platform/Generic.cmake"**
**? )**
**
**# The corresponding makefile is:**
**set(CMAKE_MAKEFILE_OUTPUTS**
**? "Makefile"**
**? "CMakeFiles/cmake.check_cache"**
**? )**
**
**# Byproducts of CMake generate step:**
**set(CMAKE_MAKEFILE_PRODUCTS**
**? "CMakeFiles/3.5.1/CMakeSystem.cmake"**
**? "CMakeFiles/3.5.1/CMakeCCompiler.cmake"**
**? "CMakeFiles/3.5.1/CMakeCXXCompiler.cmake"**
**? "CMakeFiles/CMakeDirectoryInformation.cmake"**
**? )**
**
**# Dependency information for all targets:**
**set(CMAKE_DEPEND_INFO_FILES**
**? "CMakeFiles/hello-world.dir/DependInfo.cmake"**
**? )**
*


Also, after this build step:

*??? make -f CMakeFiles/Makefile2 all**
**??? make[1]: Entering directory './build'**
**??? make -f CMakeFiles/hello-world.dir/build.make 
CMakeFiles/hello-world.dir/depend**
**??? make[2]: Entering directory './build'**
*
it sais:

*??? -E cmake_depends "Unix Makefiles" ./ ./ ./build ./build 
./build/CMakeFiles/hello-world.dir/DependInfo.cmake --color=**
*
why are the folders "./" and "./build" appearing twice?

this is my build command:

*??? cmake -DCMAKE_TOOLCHAIN_FILE=Toolchains/tc.cmake 
-DCMAKE_BUILD_TYPE=Debug*


thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190206/75350296/attachment-0001.html>

From benjamin.beney at kitware.com  Thu Feb  7 02:22:56 2019
From: benjamin.beney at kitware.com (Benjamin Beney)
Date: Thu, 7 Feb 2019 08:22:56 +0100
Subject: [CMake] [ANN] CMake Training Course in France - March 18
Message-ID: <CANm94zzeHUsFbvf1mJ7SW6+_Ft8q2V50CHf2QVWRqUxVzD6xMA@mail.gmail.com>

Hello all,

Kitware will be holding a CMake training course on March 18, 2019 in
Lyon, France. This one-day course will cover the best practice for
CMake, CTest, CPack and CDash.

Please visit our website for more information and registration details:

     https://training.kitware.fr/browse/204

Note that the course will be taught in English. If you have any
questions, please contact us at training at kitware.fr or email me directly.

We are looking forward to seeing you in Lyon,

Benjamin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190207/554a014a/attachment.html>

From robert.maynard at kitware.com  Thu Feb  7 11:25:26 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 7 Feb 2019 11:25:26 -0500
Subject: [CMake] [ANNOUNCE] CMake 3.14.0-rc1 is ready for testing
Message-ID: <CAFzjYVp5sA66gkNi3s3qmsMHDcPCMPzZkeav=Q4CcLg0UE1PeQ@mail.gmail.com>

I am proud to announce the first CMake 3.14 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.14

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.14/release/3.14.html

Some of the more significant changes in CMake 3.14 are:

* Support for running CMake on Windows XP and Windows Vista has been
  dropped. The precompiled Windows binaries provided on "cmake.org"
  now require Windows 7 or higher.

* CMake now supports Cross Compiling for iOS, tvOS, or watchOS using
  simple toolchain files.

* The "Visual Studio 16 2019" generator was added.  This is
  experimental and based on "Visual Studio 2019 Preview 2" because
  this version of VS has not been released.

  The VS 2019 generator differs from generators for earlier versions
  in that it does not provide variants that specify the target
  platform in the generator name.  Instead "CMAKE_GENERATOR_PLATFORM"
  must be used, e.g. through the "-A" command-line option.
  Furthermore, the default target platform (architecture) is now based
  on the *host* platform.  The VS host toolset selection is now based
  on the host architecture as well.

* A "CMAKE_BUILD_RPATH_USE_ORIGIN" variable and corresponding
  "BUILD_RPATH_USE_ORIGIN" target property were added to enable use of
  relative runtime paths (RPATHs). This helps achieving relocatable
  and reproducible builds that are invariant of the build directory.

* The "install(TARGETS)" command learned how to install to an
  appropriate default directory for a given target type, based on
  variables from the "GNUInstallDirs" module and built-in defaults, in
  lieu of a "DESTINATION" argument.

* The "install(FILES)" and "install(DIRECTORY)" commands learned a
  new set of parameters for installing files as a file type, setting
  the destination based on the appropriate variables from
  "GNUInstallDirs" and built-in defaults, in lieu of a "DESTINATION"
  argument.

* The "install(CODE)" and "install(SCRIPT)" commands learned to
  support generator expressions.  See policy "CMP0087".

* The "if()" command gained support for checking if cache variables
  are defined with the  "DEFINED CACHE{VAR}" syntax.

* A file-based api for clients to get semantic buildsystem
  information has been added.  See the "cmake-file-api(7)" manual.
  This is intended to replace the "cmake-server(7)" mode for IDEs.

* The "cmake(1)" Build Tool Mode ("cmake --build") gained "--
  verbose" and "-v" options to specify verbose build output. Some
  generators such as Xcode don't support this option currently.

* The "cmake(1)" "-E compare_files" command learned a new "--ignore-
  eol" option to specify that end-of-line differences (e.g. LF vs
  CRLF) should be ignored when comparing files.


CMake 3.14 Release Notes
************************

Changes made since CMake 3.13 include the following.


New Features
============


Generators
----------

* The "Visual Studio 16 2019" generator was added.  This is
  experimental and based on "Visual Studio 2019 Preview 2" because
  this version of VS has not been released.

  The VS 2019 generator differs from generators for earlier versions
  in that it does not provide variants that specify the target
  platform in the generator name.  Instead "CMAKE_GENERATOR_PLATFORM"
  must be used, e.g. through the "-A" command-line option.
  Furthermore, the default target platform (architecture) is now based
  on the *host* platform.  The VS host toolset selection is now based
  on the host architecture as well.


File-Based API
--------------

* A file-based api for clients to get semantic buildsystem
  information has been added.  See the "cmake-file-api(7)" manual.
  This is intended to replace the "cmake-server(7)" mode for IDEs.


Platforms
---------

* CMake now supports Cross Compiling for iOS, tvOS, or watchOS using
  simple toolchain files.


Command-Line
------------

* The "cmake(1)" Build Tool Mode ("cmake --build") gained "--
  verbose" and "-v" options to specify verbose build output. Some
  generators such as Xcode don't support this option currently.

* The "cmake(1)" "-E compare_files" command learned a new "--ignore-
  eol" option to specify that end-of-line differences (e.g. LF vs
  CRLF) should be ignored when comparing files.

* The "cmake-gui(1)" dialog gained new "-S" and "-B" arguments to
  explicitly specify source and build directories.


Commands
--------

* The "file()" command learned a new sub-command, "READ_SYMLINK",
  which can be used to determine the path that a symlink points to.

* The "file()" command gained a "SIZE" mode to get the size of a
  file on disk.

* The "find_package()" command learned to optionally resolve
  symbolic links in the paths to package configuration files. See the
  "CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS" variable.

* The "get_filename_component()" command gained new "LAST_EXT" and
  "NAME_WLE" variants to work with the extension after the last "." in
  the name.

* The "if()" command gained support for checking if cache variables
  are defined with the  "DEFINED CACHE{VAR}" syntax.

* The "install(CODE)" and "install(SCRIPT)" commands learned to
  support generator expressions.  See policy "CMP0087".

* The "install(TARGETS)" command learned how to install to an
  appropriate default directory for a given target type, based on
  variables from the "GNUInstallDirs" module and built-in defaults, in
  lieu of a "DESTINATION" argument.

* The "install(FILES)" and "install(DIRECTORY)" commands learned a
  new set of parameters for installing files as a file type, setting
  the destination based on the appropriate variables from
  "GNUInstallDirs" and built-in defaults, in lieu of a "DESTINATION"
  argument.

* The "list()" operations "REMOVE_ITEM", "REMOVE_DUPLICATES",
  "SORT", "REVERSE", and "FILTER" all now accept a non-existent
  variable as the list since these operations on empty lists is also
  the empty list.

* The "list()" operation "REMOVE_AT" now indicates that the given
  indices are invalid for a non-existent variable or empty list.

* The "try_compile()" and "try_run()" commands gained a new
  "LINK_OPTIONS" option.


Variables
---------

* A "CMAKE_BUILD_RPATH_USE_ORIGIN" variable and corresponding
  "BUILD_RPATH_USE_ORIGIN" target property were added to enable use of
  relative runtime paths (RPATHs). This helps achieving relocatable
  and reproducible builds that are invariant of the build directory.


Properties
----------

* A "CMAKE_ROLE" global property was added to allow scripts to
  determine whether they're running in project mode, script mode,
  find-package mode, CTest, or CPack.

* The "CUDA_RESOLVE_DEVICE_SYMBOLS" target property is now supported
  on shared library, module library, and executable targets.
  Previously it was only honored on static libraries.

* The "EXCLUDE_FROM_ALL" target property was created to override the
  setting of its directory. A target will now be built as part of
  "all" if its "EXCLUDE_FROM_ALL" property is set to "OFF", even if
  its containing directory is marked as "EXCLUDE_FROM_ALL".

* "INTERFACE_POSITION_INDEPENDENT_CODE" target property gains the
  support of "generator expressions".


Modules
-------

* The family of modules to check capabilities (like
  "CheckCSourceCompiles") gain capability to manage "LINK_OPTIONS".

* A "CheckFortranSourceRuns" module was added to provide a
  "check_fortran_source_runs()" command to check if a Fortran source
  snippet compiles and runs.

* The "ExternalProject" module "ExternalProject_Add()" command
  gained "LOG_DIR" and "LOG_MERGED_STDOUTERR" options to control
  logging.

* The "ExternalProject" module "ExternalProject_Add()" command
  gained "LOG_PATCH" to optionally log the patch step.

* The "ExternalProject" module's "ExternalProject_Add" command
  learned to apply "SOURCE_SUBDIR" when "BUILD_IN_SOURCE" is also
  used. The "BUILD_COMMAND" is run in the given "SOURCE_SUBDIR" of the
  "SOURCE_DIR".

* The "FetchContent" module gained a new
  "FetchContent_MakeAvailable()" command.  It accepts a list of
  dependency names, which it then iterates over, populating and adding
  each one to the main build using the canonical pattern.  This
  significantly reduces the amount of boilerplate needed in a project.

* The "FindBISON" module's "BISON_TARGET" command now runs "bison"
  with "CMAKE_CURRENT_BINARY_DIR" as the working directory. See policy
  "CMP0088".

* The "FindCURL" module gained support for requesting protocols as
  package components.

* The "FindFontconfig" module was added to find fontconfig.

* The "FindGDAL" module now provides imported targets.

* The "FindGIF" module now provides imported targets.

* The "FindGit" module now provides an imported target for the Git
  executable.

* The "FindIce" module learned to find "slice2confluence" and
  "slice2matlab".

* The "FindLibinput" module was added to find libinput.

* The "FindLibLZMA" module now provides imported targets.

* The "FindMatlab" module gained new options "R2017b" and "R2018a"
  to specify the MEX API version to use; these options mirror the new
  options to the "mex" command in MATLAB R2018a. The option
  "MX_LIBRARY" is no longer needed.

* A "FindOctave" module was added to find GNU octave.

* The "FindPostgreSQL" module now provides imported targets.

* The "FindPython", "FindPython2", and "FindPython3" modules gained
  support for "NumPy" component.

* The "FindPython2", "FindPython3", and "FindPython" modules now
  support running in script mode by skipping the creation of imported
  targets and helper functions.

* The "FindSQLite3" module was added to find the SQLite v3.x
  library.

* The "FindX11" had the following variables renamed in order to
  match their library names rather than header names. The old
  variables are provided for compatibility:

     * "X11_Xxf86misc_INCLUDE_PATH" instead of
       "X11_xf86misc_INCLUDE_PATH"

     * "X11_Xxf86misc_LIB" instead of "X11_xf86misc_LIB"

     * "X11_Xxf86misc_FOUND" instead of "X11_xf86misc_FOUND"

     * "X11_Xxf86vm_INCLUDE_PATH" instead of
       "X11_xf86vmode_INCLUDE_PATH"

     * "X11_Xxf86vm_LIB" instead of "X11_xf86vmode_LIB"

     * "X11_Xxf86vm_FOUND" instead of "X11_xf86vmode_FOUND"

     * "X11_xkbfile_INCLUDE_PATH" instead of
       "X11_Xkbfile_INCLUDE_PATH"

     * "X11_xkbfile_LIB" instead of "X11_Xkbfile_LIB"

     * "X11_xkbfile_FOUND" instead of "X11_Xkbfile_FOUND"

     * "X11_Xtst_INCLUDE_PATH" instead of "X11_XTest_INCLUDE_PATH"

     * "X11_Xtst_LIB" instead of "X11_XTest_LIB"

     * "X11_Xtst_FOUND" instead of "X11_XTest_FOUND"

     * "X11_Xss_INCLUDE_PATH" instead of
       "X11_Xscreensaver_INCLUDE_PATH"

     * "X11_Xss_LIB" instead of "X11_Xscreensaver_LIB"

     * "X11_Xss_FOUND" instead of "X11_Xscreensaver_FOUND"

  The following variables are deprecated completely since they were
  essentially duplicates:

     * "X11_Xinput_INCLUDE_PATH" (use "X11_Xi_INCLUDE_PATH")

     * "X11_Xinput_LIB" (use "X11_Xi_LIB")

     * "X11_Xinput_FOUND" (use "X11_Xi_FOUND")

* The "FindX11" now provides "X11_Xext_INCLUDE_PATH".

* The "FindX11" now provides imported targets.

* The "UseSWIG" module learned to pass "-module <module_name>" to
  the "SWIG" compiler if the file property "SWIG_MODULE_NAME" is
  defined. See policy "CMP0086".

* The "UseSWIG" module gained an option to specify "SWIG" source
  file extensions.


Generator Expressions
---------------------

* The "$<Fortran_COMPILER_ID:...>" and
  "$<Fortran_COMPILER_VERSION:...>" "generator expressions" were
  added.

* The "$<IN_LIST:...>" generator expression now correctly handles an
  empty argument. See "CMP0085" for details.


Autogen
-------

* The "AUTOMOC_EXECUTABLE", "AUTORCC_EXECUTABLE", and
  "AUTOUIC_EXECUTABLE" target properties were added.  They all take a
  path to an executable and force automoc/autorcc/autouic to use this
  executable.

  Setting these will also prevent the configure time testing for these
  executables. This is mainly useful when you build these tools
  yourself.

* The new variables "CMAKE_GLOBAL_AUTOGEN_TARGET",
  "CMAKE_GLOBAL_AUTOGEN_TARGET_NAME", "CMAKE_GLOBAL_AUTORCC_TARGET"
  and "CMAKE_GLOBAL_AUTORCC_TARGET_NAME" control the generation of
  global "autogen" and "autorcc" targets.

* A new "CMAKE_AUTOGEN_ORIGIN_DEPENDS" variable and
  "AUTOGEN_ORIGIN_DEPENDS" target property may be set to enable or
  disable forwarding of the origin target dependencies to the
  corresponding "_autogen" target.


CTest
-----

* "ctest(1)" gained a "--show-only=json-v1" option to show the list
  of tests in a machine-readable JSON format. See the Show as JSON
  Object Model section of the manual.

* The "ctest_submit()" command learned a new "Done" part that can be
  used to inform CDash that a build is complete and that no more parts
  will be uploaded.

* CTest learned to accept the dashboard server submission URL from a
  single variable.  See the "SubmitURL" setting in "ctest(1)", the
  "CTEST_SUBMIT_URL" variable, and the "SUBMIT_URL" argument of the
  "ctest_submit()" command.


Deprecated and Removed Features
===============================

* An explicit deprecation diagnostic was added for policies
  "CMP0064" and "CMP0065" ("CMP0063" and below were already
  deprecated). The "cmake-policies(7)" manual explains that the OLD
  behaviors of all policies are deprecated and that projects should
  port to the NEW behaviors.

* The "Xcode" generator deprecated support for Xcode versions prior
  to Xcode 5.  Support for those will be dropped in a future version
  of CMake.

* The "FindQt" module is no longer used by the "find_package()"
  command as a find module.  This allows the Qt Project upstream to
  optionally provide its own "QtConfig.cmake" package configuration
  file and have applications use it via "find_package(Qt)" rather than
  "find_package(Qt CONFIG)".  See policy "CMP0084".

* Support for running CMake on Windows XP and Windows Vista has been
  dropped. The precompiled Windows binaries provided on "cmake.org"
  now require Windows 7 or higher.

* CTest no longer supports submissions via "ftp", "scp", "cp", and
  "xmlrpc".  CDash is the only maintained testing dashboard for CTest,
  and it only supports submissions over "http" and "https".


Other Changes
=============

* Object library linking has been fixed to propagate transitive link
  dependencies of object libraries to consuming targets.

* Install rules under "add_subdirectory()" now interleave with those
  in the calling directory. See policy "CMP0082" for details.

* CMake now imposes a maximum recursion limit to prevent a stack
  overflow on scripts that recurse infinitely. The limit can be
  adjusted at runtime with "CMAKE_MAXIMUM_RECURSION_DEPTH".

* When using cppcheck via the "CMAKE_<LANG>_CPPCHECK" variable or
  "<LANG>_CPPCHECK" property, the build will now fail if "cppcheck"
  returns non-zero as configured by its command-line options.

* Required link options to manage Position Independent Executable
  are now added when "POSITION_INDEPENDENT_CODE" is set.  The project
  is responsible for using the "CheckPIESupported" module to check for
  "PIE" support to ensure that the "POSITION_INDEPENDENT_CODE" target
  property will be honored at link time for executables.  This
  behavior is controlled by policy "CMP0083".

* Visual Studio Generators for VS 2010 and above learned to support
  the "VS_DEBUGGER_*" properties on targets created via
  "add_custom_target()".

* The "CPack" module no longer defaults to the "paxr" value in the
  "CPACK_DEBIAN_ARCHIVE_TYPE" variable, because "dpkg" has never
  supported the PAX tar format. The "paxr" value will be mapped to
  "gnutar" and a deprecation message emitted.

From paul at mad-scientist.net  Sat Feb  9 12:29:23 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Sat, 09 Feb 2019 12:29:23 -0500
Subject: [CMake] OBJECT libraries getting fully support?
Message-ID: <a9c02c840e71a13405c698ca0eb6d9275d0a463a.camel@mad-scientist.net>

Hi all;

I saw an email to the list from Chuck Atkins in the summer of 2017
suggesting that OBJECT libraries were being enhanced and could become
fully-functional libraries hopefully sometime that year.  I'm wondering
if that ever actally happened and if so what release of cmake it was
in, and if not is there still a plan for this sometime?

I'm trying to convert a large and complex cmake environment originally
started in 2007 or so, which uses all old-school cmake facilities, to
use modern cmake methods.

I have a situation where we have a library containing basic methods
which can be implemented multiple ways and different executables use
different implementations.  However these methods are used by all sorts
of static libraries as well.

Since we don't know until executable link time which library to use,
the static libraries cannot depend on the base library: it has to be
listed only in the executable's target_link_libraries.  But of course
because the static libraries use them as well we need the base library
to be listed last (or near last) in the link line else we get undefined
symbols.  Adding the base library to the executable TLL doesn't allow
us to do that.

So I was thinking of making this base library an OBJECT library so it
would always be fully linked but it seems that our version of cmake
doesn't allow an OBJECT library to be used as a normal library and I'd
be reduced to adding lots of generator expressions for it everywhere
which is a huge PITA.

Any ideas on how best to address this situation, if OBJECT libraries
are not supported yet?


From jon.haitz.legarreta at gmail.com  Mon Feb 11 12:02:49 2019
From: jon.haitz.legarreta at gmail.com (=?UTF-8?Q?Jon_Haitz_Legarreta_Gorro=C3=B1o?=)
Date: Mon, 11 Feb 2019 12:02:49 -0500
Subject: [CMake] [CMAKE] Disable testing when building using bootstrap
Message-ID: <CAPUXxNEf0ein=g_Kpe3+wuiO36TBJ5FDnuyPfNE=8BgtLr7y=Q@mail.gmail.com>

Hi,

I'm trying to build CMake from sources using the `bootstrap` script.

Please, correct me if I'm wrong, but it looks like CMake is being
built with `BUILD_TESTING=ON` by default.

I'd like to disable testing (and any other non-essential option), but
AFAIK bootstrap does not expose the `-DBUILD_TESTING` flag, or I have
not found a way to set it to `OFF`.

Is this possible / does this make sense at all? Can anyone please
provide me with the pointers to do so?

Thank you,
JON HAITZ

From tjwrona1992 at gmail.com  Mon Feb 11 15:27:00 2019
From: tjwrona1992 at gmail.com (Timothy Wrona)
Date: Mon, 11 Feb 2019 15:27:00 -0500
Subject: [CMake] What is the best practice for installing custom CMake
 modules?
Message-ID: <CAGrOMv0YzKSYvKAz+T3WgTTkGFuUbOsisi553vz9HNJzpgQ3Lg@mail.gmail.com>

I've written a custom CMake module (MyModule.cmake) and would like to
install it in a sensible location on my system so my other CMake projects
can find it easily.

First of all, is there an accepted standard way of doing this?
If not, is my approach below acceptable and considered good practice?

I have taken the following approach:

*Project structure:*

MyModule
    |---CMakeLists.txt
    |---MyModule.cmake
    |---MyModuleConfig.cmake

*Contents of CMakeLists.txt:*

cmake_minimum_required(VERSION 3.13.0)

project(MyModule)

install(
  FILES
    ${CMAKE_CURRENT_SOURCE_DIR}/MyModuleConfig.cmake
    ${CMAKE_CURRENT_SOURCE_DIR}/MyModule.cmake
  DESTINATION
    share/cmake/${PROJECT_NAME}
)

*Contents of MyModule.cmake:*

message(STATUS "included: my-module.cmake")

*Contents of MyModuleConfig.cmake*

# Add this module's directory to the "CMAKE_MODULE_PATH" so it is visible
after calling "find_package()"
list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR})

--------------------------------
The module can easily be built and installed with the following commands:

cmake -S . -B build
cmake --build build --target install

--------------------------------
Once installed, the module can be used in any future CMake project as
follows:

find_package(MyModule)
include(MyModule)

This approach seems to work quite well and is very easy to use, but I feel
like modifying "CMAKE_MODULE_PATH" from "MyModuleConfig.cmake" is not
really a standard way of doing things because I've never seen it done
before.

Is this approach considered okay? Or is there a better more accepted way to
easily make your own CMake modules visible from other projects?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190211/fb8da495/attachment.html>

From marc.herbert at gmail.com  Mon Feb 11 20:56:34 2019
From: marc.herbert at gmail.com (Marc Herbert)
Date: Mon, 11 Feb 2019 17:56:34 -0800
Subject: [CMake] Syntax to document cmake files, functions and macros
In-Reply-To: <204B048D-7540-402B-B5E8-081C897C131A@Robitzki.de>
References: <cc023f8c-3905-b470-a2a6-ad57a00150a0@free.fr>
 <1506c326-ebba-3f1d-32b3-7ac8f0100d4f@gmail.com>
 <75AF606E-AE0C-4129-9290-0854F395F333@gmail.com>
 <204B048D-7540-402B-B5E8-081C897C131A@Robitzki.de>
Message-ID: <CA+rkZbikAV8w9NA7bn1UOhNGzp5P9b8spXDAhgfkar0y8800yw@mail.gmail.com>

Le jeu. 31 janv. 2019 ? 23:09, Torsten Robitzki <Torsten at robitzki.de> a
?crit :

>
> We are working on a larger CMake project and we use Sphinx. We use
> sphinxcontrib.moderncmakedomain as extension, which adds CMake syntax
> highlighting and sphinx.ext.intersphinx to allow us, to refer to the
> original CMake documentation.
>

Thanks Torsten, that was really useful. I was reluctant to spend time
understanding the project's build system (cause it has... no documentation
outside the source ;-) but I'm glad I did, now it's mostly just:

pip3 install --user sphinxcontrib-moderncmakedomain

.. cmake-module:: does/not/have/to/be/a/module.cmake

More details at https://pypi.org/project/sphinxcontrib-moderncmakedomain/

I didn't try sphinx.ext.intersphinx.

I'm still a bit confused about Kitware's official stance about this sphinx
extension though. Quoting:

- https://pypi.org/project/sphinxcontrib-moderncmakedomain/
"I will do my best to keep this module in sync with the one that Kitware
uses themselves."
apparently a selection from:
https://github.com/Kitware/CMake/tree/master/Utilities/Sphinx/
- https://cmake.org/cmake/help/v3.13/manual/cmake-developer.7.html
This manual is intended for reference by developers modifying the CMake
source tree itself, and by those authoring externally-maintained modules.

So while sphinxcontrib-moderncmakedomain seems to just work on any .cmake
file, it's not officially supported beyond modules and not distributed for
all users in pre-built packages?

There are (too) many developers who don't want to go anywhere near their
own build system. There are even more who don't want to go near a build
system with an indirection like CMake. Something like
sphinxcontrib-moderncmakedomain would really help there IMHO.

Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190211/b7c4447d/attachment.html>

From starka at fit.vutbr.cz  Tue Feb 12 02:02:43 2019
From: starka at fit.vutbr.cz (Starka =?iso-8859-2?b?VG9t4bk=?=)
Date: Tue, 12 Feb 2019 08:02:43 +0100
Subject: [CMake] link only with targets feature
Message-ID: <20190212080243.19586rdkzpu0ba1f@email.fit.vutbr.cz>

tldr;
It would be wonderful to have function or signature for  
target_link_libraries tha would link only to a targets. Did I overlook  
something?

like target_link_libraries(name [PUBLIC...] TARGETS myFavouriteLib ...  
QUIET/VERBOSE)

(*read with the voice of a child*)

Dear CMake developers, dear Santa
I wish you could make the mess of using "fake namespace" notation go  
away. I no longer know what to link to when i write  
find_package(myFavouriteLib). In cmake 2.6, 2.8 there was a set of  
variables, which you need to get from the FindmyFavouriteLib.cmake.  
Smart people used MYFAVOURITELIB_INCLUDE_DIR and  
MYFAVOURITELIB_LIBRARY. Well sometimes a plural but mostly just that.  
Then there came the targets. A really nice way of packing all the  
things together and then it mostly got even simpler - link to the same  
string you provided to the find_package. So myFavouriteLib or in case  
of having a COMPONENTS a 'componentName'. But some spooky people were  
constantly making mistakes about not checking their targets and so for  
the sake of the backward compatibility with the target_link_libraries  
someone brought a "fake namespace" to once again break the backward  
compatibility. Some of the libraries changed the string to link to  
again from myFavouriteLib to myFavouriteLib::myFavouriteLib (e.g.  
assimp, and thanks to my colleague for that, but their cmake config  
never really worked anyway) which is horribly long and now I need to  
change every cmake that uses it. Well in some cases I changed only the  
custom find module but since I can't effectively alias imported  
targets (that aren't globaly vissible, wtf) nor I could clone them  
(WHYYYYYYYY?, did I again overlook something) it was a hell and the  
code is unnecesserily long. But now once again I don't know what to  
link to when calling find_package. It could be anything from  
myFavouriteLib, myFavouriteLib::myFavouriteLib,  
myFavouriteLib::component, MFL::component, component, and more (glm,  
Qt, OpenSceneGraph...). The programmers (myself included) seldomly  
have a time to write a proper documentation for their libraries (like  
Qt or Java do) and moreover this goes for documenting their cmake  
behaviour. So I once again need to go through the code to realy find  
what to link to. What a mess.
But then I guess it wouldn't hurt to have something like  
target_link_libraries(name [PUBLIC...] TARGETS myFavouriteLib ...  
QUIET/VERBOSE) which would not try to give linker myFavouriteLib.lib  
if there was no target of that name in question. Or  
target_link_targets... realy doesn't matter as long as it does that  
and maybe when asked by the last parameter it gives an error if the  
one of the target is non-existent or ill-formed. And maybe then after  
couple of years when the dusts settles (after otherwise great talk  
from Daniel Pfeifer on cppCon) we could see the cmakes that when you  
know the name of the library, you don't need to search throu the code  
to find what you are supposed to link to like glm.
Eventhough this doesn't look like it, it is just a short 'story' to  
pinpoint, from my perspective, one of the biggest flaw in one great  
configuration system. There could be done lot of the arguments for  
every thing I mentioned and lot's of problems that I for sake of  
simplicity didn't. After 10 years of using cmake and couple of years  
of trying to teach it to people that knows only a makefile and  
sometimes a bit about MSVC I came across a lot. And for me this class  
of problems boils down to the inconsistency between the find_package  
call and what you get from it. I now that it is great, that librety of  
doing what ever you want in that config script, but...
Hope I don't spark a flame war about the naming conventions. I would  
like this proposal to be calmly considered. In best case just say that  
I'm an idiot and there is exactly that feature since 3.x.x.

Best regards

forry


From robb at datalogics.com  Tue Feb 12 12:54:28 2019
From: robb at datalogics.com (Rob Boehne)
Date: Tue, 12 Feb 2019 17:54:28 +0000
Subject: [CMake] [SPAM] Re: resource installation
In-Reply-To: <CAFzjYVp5AghsbhMepScWuxAf5VWLkVmWQvvmKBZKTsG+-0s5Aw@mail.gmail.com>
References: <FCE08CDB-2FEB-466B-BA76-41AA4AD675D1@datalogics.com>
 <763DC666-977D-4873-A4DC-7FD6DE12CE7E@datalogics.com>
 <CAFzjYVp5AghsbhMepScWuxAf5VWLkVmWQvvmKBZKTsG+-0s5Aw@mail.gmail.com>
Message-ID: <2EF478FE-33E5-4606-94DE-638619A989D3@datalogics.com>

Hmmm, I think I've found a bug.  Here is what I have in my top-level CMakeLists.txt file:


if(WIN32)
    #
    # run the script to install the resources
    #
    set(RI_RESULT " ")
    set(RI_OUTPUT " ")
    set(RI_ERROR " ")
    
    install(CODE "message(\"running ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")")

    install(CODE execute_process(COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}
                                 RESULT_VARIABLE RI_RESULT
                                 OUTPUT_VARIABLE RI_OUTPUT
                                 ERROR_VARIABLE RI_ERROR
                                 OUTPUT_FILE ResInst.out
                                 ERROR_FILE ResInst.err )
           )

    install(CODE "message(\"ResourceInstall results \\\"${RI_RESULT}\\\" output: \\\"${RI_OUTPUT}\\\"  error: \\\"${RI_ERROR}\\\" \")")

endif()


(As you can see I haven't figured out quoting yet)
This is what comes out of the above code:


if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
  message("running C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release")
endif()

if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
  execute_process(COMMAND "C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release"
        WORKING_DIRECTORY C:/Users/robb/Development/apdfl-sandbox/pdfl15_all
        RESULT_VARIABLE RI_RESULT
        OUTPUT_VARIABLE RI_OUTPUT
        ERROR_VARIABLE RI_ERROR
        OUTPUT_FILE ResInst.out
        ERROR_FILE ResInst.err ")
endif()

if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
  message("ResourceInstall results  output:   error:  ")
endif()


From cmake 3.12.2 on Win64.  The issue is the closing quote inside "execute_process"  which appears to have been magically added by cmake.
When I run the cmake_install.cmake as is it fails on that line:


CMake Error at cmake_install.cmake:87:
  Parse error.  Function missing ending ")".  Instead found unterminated
  string with text ")

  ".

If I remove that stray double quote, it runs, doing all the subdir install tasks, but still doesn't run the ResourceInstall.bat file.
And it generates the error:

1>  -- Installing: C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/cmake_vs2013/../dist/x64/release/Resources/Sample_Input/XPStoPDF.xps
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: The command "setlocal
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: "C:\Program Files\CMake\bin\cmake.exe" -DBUILD_TYPE=RelWithDebInfo -P cmake_install.cmake
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :cmEnd
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :cmErrorLevel
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: exit /b %1
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :cmDone
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :VCEnd" exited with code -1.
1>Done executing task "Exec" -- FAILED.
1>Done building target "PostBuildEvent" in project "INSTALL.vcxproj" -- FAILED.
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:29.40
========== Build: 0 succeeded, 1 failed, 31 up-to-date, 0 skipped ==========


I know the batch file does not get run because I have statements at the top that create a file before anything else, and it also sends output to stdout.

Any advice on how I can move forward here?

Thanks,

Rob Boehne



?On 2/5/19, 4:09 PM, "Robert Maynard" <robert.maynard at kitware.com> wrote:

    If you add 'OUTPUT_VARIABLE' and 'ERROR_VARIABLE' information to the
    execute_process call you should be able to dump the information using
    'message' and see if the execute_process is running.
    
    
    On Tue, Jan 29, 2019 at 3:04 PM Rob Boehne <robb at datalogics.com> wrote:
    >
    > I?m still not getting this script executed.  I can copy the ?message? output and run it ? and it does what I want, and I see it in cmake_install.cmake ? the message() and execute_process() calls are inside of identical conditionals, but there?s no indication that it is executing, or that there was any sort of problem.
    >
    > How do I get it to actually execute?
    >
    >
    >
    > In cmake_install.cmake:
    >
    >
    >
    > if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
    >
    >   message("running C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release")
    >
    > endif()
    >
    >
    >
    > if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
    >
    >   execute_process(COMMAND "C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release")
    >
    > endif()
    >
    >
    >
    >
    >
    > From: CMake <cmake-bounces at cmake.org> on behalf of Rob Boehne <robb at datalogics.com>
    > Date: Thursday, January 24, 2019 at 9:49 AM
    > To: "cmake at cmake.org" <cmake at cmake.org>
    > Subject: [SPAM] Re: [CMake] resource installation
    >
    >
    >
    > Maybe because I misspelled it?  Yes.  Because I misspelled the script name.
    >
    >
    >
    > From: CMake <cmake-bounces at cmake.org> on behalf of Rob Boehne <robb at datalogics.com>
    > Date: Thursday, January 24, 2019 at 9:40 AM
    > To: "cmake at cmake.org" <cmake at cmake.org>
    > Subject: [SPAM] [CMake] resource installation
    >
    >
    >
    > All,
    >
    >
    >
    > I?m attempting to install resource files (Fonts, etc.) into my product.  To that end, I have added this chunk of code to run a batch file that will copy resources into the tree:
    >
    >
    >
    > if(WIN32)
    >
    >     #
    >
    >     # run the script to install the resources
    >
    >     #
    >
    >     install(CODE "message(\"running ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")")
    >
    >     install(CODE "execute_process(COMMAND \"${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")")
    >
    > endif()
    >
    >
    >
    > I see the output of the first line when I run the INSTALL target in VS 2013, but it seems as though the script isn?t run.
    >
    > 1>  -- Install configuration: "RelWithDebInfo"
    >
    > 1>  running C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release
    >
    > 1>  -- Installing: C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/cmake_build/../dist/x64/release/CPlusPlus/Binaries/DL150BIBUtils.lib
    >
    >
    >
    > So the message is there, but the script isn?t run.
    >
    >
    >
    > I?m I missing a dependency, or formatting the string incorrectly?  How do I debug this?
    >
    >
    >
    > Thanks,
    >
    >
    >
    > Rob
    >
    >
    >
    >
    >
    > Rob Boehne
    >
    > Senior Software Architect | Datalogics, Inc.
    >
    > +1.312.853.8351 | robb at datalogics.com
    >
    > datalogics.com | blogs.datalogics.com
    >
    > Connect with us: Facebook | Twitter | LinkedIn | YouTube
    >
    >
    >
    >
    >
    > --
    >
    > 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:
    > https://cmake.org/mailman/listinfo/cmake
    


From robert.maynard at kitware.com  Tue Feb 12 13:24:09 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 12 Feb 2019 13:24:09 -0500
Subject: [CMake] [CMAKE] Disable testing when building using bootstrap
In-Reply-To: <CAPUXxNEf0ein=g_Kpe3+wuiO36TBJ5FDnuyPfNE=8BgtLr7y=Q@mail.gmail.com>
References: <CAPUXxNEf0ein=g_Kpe3+wuiO36TBJ5FDnuyPfNE=8BgtLr7y=Q@mail.gmail.com>
Message-ID: <CAFzjYVp6Uy8yOSbRNOS5pGbV3bZ7Hegpt6a+U9hPFUQmrzGDVQ@mail.gmail.com>

You can pass CMake arguments to the bootstrap by doing:

./bootstrap <options> -- -DBUILD_TESTING=OFF

On Mon, Feb 11, 2019 at 12:03 PM Jon Haitz Legarreta Gorro?o
<jon.haitz.legarreta at gmail.com> wrote:
>
> Hi,
>
> I'm trying to build CMake from sources using the `bootstrap` script.
>
> Please, correct me if I'm wrong, but it looks like CMake is being
> built with `BUILD_TESTING=ON` by default.
>
> I'd like to disable testing (and any other non-essential option), but
> AFAIK bootstrap does not expose the `-DBUILD_TESTING` flag, or I have
> not found a way to set it to `OFF`.
>
> Is this possible / does this make sense at all? Can anyone please
> provide me with the pointers to do so?
>
> Thank you,
> JON HAITZ
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake

From robb at datalogics.com  Tue Feb 12 14:12:55 2019
From: robb at datalogics.com (Rob Boehne)
Date: Tue, 12 Feb 2019 19:12:55 +0000
Subject: [CMake] [SPAM] Re:  [SPAM] Re: resource installation
In-Reply-To: <2EF478FE-33E5-4606-94DE-638619A989D3@datalogics.com>
References: <FCE08CDB-2FEB-466B-BA76-41AA4AD675D1@datalogics.com>
 <763DC666-977D-4873-A4DC-7FD6DE12CE7E@datalogics.com>
 <CAFzjYVp5AghsbhMepScWuxAf5VWLkVmWQvvmKBZKTsG+-0s5Aw@mail.gmail.com>
 <2EF478FE-33E5-4606-94DE-638619A989D3@datalogics.com>
Message-ID: <C2FE794E-6AD3-4A11-9A43-2AC55F701AC0@datalogics.com>

The same behavior is also present in version 3.14.0-rc1.

?On 2/12/19, 11:54 AM, "CMake on behalf of Rob Boehne" <cmake-bounces at cmake.org on behalf of robb at datalogics.com> wrote:

    Hmmm, I think I've found a bug.  Here is what I have in my top-level CMakeLists.txt file:
    
    
    if(WIN32)
        #
        # run the script to install the resources
        #
        set(RI_RESULT " ")
        set(RI_OUTPUT " ")
        set(RI_ERROR " ")
        
        install(CODE "message(\"running ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")")
    
        install(CODE execute_process(COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}
                                     RESULT_VARIABLE RI_RESULT
                                     OUTPUT_VARIABLE RI_OUTPUT
                                     ERROR_VARIABLE RI_ERROR
                                     OUTPUT_FILE ResInst.out
                                     ERROR_FILE ResInst.err )
               )
    
        install(CODE "message(\"ResourceInstall results \\\"${RI_RESULT}\\\" output: \\\"${RI_OUTPUT}\\\"  error: \\\"${RI_ERROR}\\\" \")")
    
    endif()
    
    
    (As you can see I haven't figured out quoting yet)
    This is what comes out of the above code:
    
    
    if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
      message("running C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release")
    endif()
    
    if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
      execute_process(COMMAND "C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release"
            WORKING_DIRECTORY C:/Users/robb/Development/apdfl-sandbox/pdfl15_all
            RESULT_VARIABLE RI_RESULT
            OUTPUT_VARIABLE RI_OUTPUT
            ERROR_VARIABLE RI_ERROR
            OUTPUT_FILE ResInst.out
            ERROR_FILE ResInst.err ")
    endif()
    
    if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
      message("ResourceInstall results  output:   error:  ")
    endif()
    
    
    From cmake 3.12.2 on Win64.  The issue is the closing quote inside "execute_process"  which appears to have been magically added by cmake.
    When I run the cmake_install.cmake as is it fails on that line:
    
    
    CMake Error at cmake_install.cmake:87:
      Parse error.  Function missing ending ")".  Instead found unterminated
      string with text ")
    
      ".
    
    If I remove that stray double quote, it runs, doing all the subdir install tasks, but still doesn't run the ResourceInstall.bat file.
    And it generates the error:
    
    1>  -- Installing: C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/cmake_vs2013/../dist/x64/release/Resources/Sample_Input/XPStoPDF.xps
    1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: The command "setlocal
    1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: "C:\Program Files\CMake\bin\cmake.exe" -DBUILD_TYPE=RelWithDebInfo -P cmake_install.cmake
    1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd
    1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :cmEnd
    1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
    1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :cmErrorLevel
    1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: exit /b %1
    1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :cmDone
    1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd
    1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :VCEnd" exited with code -1.
    1>Done executing task "Exec" -- FAILED.
    1>Done building target "PostBuildEvent" in project "INSTALL.vcxproj" -- FAILED.
    1>
    1>Build FAILED.
    1>
    1>Time Elapsed 00:00:29.40
    ========== Build: 0 succeeded, 1 failed, 31 up-to-date, 0 skipped ==========
    
    
    I know the batch file does not get run because I have statements at the top that create a file before anything else, and it also sends output to stdout.
    
    Any advice on how I can move forward here?
    
    Thanks,
    
    Rob Boehne
    
    
    
    On 2/5/19, 4:09 PM, "Robert Maynard" <robert.maynard at kitware.com> wrote:
    
        If you add 'OUTPUT_VARIABLE' and 'ERROR_VARIABLE' information to the
        execute_process call you should be able to dump the information using
        'message' and see if the execute_process is running.
        
        
        On Tue, Jan 29, 2019 at 3:04 PM Rob Boehne <robb at datalogics.com> wrote:
        >
        > I?m still not getting this script executed.  I can copy the ?message? output and run it ? and it does what I want, and I see it in cmake_install.cmake ? the message() and execute_process() calls are inside of identical conditionals, but there?s no indication that it is executing, or that there was any sort of problem.
        >
        > How do I get it to actually execute?
        >
        >
        >
        > In cmake_install.cmake:
        >
        >
        >
        > if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
        >
        >   message("running C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release")
        >
        > endif()
        >
        >
        >
        > if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
        >
        >   execute_process(COMMAND "C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release")
        >
        > endif()
        >
        >
        >
        >
        >
        > From: CMake <cmake-bounces at cmake.org> on behalf of Rob Boehne <robb at datalogics.com>
        > Date: Thursday, January 24, 2019 at 9:49 AM
        > To: "cmake at cmake.org" <cmake at cmake.org>
        > Subject: [SPAM] Re: [CMake] resource installation
        >
        >
        >
        > Maybe because I misspelled it?  Yes.  Because I misspelled the script name.
        >
        >
        >
        > From: CMake <cmake-bounces at cmake.org> on behalf of Rob Boehne <robb at datalogics.com>
        > Date: Thursday, January 24, 2019 at 9:40 AM
        > To: "cmake at cmake.org" <cmake at cmake.org>
        > Subject: [SPAM] [CMake] resource installation
        >
        >
        >
        > All,
        >
        >
        >
        > I?m attempting to install resource files (Fonts, etc.) into my product.  To that end, I have added this chunk of code to run a batch file that will copy resources into the tree:
        >
        >
        >
        > if(WIN32)
        >
        >     #
        >
        >     # run the script to install the resources
        >
        >     #
        >
        >     install(CODE "message(\"running ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")")
        >
        >     install(CODE "execute_process(COMMAND \"${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")")
        >
        > endif()
        >
        >
        >
        > I see the output of the first line when I run the INSTALL target in VS 2013, but it seems as though the script isn?t run.
        >
        > 1>  -- Install configuration: "RelWithDebInfo"
        >
        > 1>  running C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release
        >
        > 1>  -- Installing: C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/cmake_build/../dist/x64/release/CPlusPlus/Binaries/DL150BIBUtils.lib
        >
        >
        >
        > So the message is there, but the script isn?t run.
        >
        >
        >
        > I?m I missing a dependency, or formatting the string incorrectly?  How do I debug this?
        >
        >
        >
        > Thanks,
        >
        >
        >
        > Rob
        >
        >
        >
        >
        >
        > Rob Boehne
        >
        > Senior Software Architect | Datalogics, Inc.
        >
        > +1.312.853.8351 | robb at datalogics.com
        >
        > datalogics.com | blogs.datalogics.com
        >
        > Connect with us: Facebook | Twitter | LinkedIn | YouTube
        >
        >
        >
        >
        >
        > --
        >
        > 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:
        > https://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:
    https://cmake.org/mailman/listinfo/cmake
    


From neundorf at kde.org  Tue Feb 12 15:23:35 2019
From: neundorf at kde.org (Alexander Neundorf)
Date: Tue, 12 Feb 2019 21:23:35 +0100
Subject: [CMake] link only with targets feature
In-Reply-To: <20190212080243.19586rdkzpu0ba1f@email.fit.vutbr.cz>
References: <20190212080243.19586rdkzpu0ba1f@email.fit.vutbr.cz>
Message-ID: <1789850.IxbgPI5ZMA@linux-l7nd>

On 2019 M02 12, Tue 08:02:43 CET Starka Tom?? wrote:
> tldr;
> It would be wonderful to have function or signature for
> target_link_libraries tha would link only to a targets. Did I overlook
> something?
> 
> like target_link_libraries(name [PUBLIC...] TARGETS myFavouriteLib ...
> QUIET/VERBOSE)
> 
...
> But then I guess it wouldn't hurt to have something like
> target_link_libraries(name [PUBLIC...] TARGETS myFavouriteLib ...
> QUIET/VERBOSE) which would not try to give linker myFavouriteLib.lib
> if there was no target of that name in question. Or
> target_link_targets... realy doesn't matter as long as it does that
> and maybe when asked by the last parameter it gives an error if the
> one of the target is non-existent or ill-formed. 

I agree to target_link_targets().
Additionally I would prefer if (maybe with a policy) include directories would 
be only applied when using target_link_targets(), but not when using 
target_link_libraries().
This would make it more obvious IMO.

Alex


From jon.haitz.legarreta at gmail.com  Tue Feb 12 17:51:03 2019
From: jon.haitz.legarreta at gmail.com (=?UTF-8?Q?Jon_Haitz_Legarreta_Gorro=C3=B1o?=)
Date: Tue, 12 Feb 2019 17:51:03 -0500
Subject: [CMake] [CMAKE] Disable testing when building using bootstrap
In-Reply-To: <CAFzjYVp6Uy8yOSbRNOS5pGbV3bZ7Hegpt6a+U9hPFUQmrzGDVQ@mail.gmail.com>
References: <CAPUXxNEf0ein=g_Kpe3+wuiO36TBJ5FDnuyPfNE=8BgtLr7y=Q@mail.gmail.com>
 <CAFzjYVp6Uy8yOSbRNOS5pGbV3bZ7Hegpt6a+U9hPFUQmrzGDVQ@mail.gmail.com>
Message-ID: <CAPUXxNFnsW88gfVrha-8U=WEZTOr7c9vFZErSK+owBhAMcnefw@mail.gmail.com>

Hi Robert,
thanks. That answers the question !

Cheers,
JON HAITZ

On Tue, Feb 12, 2019 at 1:24 PM Robert Maynard
<robert.maynard at kitware.com> wrote:
>
> You can pass CMake arguments to the bootstrap by doing:
>
> ./bootstrap <options> -- -DBUILD_TESTING=OFF
>
> On Mon, Feb 11, 2019 at 12:03 PM Jon Haitz Legarreta Gorro?o
> <jon.haitz.legarreta at gmail.com> wrote:
> >
> > Hi,
> >
> > I'm trying to build CMake from sources using the `bootstrap` script.
> >
> > Please, correct me if I'm wrong, but it looks like CMake is being
> > built with `BUILD_TESTING=ON` by default.
> >
> > I'd like to disable testing (and any other non-essential option), but
> > AFAIK bootstrap does not expose the `-DBUILD_TESTING` flag, or I have
> > not found a way to set it to `OFF`.
> >
> > Is this possible / does this make sense at all? Can anyone please
> > provide me with the pointers to do so?
> >
> > Thank you,
> > JON HAITZ
> > --
> >
> > 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:
> > https://cmake.org/mailman/listinfo/cmake

From paul at mad-scientist.net  Tue Feb 12 18:35:12 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Tue, 12 Feb 2019 18:35:12 -0500
Subject: [CMake] OBJECT libraries getting fully support?
In-Reply-To: <a9c02c840e71a13405c698ca0eb6d9275d0a463a.camel@mad-scientist.net>
References: <a9c02c840e71a13405c698ca0eb6d9275d0a463a.camel@mad-scientist.net>
Message-ID: <b42611ef98a181d5fca18ed2ad20dfef12f5f1fc.camel@mad-scientist.net>

Don't want to be a noodge but wondering if anyone has any thoughts
about this question or ideas on how to solve my problem?


On Sat, 2019-02-09 at 12:29 -0500, Paul Smith wrote:
> Hi all;
> 
> I saw an email to the list from Chuck Atkins in the summer of 2017
> suggesting that OBJECT libraries were being enhanced and could become
> fully-functional libraries hopefully sometime that year.  I'm wondering
> if that ever actally happened and if so what release of cmake it was
> in, and if not is there still a plan for this sometime?
> 
> I'm trying to convert a large and complex cmake environment originally
> started in 2007 or so, which uses all old-school cmake facilities, to
> use modern cmake methods.
> 
> I have a situation where we have a library containing basic methods
> which can be implemented multiple ways and different executables use
> different implementations.  However these methods are used by all sorts
> of static libraries as well.
> 
> Since we don't know until executable link time which library to use,
> the static libraries cannot depend on the base library: it has to be
> listed only in the executable's target_link_libraries.  But of course
> because the static libraries use them as well we need the base library
> to be listed last (or near last) in the link line else we get undefined
> symbols.  Adding the base library to the executable TLL doesn't allow
> us to do that.
> 
> So I was thinking of making this base library an OBJECT library so it
> would always be fully linked but it seems that our version of cmake
> doesn't allow an OBJECT library to be used as a normal library and I'd
> be reduced to adding lots of generator expressions for it everywhere
> which is a huge PITA.
> 
> Any ideas on how best to address this situation, if OBJECT libraries
> are not supported yet?


From mellery451 at gmail.com  Tue Feb 12 19:19:48 2019
From: mellery451 at gmail.com (Michael Ellery)
Date: Tue, 12 Feb 2019 16:19:48 -0800
Subject: [CMake] OBJECT libraries getting fully support?
In-Reply-To: <b42611ef98a181d5fca18ed2ad20dfef12f5f1fc.camel@mad-scientist.net>
References: <a9c02c840e71a13405c698ca0eb6d9275d0a463a.camel@mad-scientist.net>
 <b42611ef98a181d5fca18ed2ad20dfef12f5f1fc.camel@mad-scientist.net>
Message-ID: <9F9958E3-7DAE-446F-A99E-D41AD40B430B@gmail.com>

https://cmake.org/cmake/help/latest/release/3.12.html says that target_link_libraries got OBJECT in 3.12 - is that what you had in mind?

-Mike

> On Feb 12, 2019, at 3:35 PM, Paul Smith <paul at mad-scientist.net> wrote:
> 
> Don't want to be a noodge but wondering if anyone has any thoughts
> about this question or ideas on how to solve my problem?
> 
> 
> On Sat, 2019-02-09 at 12:29 -0500, Paul Smith wrote:
>> Hi all;
>> 
>> I saw an email to the list from Chuck Atkins in the summer of 2017
>> suggesting that OBJECT libraries were being enhanced and could become
>> fully-functional libraries hopefully sometime that year.  I'm wondering
>> if that ever actally happened and if so what release of cmake it was
>> in, and if not is there still a plan for this sometime?
>> 
>> I'm trying to convert a large and complex cmake environment originally
>> started in 2007 or so, which uses all old-school cmake facilities, to
>> use modern cmake methods.
>> 
>> I have a situation where we have a library containing basic methods
>> which can be implemented multiple ways and different executables use
>> different implementations.  However these methods are used by all sorts
>> of static libraries as well.
>> 
>> Since we don't know until executable link time which library to use,
>> the static libraries cannot depend on the base library: it has to be
>> listed only in the executable's target_link_libraries.  But of course
>> because the static libraries use them as well we need the base library
>> to be listed last (or near last) in the link line else we get undefined
>> symbols.  Adding the base library to the executable TLL doesn't allow
>> us to do that.
>> 
>> So I was thinking of making this base library an OBJECT library so it
>> would always be fully linked but it seems that our version of cmake
>> doesn't allow an OBJECT library to be used as a normal library and I'd
>> be reduced to adding lots of generator expressions for it everywhere
>> which is a huge PITA.
>> 
>> Any ideas on how best to address this situation, if OBJECT libraries
>> are not supported yet?
> 
> -- 
> 
> 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:
> https://cmake.org/mailman/listinfo/cmake


From dmacq at instantiations.com  Tue Feb 12 21:51:18 2019
From: dmacq at instantiations.com (Donald MacQueen [|])
Date: Tue, 12 Feb 2019 21:51:18 -0500
Subject: [CMake] Cdash - Display Start Time in local time zone
Message-ID: <30bedf3a-6a86-5a3d-25e2-b04c3ba92121@instantiations.com>

Greetings,

I understand that start times are stored in UTC.

But I would like the Start Time column in the Dashboard window to 
display those times in my local time zone of 'America/New York' or EST.

I have looked at the code in index.php, but I am not a php expert.

2) Running date in Ubuntu gets this: Tue Feb 12 21:47:16 EST 2019

So why is the CDash browser showing the current time in UTC? Wednesday, 
February 13 2019 02:41:47.

I have my project nightly start time set to 00:00:01 EST.

Thanks in advance.

-- 
Donald [|]
A bad day in [] is better than a good day in {}.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


From paul at mad-scientist.net  Wed Feb 13 13:42:11 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Wed, 13 Feb 2019 13:42:11 -0500
Subject: [CMake] OBJECT libraries getting fully support?
In-Reply-To: <9F9958E3-7DAE-446F-A99E-D41AD40B430B@gmail.com>
References: <a9c02c840e71a13405c698ca0eb6d9275d0a463a.camel@mad-scientist.net>
 <b42611ef98a181d5fca18ed2ad20dfef12f5f1fc.camel@mad-scientist.net>
 <9F9958E3-7DAE-446F-A99E-D41AD40B430B@gmail.com>
Message-ID: <3ff864523c7f012fc10260505ab95a5a84c77c8f.camel@mad-scientist.net>

On Tue, 2019-02-12 at 16:19 -0800, Michael Ellery wrote:
> https://cmake.org/cmake/help/latest/release/3.12.html
>  says that target_link_libraries got OBJECT in 3.12 - is that what
> you had in mind?

Aha!  Of course, we're using the most recent 3.11 version.  Isn't it
always the way it goes?

OK I'll test with a newer version of CMake and see if I can get things
to work.

It would be great if anyone knows of a way to force a library to be
listed "last" (or near the end anyway) of an executable link line
regardless of dependency information described by
target_link_libraries() (when using modern CMake methods).

If I could do that I could avoid needing the OBJECT library in the
first place and just use a STATIC library.


From dev at thiagocrepaldi.com  Thu Feb 14 02:43:18 2019
From: dev at thiagocrepaldi.com (Thiago Crepaldi)
Date: Wed, 13 Feb 2019 23:43:18 -0800
Subject: [CMake] Multiple occurrences of a library on linux (ldd)
In-Reply-To: <CAGrNNLy2GFLJ0SVodOy8HF_OhVOQU3RdRYRdzK2DUENCdjr6+Q@mail.gmail.com>
References: <CAGrNNLy2GFLJ0SVodOy8HF_OhVOQU3RdRYRdzK2DUENCdjr6+Q@mail.gmail.com>
Message-ID: <CAGrNNLxn2iQ5bUrs+1hgQWivsnoBCi626K8YAhY1RA_AJ4506g@mail.gmail.com>

Hello all,

After reading CMake Cookbook I have written my first "complex" CMake build
script based on the superbuild pattern. I am excited to heave a better
understanding on CMake, but I definitely will learn much more from
experience and your kind help.
In summary, the standalone google test application `standalone_gtests`
publicly links to `libdatareader.so` and to pytorch libraries
(`libc10.so`,`libcafee2.so`, `libtorch.so`).
`libdatareader.so` also publicly links to pytorch libraries (I have a
theoretical question on why `standalone_gtests` had to link to pytorch
libraries if `libdatareader.so` already did, but that can wait).

Compilation finishes successfully, but when I try to run
`standalone_gtests`, it aborts because it cant find `libc10.so`.
After executing `ldd standalone_gtests`, the weird result was that there
were two entries for `libc10.so`.
The first one maps to "not found" while the second had the correct path to
the library. `libcaffe2.so`, which is also a pytorch library, has a single
occurrence with full path.
If I add the (...)/pytorch_external/(...) (see ldd output below) path to
LD_LIBRARY_PATH, then everything works, but I would like to avoid this, if
possible.

`ldd ./subprojects/Build/datareaders_core_test/standalone_gtests
libdatareader.so =>
/home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib/libdatareader.so
libcaffe2.so =>
/home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libcaffe2.so
libc10.so => not found
libc10.so =>
/home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libc10.so
(...)`

Have anyone seen multiple entries for the same library on ldd before? Why
is that? Is it because `standalone_gtests` links to libc10.so and to
`libdatareader.so`, which in turn also links to `libc10.so`?
Both CMakeLists.txt (libdatareader and standalone_gtests) succeeds at
find_package(Torch REQUIRED QUIET) commands (${TORCH_LIBRARY} returns the
correct path).


I run the same build on my Mac and everything works fine, so that is
confined to linux environment. I have destroyed my conda environment and
performed multiple clean builds in the process and no luck :(
Hoping this was some sort of ldconfig issue, I tried `sudo ldconfig` and
`sudo rm /etc/ld.so.cache`, but that doesn't fix it.

Any ideas?

best regards,
Thiago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190213/36701fb8/attachment.html>

From itay.chamiel at orcam.com  Thu Feb 14 05:24:26 2019
From: itay.chamiel at orcam.com (Itay Chamiel)
Date: Thu, 14 Feb 2019 12:24:26 +0200
Subject: [CMake] Redundant linking when modifying shared libraries
Message-ID: <CAA1-gOm-GpyGVeYgfPjqJJwse9GG3zQWxCya_77G45ceJBkUxg@mail.gmail.com>

Hi,

I've asked this question on Stack Overflow almost a year ago with no useful
responses (with the same topic if you wish to search for it), so I'm trying
my luck here.

I work on a large commercial C++ project comprised of a couple dozen
dynamically linked shared libraries, each of which has many associated unit
tests. Many libs are also dependent on other libs because a lib for some
specific functionality will use the code from one of the more common libs.
And finally of course there are the production executables which depend on
the libs.

There is no question that a change in the API (a header file) of some core
common lib should trigger a major recompilation of nearly the entire
system. But typically there is only a change in some function's
implementation, and the only file compiled is the modified .cpp file, and
in theory just the modified lib would need to be linked - thanks to dynamic
linking there should be no need to relink anything else. But CMake goes
ahead and does it anyway: after relinking the lib it relinks all the unit
tests associated with that lib. Then it relinks all the libs in that lib's
dependency tree and all their unit tests. Finally it relinks the production
executables. Due to the scale of the project this takes a lot of precious
time.

I have reproduced this behavior with a simple project based on the example
at cmake.org/examples (comments removed for brevity and lib type changed to
shared). My system is Ubuntu 16 on an Intel PC and my CMake version is
3.5.1.

Start with an empty directory. Create subdirectories Demo and Hello and
then create these files:

* CMakeLists.txt

cmake_minimum_required (VERSION 2.8.11)
project (HELLO)
add_subdirectory (Hello)
add_subdirectory (Demo)

* Demo/CMakeLists.txt

add_executable (helloDemo demo.cpp)
target_link_libraries (helloDemo LINK_PUBLIC Hello)

* Demo/demo.cpp

#include "hello.h"
int main() { hello(); }

* Hello/CMakeLists.txt

add_library (Hello SHARED hello.cpp)
target_include_directories (Hello PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})

* Hello/hello.h

void hello();

* Hello/hello.cpp

#include <stdio.h>
void hello() { printf("hello!\n"); }

* now run the commands:

mkdir build
cd build
cmake ../
make

* You may now execute Demo/helloDemo and see hello!.

Now, touch Hello/hello.cpp and make again. You will see that libHello is
built and linked as expected, but then the helloDemo executable is also
relinked ("Linking CXX executable helloDemo"). The latter step is
completely redundant; even if hello.cpp is modified to print a different
string the relinked executable remains binary identical.

Is there a way to prevent these redundant build actions? This would be a
huge time saver for us.

Thank you,

itay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190214/163dc7d1/attachment.html>

From craig.scott at crascit.com  Thu Feb 14 05:38:48 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Thu, 14 Feb 2019 21:38:48 +1100
Subject: [CMake] Redundant linking when modifying shared libraries
In-Reply-To: <CAA1-gOm-GpyGVeYgfPjqJJwse9GG3zQWxCya_77G45ceJBkUxg@mail.gmail.com>
References: <CAA1-gOm-GpyGVeYgfPjqJJwse9GG3zQWxCya_77G45ceJBkUxg@mail.gmail.com>
Message-ID: <CA+dygYku2fCFHqd600SJkSKPoiw9Bxge-FBYRzNc8DPWCknAUw@mail.gmail.com>

On Thu, Feb 14, 2019 at 9:24 PM Itay Chamiel <itay.chamiel at orcam.com> wrote:

> Hi,
>
> I've asked this question on Stack Overflow almost a year ago with no
> useful responses (with the same topic if you wish to search for it), so I'm
> trying my luck here.
>
> I work on a large commercial C++ project comprised of a couple dozen
> dynamically linked shared libraries, each of which has many associated unit
> tests. Many libs are also dependent on other libs because a lib for some
> specific functionality will use the code from one of the more common libs.
> And finally of course there are the production executables which depend on
> the libs.
>
> There is no question that a change in the API (a header file) of some core
> common lib should trigger a major recompilation of nearly the entire
> system. But typically there is only a change in some function's
> implementation, and the only file compiled is the modified .cpp file, and
> in theory just the modified lib would need to be linked - thanks to dynamic
> linking there should be no need to relink anything else. But CMake goes
> ahead and does it anyway: after relinking the lib it relinks all the unit
> tests associated with that lib. Then it relinks all the libs in that lib's
> dependency tree and all their unit tests. Finally it relinks the production
> executables. Due to the scale of the project this takes a lot of precious
> time.
>
> I have reproduced this behavior with a simple project based on the example
> at cmake.org/examples (comments removed for brevity and lib type changed
> to shared). My system is Ubuntu 16 on an Intel PC and my CMake version is
> 3.5.1.
>
> Start with an empty directory. Create subdirectories Demo and Hello and
> then create these files:
>
> * CMakeLists.txt
>
> cmake_minimum_required (VERSION 2.8.11)
> project (HELLO)
> add_subdirectory (Hello)
> add_subdirectory (Demo)
>
> * Demo/CMakeLists.txt
>
> add_executable (helloDemo demo.cpp)
> target_link_libraries (helloDemo LINK_PUBLIC Hello)
>
> * Demo/demo.cpp
>
> #include "hello.h"
> int main() { hello(); }
>
> * Hello/CMakeLists.txt
>
> add_library (Hello SHARED hello.cpp)
> target_include_directories (Hello PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
>
> * Hello/hello.h
>
> void hello();
>
> * Hello/hello.cpp
>
> #include <stdio.h>
> void hello() { printf("hello!\n"); }
>
> * now run the commands:
>
> mkdir build
> cd build
> cmake ../
> make
>
> * You may now execute Demo/helloDemo and see hello!.
>
> Now, touch Hello/hello.cpp and make again. You will see that libHello is
> built and linked as expected, but then the helloDemo executable is also
> relinked ("Linking CXX executable helloDemo"). The latter step is
> completely redundant; even if hello.cpp is modified to print a different
> string the relinked executable remains binary identical.
>
> Is there a way to prevent these redundant build actions? This would be a
> huge time saver for us.
>


I think you might be looking for the LINK_DEPENDS_NO_SHARED
<https://cmake.org/cmake/help/latest/prop_tgt/LINK_DEPENDS_NO_SHARED.html>
target
property (or more likely its associated CMAKE_LINK_DEPENDS_NO_SHARED
<https://cmake.org/cmake/help/latest/variable/CMAKE_LINK_DEPENDS_NO_SHARED.html>
 variable).


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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190214/98bcfb2f/attachment-0001.html>

From itay.chamiel at orcam.com  Thu Feb 14 08:17:03 2019
From: itay.chamiel at orcam.com (Itay Chamiel)
Date: Thu, 14 Feb 2019 15:17:03 +0200
Subject: [CMake] Redundant linking when modifying shared libraries
In-Reply-To: <CA+dygYku2fCFHqd600SJkSKPoiw9Bxge-FBYRzNc8DPWCknAUw@mail.gmail.com>
References: <CAA1-gOm-GpyGVeYgfPjqJJwse9GG3zQWxCya_77G45ceJBkUxg@mail.gmail.com>
 <CA+dygYku2fCFHqd600SJkSKPoiw9Bxge-FBYRzNc8DPWCknAUw@mail.gmail.com>
Message-ID: <a678cf84-0107-c928-51a9-8934ade93f81@orcam.com>

An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190214/9d2b5ba7/attachment.html>

From kgt at lanl.gov  Thu Feb 14 09:13:36 2019
From: kgt at lanl.gov (Thompson, KT)
Date: Thu, 14 Feb 2019 14:13:36 +0000
Subject: [CMake] Multiple occurrences of a library on linux (ldd)
In-Reply-To: <CAGrNNLxn2iQ5bUrs+1hgQWivsnoBCi626K8YAhY1RA_AJ4506g@mail.gmail.com>
References: <CAGrNNLy2GFLJ0SVodOy8HF_OhVOQU3RdRYRdzK2DUENCdjr6+Q@mail.gmail.com>
 <CAGrNNLxn2iQ5bUrs+1hgQWivsnoBCi626K8YAhY1RA_AJ4506g@mail.gmail.com>
Message-ID: <01f98045e7584fc88d733f8e010979c8@lanl.gov>

Thiago,

I haven?t see the double entry pattern that you mention below.  However, you might want to tell CMake to embed a BUILD_RPATH in your libraries.  This should get around the issue of manually setting LD_LIBRARY_PATH.

https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH.html?highlight=rpath

-kt

From: CMake <cmake-bounces at cmake.org> On Behalf Of Thiago Crepaldi
Sent: Thursday, February 14, 2019 12:43 AM
To: cmake at cmake.org
Subject: [CMake] Multiple occurrences of a library on linux (ldd)

Hello all,

After reading CMake Cookbook I have written my first "complex" CMake build script based on the superbuild pattern. I am excited to heave a better understanding on CMake, but I definitely will learn much more from experience and your kind help.
In summary, the standalone google test application `standalone_gtests` publicly links to `libdatareader.so` and to pytorch libraries (`libc10.so`,`libcafee2.so`, `libtorch.so`).
`libdatareader.so` also publicly links to pytorch libraries (I have a theoretical question on why `standalone_gtests` had to link to pytorch libraries if `libdatareader.so` already did, but that can wait).

Compilation finishes successfully, but when I try to run `standalone_gtests`, it aborts because it cant find `libc10.so`.
After executing `ldd standalone_gtests`, the weird result was that there were two entries for `libc10.so`.
The first one maps to "not found" while the second had the correct path to the library. `libcaffe2.so`, which is also a pytorch library, has a single occurrence with full path.
If I add the (...)/pytorch_external/(...) (see ldd output below) path to LD_LIBRARY_PATH, then everything works, but I would like to avoid this, if possible.

`ldd ./subprojects/Build/datareaders_core_test/standalone_gtests
libdatareader.so => /home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib/libdatareader.so
libcaffe2.so => /home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libcaffe2.so
libc10.so => not found
libc10.so => /home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libc10.so
(...)`

Have anyone seen multiple entries for the same library on ldd before? Why is that? Is it because `standalone_gtests` links to libc10.so and to `libdatareader.so`, which in turn also links to `libc10.so`?
Both CMakeLists.txt (libdatareader and standalone_gtests) succeeds at find_package(Torch REQUIRED QUIET) commands (${TORCH_LIBRARY} returns the correct path).


I run the same build on my Mac and everything works fine, so that is confined to linux environment. I have destroyed my conda environment and performed multiple clean builds in the process and no luck :(
Hoping this was some sort of ldconfig issue, I tried `sudo ldconfig` and `sudo rm /etc/ld.so.cache`, but that doesn't fix it.

Any ideas?

best regards,
Thiago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190214/d47dabef/attachment.html>

From dev at thiagocrepaldi.com  Thu Feb 14 10:42:23 2019
From: dev at thiagocrepaldi.com (Thiago Crepaldi)
Date: Thu, 14 Feb 2019 07:42:23 -0800
Subject: [CMake] Multiple occurrences of a library on linux (ldd)
In-Reply-To: <01f98045e7584fc88d733f8e010979c8@lanl.gov>
References: <CAGrNNLy2GFLJ0SVodOy8HF_OhVOQU3RdRYRdzK2DUENCdjr6+Q@mail.gmail.com>
 <CAGrNNLxn2iQ5bUrs+1hgQWivsnoBCi626K8YAhY1RA_AJ4506g@mail.gmail.com>
 <01f98045e7584fc88d733f8e010979c8@lanl.gov>
Message-ID: <CAGrNNLxFFhG9=M-V+ySOWDeQb+GjZe63tHByw=FEn=Ea=OPQKg@mail.gmail.com>

Thanks, Thompson, I will look into BUILD_RPATH and possibly INSTALL_RPATH.

I just learned about `export LD_DEBUG=files` to debug linking issues
on linux. It provides more detail on the ldd output, as below:

18843: file=libc10.so [0];  needed by
/home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib/libdatareader.so
[0]
               (no linking information)
18843: file=libdatareader.so [0];  needed by
subprojects/Build/datareaders_core_test/standalone_gtests [0]
18843: file=libdatareader.so [0];  generating link map
                (linking information)
(...)
18843: file=libc10.so [0];  needed by
/home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libcaffe2.so
[0]
18843: file=libc10.so [0];  generating link map
               (linking information)
18843: file=libcaffe2.so [0];  needed by
subprojects/Build/datareaders_core_test/standalone_gtests [0]
18843: file=libcaffe2.so [0];  generating link map
               (linking information)

Now I can see that the missing libc10.so is needed by
`libdatareader.so`, which was linked against `standalone_gtests`.

However, RUNPATH for both `libdatareader.so` and `standalone_gtests`
seems to be correct and point to the same torch/lib folder that has
libc10.so:
libdatareader.so:
RUNPATH=/home/dev/miniconda3/datareaders_py37/build/stage/boost/lib:/home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib:
standalone_gtests:
RUNPATH=/home/dev/miniconda3/datareaders_py37/build/stage/boost/lib:/home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib:/home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib

So, libdatareader.so links to libcaffe2.so which links to libc10.so
successfully; standalone_gtests links to libcaffe2.so which links to
libc10.so successully too; however, when standalone_gtests links to
libdatareader.so, there is a transitive linking issue with
libdatareader.so dependency on libc10.so, like the diagram below:

libdatareader.so ---> libcaffe2.so ---> libc10.so (ok)

standalone_gtests 0 ---> libcaffe2.so ---> libc10.so (ok)
              |
              -------------------> libdatareader.so ---> libc10.so (not found)


Thanks again,
Thiago



On Thu, Feb 14, 2019 at 6:13 AM Thompson, KT <kgt at lanl.gov> wrote:
>
> Thiago,
>
>
>
> I haven?t see the double entry pattern that you mention below.  However, you might want to tell CMake to embed a BUILD_RPATH in your libraries.  This should get around the issue of manually setting LD_LIBRARY_PATH.
>
>
>
> https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH.html?highlight=rpath
>
>
>
> -kt
>
>
>
> From: CMake <cmake-bounces at cmake.org> On Behalf Of Thiago Crepaldi
> Sent: Thursday, February 14, 2019 12:43 AM
> To: cmake at cmake.org
> Subject: [CMake] Multiple occurrences of a library on linux (ldd)
>
>
>
> Hello all,
>
>
>
> After reading CMake Cookbook I have written my first "complex" CMake build script based on the superbuild pattern. I am excited to heave a better understanding on CMake, but I definitely will learn much more from experience and your kind help.
>
> In summary, the standalone google test application `standalone_gtests` publicly links to `libdatareader.so` and to pytorch libraries (`libc10.so`,`libcafee2.so`, `libtorch.so`).
>
> `libdatareader.so` also publicly links to pytorch libraries (I have a theoretical question on why `standalone_gtests` had to link to pytorch libraries if `libdatareader.so` already did, but that can wait).
>
>
>
> Compilation finishes successfully, but when I try to run `standalone_gtests`, it aborts because it cant find `libc10.so`.
>
> After executing `ldd standalone_gtests`, the weird result was that there were two entries for `libc10.so`.
>
> The first one maps to "not found" while the second had the correct path to the library. `libcaffe2.so`, which is also a pytorch library, has a single occurrence with full path.
>
> If I add the (...)/pytorch_external/(...) (see ldd output below) path to LD_LIBRARY_PATH, then everything works, but I would like to avoid this, if possible.
>
>
>
> `ldd ./subprojects/Build/datareaders_core_test/standalone_gtests
>
> libdatareader.so => /home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib/libdatareader.so
>
> libcaffe2.so => /home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libcaffe2.so
>
> libc10.so => not found
>
> libc10.so => /home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libc10.so
>
> (...)`
>
>
>
> Have anyone seen multiple entries for the same library on ldd before? Why is that? Is it because `standalone_gtests` links to libc10.so and to `libdatareader.so`, which in turn also links to `libc10.so`?
>
> Both CMakeLists.txt (libdatareader and standalone_gtests) succeeds at find_package(Torch REQUIRED QUIET) commands (${TORCH_LIBRARY} returns the correct path).
>
>
>
>
>
> I run the same build on my Mac and everything works fine, so that is confined to linux environment. I have destroyed my conda environment and performed multiple clean builds in the process and no luck :(
>
> Hoping this was some sort of ldconfig issue, I tried `sudo ldconfig` and `sudo rm /etc/ld.so.cache`, but that doesn't fix it.
>
>
>
> Any ideas?
>
>
>
> best regards,
>
> Thiago



-- 
Thiago

From itay.chamiel at orcam.com  Thu Feb 14 12:11:13 2019
From: itay.chamiel at orcam.com (Itay Chamiel)
Date: Thu, 14 Feb 2019 19:11:13 +0200
Subject: [CMake] Redundant linking when modifying shared libraries
In-Reply-To: <CA+dygYku2fCFHqd600SJkSKPoiw9Bxge-FBYRzNc8DPWCknAUw@mail.gmail.com>
References: <CAA1-gOm-GpyGVeYgfPjqJJwse9GG3zQWxCya_77G45ceJBkUxg@mail.gmail.com>
 <CA+dygYku2fCFHqd600SJkSKPoiw9Bxge-FBYRzNc8DPWCknAUw@mail.gmail.com>
Message-ID: <CAA1-gOnH3v-=jUV04EJOTT1zZacxxf329z_k5U=CapHF+uo7Mg@mail.gmail.com>

On Thu, Feb 14, 2019 at 12:39 PM Craig Scott <craig.scott at crascit.com> wrote:
> I think you might be looking for the LINK_DEPENDS_NO_SHARED target property (or more likely its associated CMAKE_LINK_DEPENDS_NO_SHARED variable).

After my previous response I experimented a little more, and I got it
to work. My mistake was that I needed to add the configuration line to
the executable target, not the lib. So in my example, add the
following line to the Demo/CMakeLists.txt file:

set_target_properties(helloDemo PROPERTIES LINK_DEPENDS_NO_SHARED true)

..and it works like a charm. I wonder why this isn't the default
behavior; can you think of any scenario where this would produce
invalid results?

Thanks for your help!

itay

From tjwrona1992 at gmail.com  Thu Feb 14 12:21:43 2019
From: tjwrona1992 at gmail.com (Timothy Wrona)
Date: Thu, 14 Feb 2019 12:21:43 -0500
Subject: [CMake] Is there a way to delay "find_package" until link-time when
 the package is actually needed?
Message-ID: <CAGrOMv0X_9-2sYFe-=hAbjYLSj3+93NQY7j1FjFg97_KYDhuCQ@mail.gmail.com>

I have a collection of interdependent CMake projects (lots of legacy code)
that I want to convert to using CMake targets for linking. The code is
built in such a way that all projects run cmake generation, then all
projects build, then all projects link.

I would like to export a CMake target from one of the projects and link to
it in another, but the issue is the project I am exporting from runs its
cmake generation AFTER the project I am linking the target in. This causes
"find_package" to fail because the target has not been exported yet, but
realistically the exported target is not needed until link-time.

Is there a way to delay "find_package" to not look for the package until
link-time? At link-time the package will have been exported already and if
"find_package" was not called until then, it would be found successfully
and the target could be pulled in and linked to.

Thanks,
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190214/a361b7c6/attachment.html>

From eric.noulard at gmail.com  Thu Feb 14 12:38:12 2019
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 14 Feb 2019 18:38:12 +0100
Subject: [CMake] Is there a way to delay "find_package" until link-time
 when the package is actually needed?
In-Reply-To: <CAGrOMv0X_9-2sYFe-=hAbjYLSj3+93NQY7j1FjFg97_KYDhuCQ@mail.gmail.com>
References: <CAGrOMv0X_9-2sYFe-=hAbjYLSj3+93NQY7j1FjFg97_KYDhuCQ@mail.gmail.com>
Message-ID: <CAPASGLpmKPUh0gLPnJOe32wqNzoCQr8p9HuJJR3w_vrVqd8mnw@mail.gmail.com>

Le jeu. 14 f?vr. 2019 ? 18:22, Timothy Wrona <tjwrona1992 at gmail.com> a
?crit :

> I have a collection of interdependent CMake projects (lots of legacy code)
> that I want to convert to using CMake targets for linking. The code is
> built in such a way that all projects run cmake generation, then all
> projects build, then all projects link.
>
> I would like to export a CMake target from one of the projects and link to
> it in another, but the issue is the project I am exporting from runs its
> cmake generation AFTER the project I am linking the target in. This causes
> "find_package" to fail because the target has not been exported yet, but
> realistically the exported target is not needed until link-time.
>

This heavily depends on the target. Modern CMake target convey compile time
information as well like compile flags, include directory etc...

Can't you re-order the cmake generation order of your projects?
If you [ever] have the graph dependency of your projects you may
topologically sort them in order to avoid this issue and superbuild them in
appropriate order.


> Is there a way to delay "find_package" to not look for the package until
> link-time?
>

I don't think so.


> At link-time the package will have been exported already and if
> "find_package" was not called until then, it would be found successfully
> and the target could be pulled in and linked to.
>

But the build compile line options used to generate build system files are
computed during CMake configuration/generation step.
So I don't think what you ask is possible.

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190214/59614f20/attachment.html>

From tjwrona1992 at gmail.com  Thu Feb 14 12:56:50 2019
From: tjwrona1992 at gmail.com (Timothy Wrona)
Date: Thu, 14 Feb 2019 12:56:50 -0500
Subject: [CMake] Is there a way to delay "find_package" until link-time
 when the package is actually needed?
In-Reply-To: <CAPASGLpmKPUh0gLPnJOe32wqNzoCQr8p9HuJJR3w_vrVqd8mnw@mail.gmail.com>
References: <CAGrOMv0X_9-2sYFe-=hAbjYLSj3+93NQY7j1FjFg97_KYDhuCQ@mail.gmail.com>
 <CAPASGLpmKPUh0gLPnJOe32wqNzoCQr8p9HuJJR3w_vrVqd8mnw@mail.gmail.com>
Message-ID: <CAGrOMv1Ow6pr-XUeB68A3qWjEmNp45Oi_1W7nSFfpJodt_wMRA@mail.gmail.com>

The problem is it is very likely that there are some circular dependencies
in the build tree -- which is why it was broken up to generation of all,
then build all, then link all in the first place.

With circular dependencies there's no real way to sort these dependencies
out without just running generation twice, but the first run will get a
bunch of errors for missing packages.

On Thu, Feb 14, 2019 at 12:38 PM Eric Noulard <eric.noulard at gmail.com>
wrote:

>
>
> Le jeu. 14 f?vr. 2019 ? 18:22, Timothy Wrona <tjwrona1992 at gmail.com> a
> ?crit :
>
>> I have a collection of interdependent CMake projects (lots of legacy
>> code) that I want to convert to using CMake targets for linking. The code
>> is built in such a way that all projects run cmake generation, then all
>> projects build, then all projects link.
>>
>> I would like to export a CMake target from one of the projects and link
>> to it in another, but the issue is the project I am exporting from runs its
>> cmake generation AFTER the project I am linking the target in. This causes
>> "find_package" to fail because the target has not been exported yet, but
>> realistically the exported target is not needed until link-time.
>>
>
> This heavily depends on the target. Modern CMake target convey compile
> time information as well like compile flags, include directory etc...
>
> Can't you re-order the cmake generation order of your projects?
> If you [ever] have the graph dependency of your projects you may
> topologically sort them in order to avoid this issue and superbuild them in
> appropriate order.
>
>
>> Is there a way to delay "find_package" to not look for the package until
>> link-time?
>>
>
> I don't think so.
>
>
>> At link-time the package will have been exported already and if
>> "find_package" was not called until then, it would be found successfully
>> and the target could be pulled in and linked to.
>>
>
> But the build compile line options used to generate build system files are
> computed during CMake configuration/generation step.
> So I don't think what you ask is possible.
>
> --
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190214/ec89a7ec/attachment.html>

From robert.maynard at kitware.com  Thu Feb 14 13:07:44 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 14 Feb 2019 13:07:44 -0500
Subject: [CMake] Redundant linking when modifying shared libraries
In-Reply-To: <CAA1-gOnH3v-=jUV04EJOTT1zZacxxf329z_k5U=CapHF+uo7Mg@mail.gmail.com>
References: <CAA1-gOm-GpyGVeYgfPjqJJwse9GG3zQWxCya_77G45ceJBkUxg@mail.gmail.com>
 <CA+dygYku2fCFHqd600SJkSKPoiw9Bxge-FBYRzNc8DPWCknAUw@mail.gmail.com>
 <CAA1-gOnH3v-=jUV04EJOTT1zZacxxf329z_k5U=CapHF+uo7Mg@mail.gmail.com>
Message-ID: <CAFzjYVo5bx6PE_PDRCTq7dPg=0CpuuPGKnJxJ2xaj8fGq+JxZw@mail.gmail.com>

> I wonder why this isn't the default behavior

By default CMake wants to get a correct build 100% of the time. There
is nothing to stop people from having functions defined in a .cxx file
with no corresponding header, and using manual forward deceleration is
used in a consuming library/executable. By setting
`LINK_DEPENDS_NO_SHARED` to `True` you will convert what was a link
time error ( renaming the function in the .cxx ) to a run time error.

On Thu, Feb 14, 2019 at 12:11 PM Itay Chamiel <itay.chamiel at orcam.com> wrote:
>
> On Thu, Feb 14, 2019 at 12:39 PM Craig Scott <craig.scott at crascit.com> wrote:
> > I think you might be looking for the LINK_DEPENDS_NO_SHARED target property (or more likely its associated CMAKE_LINK_DEPENDS_NO_SHARED variable).
>
> After my previous response I experimented a little more, and I got it
> to work. My mistake was that I needed to add the configuration line to
> the executable target, not the lib. So in my example, add the
> following line to the Demo/CMakeLists.txt file:
>
> set_target_properties(helloDemo PROPERTIES LINK_DEPENDS_NO_SHARED true)
>
> ..and it works like a charm. I wonder why this isn't the default
> behavior; can you think of any scenario where this would produce
> invalid results?
>
> Thanks for your help!
>
> itay
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake

From eric.noulard at gmail.com  Thu Feb 14 13:32:43 2019
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 14 Feb 2019 19:32:43 +0100
Subject: [CMake] Is there a way to delay "find_package" until link-time
 when the package is actually needed?
In-Reply-To: <CAGrOMv1Ow6pr-XUeB68A3qWjEmNp45Oi_1W7nSFfpJodt_wMRA@mail.gmail.com>
References: <CAGrOMv0X_9-2sYFe-=hAbjYLSj3+93NQY7j1FjFg97_KYDhuCQ@mail.gmail.com>
 <CAPASGLpmKPUh0gLPnJOe32wqNzoCQr8p9HuJJR3w_vrVqd8mnw@mail.gmail.com>
 <CAGrOMv1Ow6pr-XUeB68A3qWjEmNp45Oi_1W7nSFfpJodt_wMRA@mail.gmail.com>
Message-ID: <CAPASGLqiL=Umiy=9snZCdyCqo2OBBEF5wy74crzxPZ2D0jEDZw@mail.gmail.com>

Le jeu. 14 f?vr. 2019 ? 18:57, Timothy Wrona <tjwrona1992 at gmail.com> a
?crit :

> The problem is it is very likely that there are some circular dependencies
> in the build tree -- which is why it was broken up to generation of all,
> then build all, then link all in the first place.
>

Yes, wrong solution to a real design issue :-)


>
> With circular dependencies there's no real way to sort these dependencies
> out without just running generation twice, but the first run will get a
> bunch of errors for missing packages.
>

I understand the situation, I did face that too in the past.
If there is not too much circular deps you may either break them by writing
(by hand) a bunch of imported target or you can merge in the same CMake
project the sub-projects belonging to the same cycle.
Feasibility depends on the amount of projects (and cycle) you have.




>
> On Thu, Feb 14, 2019 at 12:38 PM Eric Noulard <eric.noulard at gmail.com>
> wrote:
>
>>
>>
>> Le jeu. 14 f?vr. 2019 ? 18:22, Timothy Wrona <tjwrona1992 at gmail.com> a
>> ?crit :
>>
>>> I have a collection of interdependent CMake projects (lots of legacy
>>> code) that I want to convert to using CMake targets for linking. The code
>>> is built in such a way that all projects run cmake generation, then all
>>> projects build, then all projects link.
>>>
>>> I would like to export a CMake target from one of the projects and link
>>> to it in another, but the issue is the project I am exporting from runs its
>>> cmake generation AFTER the project I am linking the target in. This causes
>>> "find_package" to fail because the target has not been exported yet, but
>>> realistically the exported target is not needed until link-time.
>>>
>>
>> This heavily depends on the target. Modern CMake target convey compile
>> time information as well like compile flags, include directory etc...
>>
>> Can't you re-order the cmake generation order of your projects?
>> If you [ever] have the graph dependency of your projects you may
>> topologically sort them in order to avoid this issue and superbuild them in
>> appropriate order.
>>
>>
>>> Is there a way to delay "find_package" to not look for the package until
>>> link-time?
>>>
>>
>> I don't think so.
>>
>>
>>> At link-time the package will have been exported already and if
>>> "find_package" was not called until then, it would be found successfully
>>> and the target could be pulled in and linked to.
>>>
>>
>> But the build compile line options used to generate build system files
>> are computed during CMake configuration/generation step.
>> So I don't think what you ask is possible.
>>
>> --
>> Eric
>>
>

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190214/f9b57318/attachment.html>

From tjwrona1992 at gmail.com  Thu Feb 14 13:38:52 2019
From: tjwrona1992 at gmail.com (Timothy Wrona)
Date: Thu, 14 Feb 2019 13:38:52 -0500
Subject: [CMake] Is there a way to delay "find_package" until link-time
 when the package is actually needed?
In-Reply-To: <CAPASGLqiL=Umiy=9snZCdyCqo2OBBEF5wy74crzxPZ2D0jEDZw@mail.gmail.com>
References: <CAGrOMv0X_9-2sYFe-=hAbjYLSj3+93NQY7j1FjFg97_KYDhuCQ@mail.gmail.com>
 <CAPASGLpmKPUh0gLPnJOe32wqNzoCQr8p9HuJJR3w_vrVqd8mnw@mail.gmail.com>
 <CAGrOMv1Ow6pr-XUeB68A3qWjEmNp45Oi_1W7nSFfpJodt_wMRA@mail.gmail.com>
 <CAPASGLqiL=Umiy=9snZCdyCqo2OBBEF5wy74crzxPZ2D0jEDZw@mail.gmail.com>
Message-ID: <CAGrOMv3KFUN-m++jH=QbvEMYAEZVmmJFzkC-6BY4i4kHaOFkkQ@mail.gmail.com>

I guess what I would ultimately like to achieve would be a
"pre-cmake-configuration" step that just initializes the package registry
with the location of each project's build tree and copies the
"project-config.cmake" files into each projects build-tree. This would
allow it to be found during generation, but it doesn't seem like it works
that way. Maybe some sort of "superbuild" pattern would be a better option.

On Thu, Feb 14, 2019 at 1:32 PM Eric Noulard <eric.noulard at gmail.com> wrote:

>
>
> Le jeu. 14 f?vr. 2019 ? 18:57, Timothy Wrona <tjwrona1992 at gmail.com> a
> ?crit :
>
>> The problem is it is very likely that there are some circular
>> dependencies in the build tree -- which is why it was broken up to
>> generation of all, then build all, then link all in the first place.
>>
>
> Yes, wrong solution to a real design issue :-)
>
>
>>
>> With circular dependencies there's no real way to sort these dependencies
>> out without just running generation twice, but the first run will get a
>> bunch of errors for missing packages.
>>
>
> I understand the situation, I did face that too in the past.
> If there is not too much circular deps you may either break them by
> writing (by hand) a bunch of imported target or you can merge in the same
> CMake project the sub-projects belonging to the same cycle.
> Feasibility depends on the amount of projects (and cycle) you have.
>
>
>
>
>>
>> On Thu, Feb 14, 2019 at 12:38 PM Eric Noulard <eric.noulard at gmail.com>
>> wrote:
>>
>>>
>>>
>>> Le jeu. 14 f?vr. 2019 ? 18:22, Timothy Wrona <tjwrona1992 at gmail.com> a
>>> ?crit :
>>>
>>>> I have a collection of interdependent CMake projects (lots of legacy
>>>> code) that I want to convert to using CMake targets for linking. The code
>>>> is built in such a way that all projects run cmake generation, then all
>>>> projects build, then all projects link.
>>>>
>>>> I would like to export a CMake target from one of the projects and link
>>>> to it in another, but the issue is the project I am exporting from runs its
>>>> cmake generation AFTER the project I am linking the target in. This causes
>>>> "find_package" to fail because the target has not been exported yet, but
>>>> realistically the exported target is not needed until link-time.
>>>>
>>>
>>> This heavily depends on the target. Modern CMake target convey compile
>>> time information as well like compile flags, include directory etc...
>>>
>>> Can't you re-order the cmake generation order of your projects?
>>> If you [ever] have the graph dependency of your projects you may
>>> topologically sort them in order to avoid this issue and superbuild them in
>>> appropriate order.
>>>
>>>
>>>> Is there a way to delay "find_package" to not look for the package
>>>> until link-time?
>>>>
>>>
>>> I don't think so.
>>>
>>>
>>>> At link-time the package will have been exported already and if
>>>> "find_package" was not called until then, it would be found successfully
>>>> and the target could be pulled in and linked to.
>>>>
>>>
>>> But the build compile line options used to generate build system files
>>> are computed during CMake configuration/generation step.
>>> So I don't think what you ask is possible.
>>>
>>> --
>>> Eric
>>>
>>
>
> --
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190214/e3ac1995/attachment.html>

From dev at thiagocrepaldi.com  Thu Feb 14 15:03:24 2019
From: dev at thiagocrepaldi.com (Thiago Crepaldi)
Date: Thu, 14 Feb 2019 12:03:24 -0800
Subject: [CMake] Multiple occurrences of a library on linux (ldd)
In-Reply-To: <CAGrNNLxFFhG9=M-V+ySOWDeQb+GjZe63tHByw=FEn=Ea=OPQKg@mail.gmail.com>
References: <CAGrNNLy2GFLJ0SVodOy8HF_OhVOQU3RdRYRdzK2DUENCdjr6+Q@mail.gmail.com>
 <CAGrNNLxn2iQ5bUrs+1hgQWivsnoBCi626K8YAhY1RA_AJ4506g@mail.gmail.com>
 <01f98045e7584fc88d733f8e010979c8@lanl.gov>
 <CAGrNNLxFFhG9=M-V+ySOWDeQb+GjZe63tHByw=FEn=Ea=OPQKg@mail.gmail.com>
Message-ID: <CAGrNNLxxgnBkm9Vy51uR3Bw+F42kv4Wz1ohRGECAH7dsibj0tg@mail.gmail.com>

I might be getting close and the root cause might be related to a
conceptual question that I was saving for later: how transitive
linking should be done!

Returning to the build design: pytorch is compile if not installed in
the system, lib datareader_core consumes pytorch and standalone_gtests
consumes datareader_core
          (aka standalone_gtests --> lib_datareader.so --> libc10.so)

Here are the relevant snippets from all relevant cmake files:

***/CMakeLists.txt***
(...)
# pytorch will be compile here
add_subdirectory(external/upstream)

# datareader_core lib will consume torch during its build
ExternalProject_Add(${PROJECT_NAME}_core
   DEPENDS pytorch_external
   SOURCE_DIR (...)
   CMAKE_ARGS (...)
   CMAKE_CACHE_ARGS (...)
   BUILD_ALWAYS 1
)

# Consumes datareader_core, which consumes pytorch (libc10.so and libcaffe2.so)
ExternalProject_Add(${PROJECT_NAME}_core_test
   DEPENDS ${PROJECT_NAME}_core
   SOURCE_DIR (...)
   CMAKE_ARGS (...)
   CMAKE_CACHE_ARGS -DDATAREADER_CORE_ROOT:INTERNAL=${DATAREADER_CORE_ROOT}

-DDATAREADER_CORE_LIBRARYDIR:INTERNAL=${DATAREADER_CORE_LIBRARYDIR}

-DDATAREADER_CORE_INCLUDEDIR:INTERNAL=${DATAREADER_CORE_INCLUDEDIR}
   (...)
   BUILD_ALWAYS 1
)

***/external/upstream/CMakeLists.txt***
add_subdirectory(pytorch)

/external/upstream/CMakeLists.txt
find_package(Torch QUIET)
if(NOT Torch_FOUND)
   message(STATUS "Pytorch not found in the systemm. Looking in the
build environment")
   set(
      CMAKE_PREFIX_PATH "${EP_BASE}/Source/pytorch_external/torch/share/cmake"
      CACHE INTERNAL "Path to Pytorch cmake configs"
      FORCE
   )
   find_package(Torch QUIET)
endif()

if(Torch_FOUND)
   add_library(pytorch_external INTERFACE)
else()
   message(STATUS "Pytorch could not be located. Building instead")

   include(ExternalProject)
   ExternalProject_Add(pytorch_external (...)
endif()

***/datareader_src/CMakeLists.txt***
project(datareader_core)

   add_library(datareader SHARED ${DATAREADER_SRC})
   find_package(Torch REQUIRED)
   target_include_directories(datareader PUBLIC
${CMAKE_CURRENT_SOURCE_DIR}/include)
   target_link_libraries(datareader PUBLIC ${TORCH_LIBRARIES})

***/datareader_test_src/CMakeLists.txt***
project(datareader_core_test)

enable_testing()
add_executable(standalone_gtests test.cpp)
find_package(GTest REQUIRED)
find_package(Threads REQUIRED)
target_include_directories(standalone_gtests PUBLIC
${DATAREADER_CORE_INCLUDEDIR}
${GOOGLETEST_INCLUDEDIR}
${CMAKE_CURRENT_SOURCE_DIR}/../)

target_link_libraries(standalone_gtests PUBLIC
${TORCH_LIBRARIES}
${DATAREADER}
${GTEST_BOTH_LIBRARIES}
${CMAKE_THREAD_LIBS_INIT}
)

At this point, Pytorch is looked in the system by find_package(Torch),
if not found, it will be cloned and compiled. datareader_core lib
find_package(Torch) and link to it. Lastly, datareader_core_test app
will link to datareader_core lib.
If I ldd libdatareader.so, I can see libc10.so (from pytorch) is
properly linked. However, datareader_core_test compilation will fail
with an undefined reference to symbol inside libc10.so:
/usr/bin/ld: warning: libcaffe2.so, needed by
/home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib/libdatareader.so,
not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libc10.so, needed by
/home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib/libdatareader.so,
not found (try using -rpath or -rpath-link)
/home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib/libdatareader.so:
undefined reference to `c10::Error::Error(c10::SourceLocation,
std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&)'
collect2: error: ld returned 1 exit status

My understanding was that if datareader_core did
target_link_libraries(datareader PUBLIC ${TORCH_LIBRARIES}), then any
other target that depends on datareader target would be properly
linked to its public dependences libraries.
Where is my mistake? To work this around, I have added
find_package(Torch REQUIRED) and
target_link_libraries(standalone_gtests PUBLIC ${TORCH_LIBRARIES}) to
standalone_gtests, although it doesn't directly consume anything from
pytorch. That change lead to the original issue of having
standalone_gtests having two entries of libc10.so in the ldd output:
one because of the indirect lib datareader dependency (not fond) and
another due tot he direct linking (working)

Am I linking Torch incorrectly to datareader_core or maybe
ExternalProject_Add(datareader_core) hides linking information from
another target inside another
ExternalProject_Add(datareader_core_test)?
I am a bit confused by the explanation at
https://cmake.org/cmake/help/latest/command/target_link_libraries.html
and this build and your help might help solidify the private, public
and interface concepts.

Thanks again
Thiago
On Thu, Feb 14, 2019 at 7:42 AM Thiago Crepaldi <dev at thiagocrepaldi.com> wrote:
>
> Thanks, Thompson, I will look into BUILD_RPATH and possibly INSTALL_RPATH.
>
> I just learned about `export LD_DEBUG=files` to debug linking issues
> on linux. It provides more detail on the ldd output, as below:
>
> 18843: file=libc10.so [0];  needed by
> /home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib/libdatareader.so
> [0]
>                (no linking information)
> 18843: file=libdatareader.so [0];  needed by
> subprojects/Build/datareaders_core_test/standalone_gtests [0]
> 18843: file=libdatareader.so [0];  generating link map
>                 (linking information)
> (...)
> 18843: file=libc10.so [0];  needed by
> /home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libcaffe2.so
> [0]
> 18843: file=libc10.so [0];  generating link map
>                (linking information)
> 18843: file=libcaffe2.so [0];  needed by
> subprojects/Build/datareaders_core_test/standalone_gtests [0]
> 18843: file=libcaffe2.so [0];  generating link map
>                (linking information)
>
> Now I can see that the missing libc10.so is needed by
> `libdatareader.so`, which was linked against `standalone_gtests`.
>
> However, RUNPATH for both `libdatareader.so` and `standalone_gtests`
> seems to be correct and point to the same torch/lib folder that has
> libc10.so:
> libdatareader.so:
> RUNPATH=/home/dev/miniconda3/datareaders_py37/build/stage/boost/lib:/home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib:
> standalone_gtests:
> RUNPATH=/home/dev/miniconda3/datareaders_py37/build/stage/boost/lib:/home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib:/home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib
>
> So, libdatareader.so links to libcaffe2.so which links to libc10.so
> successfully; standalone_gtests links to libcaffe2.so which links to
> libc10.so successully too; however, when standalone_gtests links to
> libdatareader.so, there is a transitive linking issue with
> libdatareader.so dependency on libc10.so, like the diagram below:
>
> libdatareader.so ---> libcaffe2.so ---> libc10.so (ok)
>
> standalone_gtests 0 ---> libcaffe2.so ---> libc10.so (ok)
>               |
>               -------------------> libdatareader.so ---> libc10.so (not found)
>
>
> Thanks again,
> Thiago
>
>
>
> On Thu, Feb 14, 2019 at 6:13 AM Thompson, KT <kgt at lanl.gov> wrote:
> >
> > Thiago,
> >
> >
> >
> > I haven?t see the double entry pattern that you mention below.  However, you might want to tell CMake to embed a BUILD_RPATH in your libraries.  This should get around the issue of manually setting LD_LIBRARY_PATH.
> >
> >
> >
> > https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH.html?highlight=rpath
> >
> >
> >
> > -kt
> >
> >
> >
> > From: CMake <cmake-bounces at cmake.org> On Behalf Of Thiago Crepaldi
> > Sent: Thursday, February 14, 2019 12:43 AM
> > To: cmake at cmake.org
> > Subject: [CMake] Multiple occurrences of a library on linux (ldd)
> >
> >
> >
> > Hello all,
> >
> >
> >
> > After reading CMake Cookbook I have written my first "complex" CMake build script based on the superbuild pattern. I am excited to heave a better understanding on CMake, but I definitely will learn much more from experience and your kind help.
> >
> > In summary, the standalone google test application `standalone_gtests` publicly links to `libdatareader.so` and to pytorch libraries (`libc10.so`,`libcafee2.so`, `libtorch.so`).
> >
> > `libdatareader.so` also publicly links to pytorch libraries (I have a theoretical question on why `standalone_gtests` had to link to pytorch libraries if `libdatareader.so` already did, but that can wait).
> >
> >
> >
> > Compilation finishes successfully, but when I try to run `standalone_gtests`, it aborts because it cant find `libc10.so`.
> >
> > After executing `ldd standalone_gtests`, the weird result was that there were two entries for `libc10.so`.
> >
> > The first one maps to "not found" while the second had the correct path to the library. `libcaffe2.so`, which is also a pytorch library, has a single occurrence with full path.
> >
> > If I add the (...)/pytorch_external/(...) (see ldd output below) path to LD_LIBRARY_PATH, then everything works, but I would like to avoid this, if possible.
> >
> >
> >
> > `ldd ./subprojects/Build/datareaders_core_test/standalone_gtests
> >
> > libdatareader.so => /home/dev/miniconda3/datareaders_py37/build/stage/datareader/lib/libdatareader.so
> >
> > libcaffe2.so => /home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libcaffe2.so
> >
> > libc10.so => not found
> >
> > libc10.so => /home/dev/miniconda3/datareaders_py37/build/subprojects/Source/pytorch_external/torch/lib/libc10.so
> >
> > (...)`
> >
> >
> >
> > Have anyone seen multiple entries for the same library on ldd before? Why is that? Is it because `standalone_gtests` links to libc10.so and to `libdatareader.so`, which in turn also links to `libc10.so`?
> >
> > Both CMakeLists.txt (libdatareader and standalone_gtests) succeeds at find_package(Torch REQUIRED QUIET) commands (${TORCH_LIBRARY} returns the correct path).
> >
> >
> >
> >
> >
> > I run the same build on my Mac and everything works fine, so that is confined to linux environment. I have destroyed my conda environment and performed multiple clean builds in the process and no luck :(
> >
> > Hoping this was some sort of ldconfig issue, I tried `sudo ldconfig` and `sudo rm /etc/ld.so.cache`, but that doesn't fix it.
> >
> >
> >
> > Any ideas?
> >
> >
> >
> > best regards,
> >
> > Thiago
>
>
>
> --
> Thiago



-- 
Thiago

From itay.chamiel at orcam.com  Thu Feb 14 15:12:41 2019
From: itay.chamiel at orcam.com (Itay Chamiel)
Date: Thu, 14 Feb 2019 22:12:41 +0200
Subject: [CMake] Redundant linking when modifying shared libraries
In-Reply-To: <CAFzjYVo5bx6PE_PDRCTq7dPg=0CpuuPGKnJxJ2xaj8fGq+JxZw@mail.gmail.com>
References: <CAA1-gOm-GpyGVeYgfPjqJJwse9GG3zQWxCya_77G45ceJBkUxg@mail.gmail.com>
 <CA+dygYku2fCFHqd600SJkSKPoiw9Bxge-FBYRzNc8DPWCknAUw@mail.gmail.com>
 <CAA1-gOnH3v-=jUV04EJOTT1zZacxxf329z_k5U=CapHF+uo7Mg@mail.gmail.com>
 <CAFzjYVo5bx6PE_PDRCTq7dPg=0CpuuPGKnJxJ2xaj8fGq+JxZw@mail.gmail.com>
Message-ID: <CAA1-gOnN5ZqnpJUFP34hX1OavX4y+7XFX8KN=xpG9-oyvd+cgg@mail.gmail.com>

On Thu, Feb 14, 2019 at 8:08 PM Robert Maynard
<robert.maynard at kitware.com> wrote:
> By default CMake wants to get a correct build 100% of the time. There
> is nothing to stop people from having functions defined in a .cxx file
> with no corresponding header, and using manual forward deceleration is
> used in a consuming library/executable. By setting
> `LINK_DEPENDS_NO_SHARED` to `True` you will convert what was a link
> time error ( renaming the function in the .cxx ) to a run time error.

First of all, thanks for the answer - it's good to understand the
rationale and to know that in our use case we can safely use this
setting.

On the question of whether to set this as the default, I understand
your position and I personally disagree - but do not wish to start a
debate. However I will say that this simple change has, in a common
case, reduced my build time from 5 minutes to 15 seconds. At the very
least could you consider steps to make this setting more known and
accessible? (No one on Stack Overflow knew about it, and I think
that's saying something.) Perhaps put it in a FAQ, and/or more
prominently in the documentation.

Kind regards,

itay

From robert.maynard at kitware.com  Thu Feb 14 16:26:11 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 14 Feb 2019 16:26:11 -0500
Subject: [CMake] Redundant linking when modifying shared libraries
In-Reply-To: <CAA1-gOnN5ZqnpJUFP34hX1OavX4y+7XFX8KN=xpG9-oyvd+cgg@mail.gmail.com>
References: <CAA1-gOm-GpyGVeYgfPjqJJwse9GG3zQWxCya_77G45ceJBkUxg@mail.gmail.com>
 <CA+dygYku2fCFHqd600SJkSKPoiw9Bxge-FBYRzNc8DPWCknAUw@mail.gmail.com>
 <CAA1-gOnH3v-=jUV04EJOTT1zZacxxf329z_k5U=CapHF+uo7Mg@mail.gmail.com>
 <CAFzjYVo5bx6PE_PDRCTq7dPg=0CpuuPGKnJxJ2xaj8fGq+JxZw@mail.gmail.com>
 <CAA1-gOnN5ZqnpJUFP34hX1OavX4y+7XFX8KN=xpG9-oyvd+cgg@mail.gmail.com>
Message-ID: <CAFzjYVrdcvY7vvAtd_249Qxu4hokVJgE9b6UGd71ZRmNjGc_rA@mail.gmail.com>

I agree that we should document this property better.
I recommend looking at the CMake wiki (
https://gitlab.kitware.com/cmake/community/wikis/home ) and thinking
maybe adding a new recipe for `optimizing redundant linking`.

On Thu, Feb 14, 2019 at 3:11 PM Itay Chamiel <itay.chamiel at orcam.com> wrote:
>
> On Thu, Feb 14, 2019 at 8:08 PM Robert Maynard
> <robert.maynard at kitware.com> wrote:
> > By default CMake wants to get a correct build 100% of the time. There
> > is nothing to stop people from having functions defined in a .cxx file
> > with no corresponding header, and using manual forward deceleration is
> > used in a consuming library/executable. By setting
> > `LINK_DEPENDS_NO_SHARED` to `True` you will convert what was a link
> > time error ( renaming the function in the .cxx ) to a run time error.
>
> First of all, thanks for the answer - it's good to understand the
> rationale and to know that in our use case we can safely use this
> setting.
>
> On the question of whether to set this as the default, I understand
> your position and I personally disagree - but do not wish to start a
> debate. However I will say that this simple change has, in a common
> case, reduced my build time from 5 minutes to 15 seconds. At the very
> least could you consider steps to make this setting more known and
> accessible? (No one on Stack Overflow knew about it, and I think
> that's saying something.) Perhaps put it in a FAQ, and/or more
> prominently in the documentation.
>
> Kind regards,
>
> itay
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake

From itay.chamiel at orcam.com  Thu Feb 14 17:18:19 2019
From: itay.chamiel at orcam.com (Itay Chamiel)
Date: Fri, 15 Feb 2019 00:18:19 +0200
Subject: [CMake] Redundant linking when modifying shared libraries
In-Reply-To: <CAFzjYVrdcvY7vvAtd_249Qxu4hokVJgE9b6UGd71ZRmNjGc_rA@mail.gmail.com>
References: <CAA1-gOm-GpyGVeYgfPjqJJwse9GG3zQWxCya_77G45ceJBkUxg@mail.gmail.com>
 <CA+dygYku2fCFHqd600SJkSKPoiw9Bxge-FBYRzNc8DPWCknAUw@mail.gmail.com>
 <CAA1-gOnH3v-=jUV04EJOTT1zZacxxf329z_k5U=CapHF+uo7Mg@mail.gmail.com>
 <CAFzjYVo5bx6PE_PDRCTq7dPg=0CpuuPGKnJxJ2xaj8fGq+JxZw@mail.gmail.com>
 <CAA1-gOnN5ZqnpJUFP34hX1OavX4y+7XFX8KN=xpG9-oyvd+cgg@mail.gmail.com>
 <CAFzjYVrdcvY7vvAtd_249Qxu4hokVJgE9b6UGd71ZRmNjGc_rA@mail.gmail.com>
Message-ID: <CAA1-gOk5fsSF_gZYeBgQ8BWqD6ngoFy4=hKG8f3A=865FNz=5Q@mail.gmail.com>

Sounds good. The FAQ has a question "Is there a way to skip checking
of dependent libraries when compiling?" - perhaps you can add one just
before that, something like "Is there a way to reduce the amount of
linking when building a large project?".or similar.

Thanks again,

itay

On Thu, Feb 14, 2019 at 11:26 PM Robert Maynard
<robert.maynard at kitware.com> wrote:
>
> I agree that we should document this property better.
> I recommend looking at the CMake wiki (
> https://gitlab.kitware.com/cmake/community/wikis/home ) and thinking
> maybe adding a new recipe for `optimizing redundant linking`.
>
> On Thu, Feb 14, 2019 at 3:11 PM Itay Chamiel <itay.chamiel at orcam.com> wrote:
> >
> > On Thu, Feb 14, 2019 at 8:08 PM Robert Maynard
> > <robert.maynard at kitware.com> wrote:
> > > By default CMake wants to get a correct build 100% of the time. There
> > > is nothing to stop people from having functions defined in a .cxx file
> > > with no corresponding header, and using manual forward deceleration is
> > > used in a consuming library/executable. By setting
> > > `LINK_DEPENDS_NO_SHARED` to `True` you will convert what was a link
> > > time error ( renaming the function in the .cxx ) to a run time error.
> >
> > First of all, thanks for the answer - it's good to understand the
> > rationale and to know that in our use case we can safely use this
> > setting.
> >
> > On the question of whether to set this as the default, I understand
> > your position and I personally disagree - but do not wish to start a
> > debate. However I will say that this simple change has, in a common
> > case, reduced my build time from 5 minutes to 15 seconds. At the very
> > least could you consider steps to make this setting more known and
> > accessible? (No one on Stack Overflow knew about it, and I think
> > that's saying something.) Perhaps put it in a FAQ, and/or more
> > prominently in the documentation.
> >
> > Kind regards,
> >
> > itay
> > --
> >
> > 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:
> > https://cmake.org/mailman/listinfo/cmake



-- 
Itay Chamiel, Software Engineer
itay.chamiel at orcam.com | Office: +972-2-591-7800, ext. 7814
OrCam Technologies  www.orcam.com

From robert.maynard at kitware.com  Fri Feb 15 10:50:15 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 15 Feb 2019 10:50:15 -0500
Subject: [CMake] [ANNOUNCE] CMake 3.14.0-rc2 is ready for testing
Message-ID: <CAFzjYVqcXXgFgOPCR2aSS9a+54ZJ9JkS3WEdrBP=Pbf+J8WhYQ@mail.gmail.com>

I am proud to announce the second CMake 3.14 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.14

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.14/release/3.14.html

Some of the more significant changes in CMake 3.14 are:

* Support for running CMake on Windows XP and Windows Vista has been
  dropped. The precompiled Windows binaries provided on "cmake.org"
  now require Windows 7 or higher.

* CMake now supports Cross Compiling for iOS, tvOS, or watchOS using
  simple toolchain files.

* The "Visual Studio 16 2019" generator was added.  This is
  experimental and based on "Visual Studio 2019 Preview 2" because
  this version of VS has not been released.

  The VS 2019 generator differs from generators for earlier versions
  in that it does not provide variants that specify the target
  platform in the generator name.  Instead "CMAKE_GENERATOR_PLATFORM"
  must be used, e.g. through the "-A" command-line option.
  Furthermore, the default target platform (architecture) is now based
  on the *host* platform.  The VS host toolset selection is now based
  on the host architecture as well.

* The "Green Hills MULTI" generator has been updated to include Object
  Library support, support for target renaming and destination output
  control properties, and other improvements.

* A "CMAKE_BUILD_RPATH_USE_ORIGIN" variable and corresponding
  "BUILD_RPATH_USE_ORIGIN" target property were added to enable use of
  relative runtime paths (RPATHs). This helps achieving relocatable
  and reproducible builds that are invariant of the build directory.

* The "install(TARGETS)" command learned how to install to an
  appropriate default directory for a given target type, based on
  variables from the "GNUInstallDirs" module and built-in defaults, in
  lieu of a "DESTINATION" argument.

* The "install(FILES)" and "install(DIRECTORY)" commands learned a
  new set of parameters for installing files as a file type, setting
  the destination based on the appropriate variables from
  "GNUInstallDirs" and built-in defaults, in lieu of a "DESTINATION"
  argument.

* The "install(CODE)" and "install(SCRIPT)" commands learned to
  support generator expressions.  See policy "CMP0087".

* The "if()" command gained support for checking if cache variables
  are defined with the  "DEFINED CACHE{VAR}" syntax.

* A file-based api for clients to get semantic buildsystem
  information has been added.  See the "cmake-file-api(7)" manual.
  This is intended to replace the "cmake-server(7)" mode for IDEs.

* The "cmake(1)" Build Tool Mode ("cmake --build") gained "--
  verbose" and "-v" options to specify verbose build output. Some
  generators such as Xcode don't support this option currently.

* The "cmake(1)" "-E compare_files" command learned a new "--ignore-
  eol" option to specify that end-of-line differences (e.g. LF vs
  CRLF) should be ignored when comparing files.


CMake 3.14 Release Notes
************************

Changes made since CMake 3.13 include the following.


New Features
============


Generators
----------

* The "Visual Studio 16 2019" generator was added.  This is
  experimental and based on "Visual Studio 2019 Preview 2" because
  this version of VS has not been released.

  The VS 2019 generator differs from generators for earlier versions
  in that it does not provide variants that specify the target
  platform in the generator name.  Instead "CMAKE_GENERATOR_PLATFORM"
  must be used, e.g. through the "-A" command-line option.
  Furthermore, the default target platform (architecture) is now based
  on the *host* platform.  The VS host toolset selection is now based
  on the host architecture as well.

* The "Green Hills MULTI" generator has been updated:

  * Now supports Object Libraries.

  * Now warns on unsupported project types such as shared libraries.

  * Now generates a top-level "<PROJECT-NAME>.top.gpj" for each
    directory calling the "project()" command.  The top-level project
    file "default.gpj" is no longer created.

  * Now honors target renaming and destination output control
    properties such as "RUNTIME_OUTPUT_DIRECTORY" and "OUTPUT_NAME".
    This also fixes support for installation rules generated by
    "install()".

  * Now honors source file properties "INCLUDE_DIRECTORIES",
    "COMPILE_DEFINITIONS", and "COMPILE_OPTIONS".

  * Now supports Dynamic Download Integrity Applications which did
    not include Integrate Files via "GHS_INTEGRITY_APP" and setting a
    target link flag of "-dynamic".

  * The contents of project files now sorts sources groups and files
    by name. Set the "GHS_NO_SOURCE_GROUP_FILE" target property to
    "ON" to generate a single project file for the target instead of a
    project file for each source group.  Set the
    "CMAKE_GHS_NO_SOURCE_GROUP_FILE" variable to enable this for all
    targets.


File-Based API
--------------

* A file-based api for clients to get semantic buildsystem
  information has been added.  See the "cmake-file-api(7)" manual.
  This is intended to replace the "cmake-server(7)" mode for IDEs.


Platforms
---------

* CMake now supports Cross Compiling for iOS, tvOS, or watchOS using
  simple toolchain files.


Command-Line
------------

* The "cmake(1)" Build Tool Mode ("cmake --build") gained "--
  verbose" and "-v" options to specify verbose build output. Some
  generators such as Xcode don't support this option currently.

* The "cmake(1)" "-E compare_files" command learned a new "--ignore-
  eol" option to specify that end-of-line differences (e.g. LF vs
  CRLF) should be ignored when comparing files.

* The "cmake-gui(1)" dialog gained new "-S" and "-B" arguments to
  explicitly specify source and build directories.


Commands
--------

* The "file()" command learned a new sub-command, "CREATE_LINK",
  which can be used to create hard or symbolic links.

* The "file()" command learned a new sub-command, "READ_SYMLINK",
  which can be used to determine the path that a symlink points to.

* The "file()" command gained a "SIZE" mode to get the size of a
  file on disk.

* The "find_package()" command learned to optionally resolve
  symbolic links in the paths to package configuration files. See the
  "CMAKE_FIND_PACKAGE_RESOLVE_SYMLINKS" variable.

* The "get_filename_component()" command gained new "LAST_EXT" and
  "NAME_WLE" variants to work with the extension after the last "." in
  the name.

* The "if()" command gained support for checking if cache variables
  are defined with the  "DEFINED CACHE{VAR}" syntax.

* The "install(CODE)" and "install(SCRIPT)" commands learned to
  support generator expressions.  See policy "CMP0087".

* The "install(TARGETS)" command learned how to install to an
  appropriate default directory for a given target type, based on
  variables from the "GNUInstallDirs" module and built-in defaults, in
  lieu of a "DESTINATION" argument.

* The "install(FILES)" and "install(DIRECTORY)" commands learned a
  new set of parameters for installing files as a file type, setting
  the destination based on the appropriate variables from
  "GNUInstallDirs" and built-in defaults, in lieu of a "DESTINATION"
  argument.

* The "list()" operations "REMOVE_ITEM", "REMOVE_DUPLICATES",
  "SORT", "REVERSE", and "FILTER" all now accept a non-existent
  variable as the list since these operations on empty lists is also
  the empty list.

* The "list()" operation "REMOVE_AT" now indicates that the given
  indices are invalid for a non-existent variable or empty list.

* The "try_compile()" and "try_run()" commands gained a new
  "LINK_OPTIONS" option.


Variables
---------

* A "CMAKE_BUILD_RPATH_USE_ORIGIN" variable and corresponding
  "BUILD_RPATH_USE_ORIGIN" target property were added to enable use of
  relative runtime paths (RPATHs). This helps achieving relocatable
  and reproducible builds that are invariant of the build directory.


Properties
----------

* A "CMAKE_ROLE" global property was added to allow scripts to
  determine whether they're running in project mode, script mode,
  find-package mode, CTest, or CPack.

* The "CUDA_RESOLVE_DEVICE_SYMBOLS" target property is now supported
  on shared library, module library, and executable targets.
  Previously it was only honored on static libraries.

* The "EXCLUDE_FROM_ALL" target property was created to override the
  setting of its directory. A target will now be built as part of
  "all" if its "EXCLUDE_FROM_ALL" property is set to "OFF", even if
  its containing directory is marked as "EXCLUDE_FROM_ALL".

* "INTERFACE_POSITION_INDEPENDENT_CODE" target property gains the
  support of "generator expressions".


Modules
-------

* The family of modules to check capabilities (like
  "CheckCSourceCompiles") gain capability to manage "LINK_OPTIONS".

* A "CheckFortranSourceRuns" module was added to provide a
  "check_fortran_source_runs()" command to check if a Fortran source
  snippet compiles and runs.

* The "ExternalProject" module "ExternalProject_Add()" command
  gained "LOG_DIR" and "LOG_MERGED_STDOUTERR" options to control
  logging.

* The "ExternalProject" module "ExternalProject_Add()" command
  gained "LOG_PATCH" to optionally log the patch step.

* The "ExternalProject" module's "ExternalProject_Add" command
  learned to apply "SOURCE_SUBDIR" when "BUILD_IN_SOURCE" is also
  used. The "BUILD_COMMAND" is run in the given "SOURCE_SUBDIR" of the
  "SOURCE_DIR".

* The "FetchContent" module gained a new
  "FetchContent_MakeAvailable()" command.  It accepts a list of
  dependency names, which it then iterates over, populating and adding
  each one to the main build using the canonical pattern.  This
  significantly reduces the amount of boilerplate needed in a project.

* The "FindBISON" module's "BISON_TARGET" command now runs "bison"
  with "CMAKE_CURRENT_BINARY_DIR" as the working directory. See policy
  "CMP0088".

* The "FindCURL" module gained support for requesting protocols as
  package components.

* The "FindFontconfig" module was added to find fontconfig.

* The "FindGDAL" module now provides imported targets.

* The "FindGIF" module now provides imported targets.

* The "FindGit" module now provides an imported target for the Git
  executable.

* The "FindIce" module learned to find "slice2confluence" and
  "slice2matlab".

* The "FindLibinput" module was added to find libinput.

* The "FindLibLZMA" module now provides imported targets.

* The "FindMatlab" module gained new options "R2017b" and "R2018a"
  to specify the MEX API version to use; these options mirror the new
  options to the "mex" command in MATLAB R2018a. The option
  "MX_LIBRARY" is no longer needed.

* A "FindOctave" module was added to find GNU octave.

* The "FindPostgreSQL" module now provides imported targets.

* The "FindPython", "FindPython2", and "FindPython3" modules gained
  support for "NumPy" component.

* The "FindPython2", "FindPython3", and "FindPython" modules now
  support running in script mode by skipping the creation of imported
  targets and helper functions.

* The "FindSQLite3" module was added to find the SQLite v3.x
  library.

* The "FindX11" had the following variables renamed in order to
  match their library names rather than header names. The old
  variables are provided for compatibility:

     * "X11_Xxf86misc_INCLUDE_PATH" instead of
       "X11_xf86misc_INCLUDE_PATH"

     * "X11_Xxf86misc_LIB" instead of "X11_xf86misc_LIB"

     * "X11_Xxf86misc_FOUND" instead of "X11_xf86misc_FOUND"

     * "X11_Xxf86vm_INCLUDE_PATH" instead of
       "X11_xf86vmode_INCLUDE_PATH"

     * "X11_Xxf86vm_LIB" instead of "X11_xf86vmode_LIB"

     * "X11_Xxf86vm_FOUND" instead of "X11_xf86vmode_FOUND"

     * "X11_xkbfile_INCLUDE_PATH" instead of
       "X11_Xkbfile_INCLUDE_PATH"

     * "X11_xkbfile_LIB" instead of "X11_Xkbfile_LIB"

     * "X11_xkbfile_FOUND" instead of "X11_Xkbfile_FOUND"

     * "X11_Xtst_INCLUDE_PATH" instead of "X11_XTest_INCLUDE_PATH"

     * "X11_Xtst_LIB" instead of "X11_XTest_LIB"

     * "X11_Xtst_FOUND" instead of "X11_XTest_FOUND"

     * "X11_Xss_INCLUDE_PATH" instead of
       "X11_Xscreensaver_INCLUDE_PATH"

     * "X11_Xss_LIB" instead of "X11_Xscreensaver_LIB"

     * "X11_Xss_FOUND" instead of "X11_Xscreensaver_FOUND"

  The following variables are deprecated completely since they were
  essentially duplicates:

     * "X11_Xinput_INCLUDE_PATH" (use "X11_Xi_INCLUDE_PATH")

     * "X11_Xinput_LIB" (use "X11_Xi_LIB")

     * "X11_Xinput_FOUND" (use "X11_Xi_FOUND")

* The "FindX11" now provides "X11_Xext_INCLUDE_PATH".

* The "FindX11" now provides imported targets.

* The "UseSWIG" module learned to pass "-module <module_name>" to
  the "SWIG" compiler if the file property "SWIG_MODULE_NAME" is
  defined. See policy "CMP0086".

* The "UseSWIG" module gained an option to specify "SWIG" source
  file extensions.


Generator Expressions
---------------------

* The "$<Fortran_COMPILER_ID:...>" and
  "$<Fortran_COMPILER_VERSION:...>" "generator expressions" were
  added.

* The "$<IN_LIST:...>" generator expression now correctly handles an
  empty argument. See "CMP0085" for details.


Autogen
-------

* The "AUTOMOC_EXECUTABLE", "AUTORCC_EXECUTABLE", and
  "AUTOUIC_EXECUTABLE" target properties were added.  They all take a
  path to an executable and force automoc/autorcc/autouic to use this
  executable.

  Setting these will also prevent the configure time testing for these
  executables. This is mainly useful when you build these tools
  yourself.

* The new variables "CMAKE_GLOBAL_AUTOGEN_TARGET",
  "CMAKE_GLOBAL_AUTOGEN_TARGET_NAME", "CMAKE_GLOBAL_AUTORCC_TARGET"
  and "CMAKE_GLOBAL_AUTORCC_TARGET_NAME" control the generation of
  global "autogen" and "autorcc" targets.

* A new "CMAKE_AUTOGEN_ORIGIN_DEPENDS" variable and
  "AUTOGEN_ORIGIN_DEPENDS" target property may be set to enable or
  disable forwarding of the origin target dependencies to the
  corresponding "_autogen" target.


CTest
-----

* "ctest(1)" gained a "--show-only=json-v1" option to show the list
  of tests in a machine-readable JSON format. See the Show as JSON
  Object Model section of the manual.

* The "ctest_submit()" command learned a new "Done" part that can be
  used to inform CDash that a build is complete and that no more parts
  will be uploaded.

* CTest learned to accept the dashboard server submission URL from a
  single variable.  See the "SubmitURL" setting in "ctest(1)", the
  "CTEST_SUBMIT_URL" variable, and the "SUBMIT_URL" argument of the
  "ctest_submit()" command.


Deprecated and Removed Features
===============================

* An explicit deprecation diagnostic was added for policies
  "CMP0064" and "CMP0065" ("CMP0063" and below were already
  deprecated). The "cmake-policies(7)" manual explains that the OLD
  behaviors of all policies are deprecated and that projects should
  port to the NEW behaviors.

* The "Xcode" generator deprecated support for Xcode versions prior
  to Xcode 5.  Support for those will be dropped in a future version
  of CMake.

* The "FindQt" module is no longer used by the "find_package()"
  command as a find module.  This allows the Qt Project upstream to
  optionally provide its own "QtConfig.cmake" package configuration
  file and have applications use it via "find_package(Qt)" rather than
  "find_package(Qt CONFIG)".  See policy "CMP0084".

* Support for running CMake on Windows XP and Windows Vista has been
  dropped. The precompiled Windows binaries provided on "cmake.org"
  now require Windows 7 or higher.

* CTest no longer supports submissions via "ftp", "scp", "cp", and
  "xmlrpc".  CDash is the only maintained testing dashboard for CTest,
  and it only supports submissions over "http" and "https".


Other Changes
=============

* Object library linking has been fixed to propagate private link
  libraries of object libraries to consuming targets.

* Install rules under "add_subdirectory()" now interleave with those
  in the calling directory. See policy "CMP0082" for details.

* CMake now imposes a maximum recursion limit to prevent a stack
  overflow on scripts that recurse infinitely. The limit can be
  adjusted at runtime with "CMAKE_MAXIMUM_RECURSION_DEPTH".

* When using cppcheck via the "CMAKE_<LANG>_CPPCHECK" variable or
  "<LANG>_CPPCHECK" property, the build will now fail if "cppcheck"
  returns non-zero as configured by its command-line options.

* Required link options to manage Position Independent Executable
  are now added when "POSITION_INDEPENDENT_CODE" is set.  The project
  is responsible for using the "CheckPIESupported" module to check for
  "PIE" support to ensure that the "POSITION_INDEPENDENT_CODE" target
  property will be honored at link time for executables.  This
  behavior is controlled by policy "CMP0083".

* Visual Studio Generators for VS 2010 and above learned to support
  the "VS_DEBUGGER_*" properties on targets created via
  "add_custom_target()".

* The "CPack" module no longer defaults to the "paxr" value in the
  "CPACK_DEBIAN_ARCHIVE_TYPE" variable, because "dpkg" has never
  supported the PAX tar format. The "paxr" value will be mapped to
  "gnutar" and a deprecation message emitted.

----------------------------------------------------------------------------
Changes made since CMake 3.14.0-rc1:

Brad King (12):
  Help: Clarify 3.14 release note about object library dependencies
  Fix EXCLUDE_FROM_ALL on directory with an interface library
  macOS: Fix addition of <sdk>/usr/include to default implicit include dirs
  Fix regression in -I/usr/include exclusion logic
  cmAlgorithms: Add cmHasPrefix to match existing cmHasSuffix
  Update logic for sysroot in detected implicit include directories
  VS: Fix validation of Windows 8.1 SDK
  Fortran: Factor out .mod and .smod file name construction
  Fortran: Thread compiler id through to internal Fortran parser
  Fortran: Fix submodule file names across compilers
  try_compile: Restore expansion of ;-list in COMPILE_DEFINITIONS
  CMake 3.14.0-rc2

Fred Baksik (2):
  GHS: Document usage of GHS_NO_SOURCE_GROUP_FILE
  Help: Update 3.14 release notes for GHS changes

Juuso "Linda" Lapinlampi (1):
  Help: Fix elseif/endif typo

Marc Chevrier (1):
  genex: Fix erroneous handling of recursion for $<GENEX_EVAL:>

Peter Stroia-Williams (1):
  FindOctave: Add target for octinterp

Saleem Abdulrasool (1):
  FindLibXml2: Document LibXml2_FOUND as preferred case

Sebastian Nagel (1):
  FindMatlab: Tolerate empty version log file

Tushar Maheshwari (1):
  Help: Add notes for `file(CREATE_LINK)` subcommand

Zsolt Parragi (1):
  cmListFileLexer: Add missing include to avoid possible pointer truncation

From robert.maynard at kitware.com  Fri Feb 15 15:45:52 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 15 Feb 2019 15:45:52 -0500
Subject: [CMake] [SPAM] Re:  [SPAM] Re: resource installation
In-Reply-To: <C2FE794E-6AD3-4A11-9A43-2AC55F701AC0@datalogics.com>
References: <FCE08CDB-2FEB-466B-BA76-41AA4AD675D1@datalogics.com>
 <763DC666-977D-4873-A4DC-7FD6DE12CE7E@datalogics.com>
 <CAFzjYVp5AghsbhMepScWuxAf5VWLkVmWQvvmKBZKTsG+-0s5Aw@mail.gmail.com>
 <2EF478FE-33E5-4606-94DE-638619A989D3@datalogics.com>
 <C2FE794E-6AD3-4A11-9A43-2AC55F701AC0@datalogics.com>
Message-ID: <CAFzjYVr0aqphJT6HKs91zn1XhpvBmUNE3+F9z-dLbkVsmfihDw@mail.gmail.com>

I believe the problem is related to execute_process CODE not being
quoted. So the following works for me:

install(CODE
"
execute_process(COMMAND
${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM}
${CMAKE_BUILD_TYPE}
                RESULT_VARIABLE RI_RESULT
                OUTPUT_VARIABLE RI_OUTPUT
                ERROR_VARIABLE RI_ERROR
                OUTPUT_FILE ResInst.out
                ERROR_FILE ResInst.err
                )
"
)

The other option you have is using CMake's 3.X new bracket strings (
https://cmake.org/cmake/help/v3.4/manual/cmake-language.7.html#bracket-argument
) which stop
any CMake configure expansion. This makes it significantly easier to
pass down code strings, but you do have to remember to have a preamble
that sends down any
variables expanded that you need. So your example would look like this:


#First send down the variables you need expanded at CMake configure time
install(CODE
"
set(CMAKE_CURRENT_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
set(WIN_PLATFORM ${WIN_PLATFORM})
set(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE})
"
)

#now send down the unexpanded commands to run
install(CODE [==[message("running
${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM}
${CMAKE_BUILD_TYPE}")]==])
install(CODE
[==[
execute_process(COMMAND
${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM}
${CMAKE_BUILD_TYPE}
                RESULT_VARIABLE RI_RESULT
                OUTPUT_VARIABLE RI_OUTPUT
                ERROR_VARIABLE RI_ERROR
                OUTPUT_FILE ResInst.out
                ERROR_FILE ResInst.err
                )
]==]
)

On Tue, Feb 12, 2019 at 2:12 PM Rob Boehne <robb at datalogics.com> wrote:
>
> The same behavior is also present in version 3.14.0-rc1.
>
> ?On 2/12/19, 11:54 AM, "CMake on behalf of Rob Boehne" <cmake-bounces at cmake.org on behalf of robb at datalogics.com> wrote:
>
>     Hmmm, I think I've found a bug.  Here is what I have in my top-level CMakeLists.txt file:
>
>
>     if(WIN32)
>         #
>         # run the script to install the resources
>         #
>         set(RI_RESULT " ")
>         set(RI_OUTPUT " ")
>         set(RI_ERROR " ")
>
>         install(CODE "message(\"running ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")")
>
>         install(CODE execute_process(COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}
>                                      RESULT_VARIABLE RI_RESULT
>                                      OUTPUT_VARIABLE RI_OUTPUT
>                                      ERROR_VARIABLE RI_ERROR
>                                      OUTPUT_FILE ResInst.out
>                                      ERROR_FILE ResInst.err )
>                )
>
>         install(CODE "message(\"ResourceInstall results \\\"${RI_RESULT}\\\" output: \\\"${RI_OUTPUT}\\\"  error: \\\"${RI_ERROR}\\\" \")")
>
>     endif()
>
>
>     (As you can see I haven't figured out quoting yet)
>     This is what comes out of the above code:
>
>
>     if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
>       message("running C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release")
>     endif()
>
>     if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
>       execute_process(COMMAND "C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release"
>             WORKING_DIRECTORY C:/Users/robb/Development/apdfl-sandbox/pdfl15_all
>             RESULT_VARIABLE RI_RESULT
>             OUTPUT_VARIABLE RI_OUTPUT
>             ERROR_VARIABLE RI_ERROR
>             OUTPUT_FILE ResInst.out
>             ERROR_FILE ResInst.err ")
>     endif()
>
>     if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
>       message("ResourceInstall results  output:   error:  ")
>     endif()
>
>
>     From cmake 3.12.2 on Win64.  The issue is the closing quote inside "execute_process"  which appears to have been magically added by cmake.
>     When I run the cmake_install.cmake as is it fails on that line:
>
>
>     CMake Error at cmake_install.cmake:87:
>       Parse error.  Function missing ending ")".  Instead found unterminated
>       string with text ")
>
>       ".
>
>     If I remove that stray double quote, it runs, doing all the subdir install tasks, but still doesn't run the ResourceInstall.bat file.
>     And it generates the error:
>
>     1>  -- Installing: C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/cmake_vs2013/../dist/x64/release/Resources/Sample_Input/XPStoPDF.xps
>     1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: The command "setlocal
>     1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: "C:\Program Files\CMake\bin\cmake.exe" -DBUILD_TYPE=RelWithDebInfo -P cmake_install.cmake
>     1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd
>     1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :cmEnd
>     1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
>     1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :cmErrorLevel
>     1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: exit /b %1
>     1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :cmDone
>     1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd
>     1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(132,5): error MSB3073: :VCEnd" exited with code -1.
>     1>Done executing task "Exec" -- FAILED.
>     1>Done building target "PostBuildEvent" in project "INSTALL.vcxproj" -- FAILED.
>     1>
>     1>Build FAILED.
>     1>
>     1>Time Elapsed 00:00:29.40
>     ========== Build: 0 succeeded, 1 failed, 31 up-to-date, 0 skipped ==========
>
>
>     I know the batch file does not get run because I have statements at the top that create a file before anything else, and it also sends output to stdout.
>
>     Any advice on how I can move forward here?
>
>     Thanks,
>
>     Rob Boehne
>
>
>
>     On 2/5/19, 4:09 PM, "Robert Maynard" <robert.maynard at kitware.com> wrote:
>
>         If you add 'OUTPUT_VARIABLE' and 'ERROR_VARIABLE' information to the
>         execute_process call you should be able to dump the information using
>         'message' and see if the execute_process is running.
>
>
>         On Tue, Jan 29, 2019 at 3:04 PM Rob Boehne <robb at datalogics.com> wrote:
>         >
>         > I?m still not getting this script executed.  I can copy the ?message? output and run it ? and it does what I want, and I see it in cmake_install.cmake ? the message() and execute_process() calls are inside of identical conditionals, but there?s no indication that it is executing, or that there was any sort of problem.
>         >
>         > How do I get it to actually execute?
>         >
>         >
>         >
>         > In cmake_install.cmake:
>         >
>         >
>         >
>         > if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
>         >
>         >   message("running C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release")
>         >
>         > endif()
>         >
>         >
>         >
>         > if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xUnspecifiedx" OR NOT CMAKE_INSTALL_COMPONENT)
>         >
>         >   execute_process(COMMAND "C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release")
>         >
>         > endif()
>         >
>         >
>         >
>         >
>         >
>         > From: CMake <cmake-bounces at cmake.org> on behalf of Rob Boehne <robb at datalogics.com>
>         > Date: Thursday, January 24, 2019 at 9:49 AM
>         > To: "cmake at cmake.org" <cmake at cmake.org>
>         > Subject: [SPAM] Re: [CMake] resource installation
>         >
>         >
>         >
>         > Maybe because I misspelled it?  Yes.  Because I misspelled the script name.
>         >
>         >
>         >
>         > From: CMake <cmake-bounces at cmake.org> on behalf of Rob Boehne <robb at datalogics.com>
>         > Date: Thursday, January 24, 2019 at 9:40 AM
>         > To: "cmake at cmake.org" <cmake at cmake.org>
>         > Subject: [SPAM] [CMake] resource installation
>         >
>         >
>         >
>         > All,
>         >
>         >
>         >
>         > I?m attempting to install resource files (Fonts, etc.) into my product.  To that end, I have added this chunk of code to run a batch file that will copy resources into the tree:
>         >
>         >
>         >
>         > if(WIN32)
>         >
>         >     #
>         >
>         >     # run the script to install the resources
>         >
>         >     #
>         >
>         >     install(CODE "message(\"running ${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")")
>         >
>         >     install(CODE "execute_process(COMMAND \"${CMAKE_CURRENT_SOURCE_DIR}/ResourceInstall.bat ${WIN_PLATFORM} ${CMAKE_BUILD_TYPE}\")")
>         >
>         > endif()
>         >
>         >
>         >
>         > I see the output of the first line when I run the INSTALL target in VS 2013, but it seems as though the script isn?t run.
>         >
>         > 1>  -- Install configuration: "RelWithDebInfo"
>         >
>         > 1>  running C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/ResourceInstall.bat x64 Release
>         >
>         > 1>  -- Installing: C:/Users/robb/Development/apdfl-sandbox/pdfl15_all/cmake_build/../dist/x64/release/CPlusPlus/Binaries/DL150BIBUtils.lib
>         >
>         >
>         >
>         > So the message is there, but the script isn?t run.
>         >
>         >
>         >
>         > I?m I missing a dependency, or formatting the string incorrectly?  How do I debug this?
>         >
>         >
>         >
>         > Thanks,
>         >
>         >
>         >
>         > Rob
>         >
>         >
>         >
>         >
>         >
>         > Rob Boehne
>         >
>         > Senior Software Architect | Datalogics, Inc.
>         >
>         > +1.312.853.8351 | robb at datalogics.com
>         >
>         > datalogics.com | blogs.datalogics.com
>         >
>         > Connect with us: Facebook | Twitter | LinkedIn | YouTube
>         >
>         >
>         >
>         >
>         >
>         > --
>         >
>         > 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:
>         > https://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:
>     https://cmake.org/mailman/listinfo/cmake
>
>

From kuba at mareimbrium.org  Fri Feb 15 23:30:32 2019
From: kuba at mareimbrium.org (Kuba Ober)
Date: Fri, 15 Feb 2019 23:30:32 -0500
Subject: [CMake] Generator expressions and rule variables
Message-ID: <CAG4N6cqcYTJsiQeuJVER4L+36NhO=D6wUwR-tm1xraFHJcegHw@mail.gmail.com>

Hi, I'm trying to integrate cmake with a set of build tools whose command
lines look nothing like standard gnu tools.

Unfortunately, both the generator expressions and the rule variables seem
very limited: I have to do some custom massaging of the arguments that get
passed to the compiler/linker. I've resorted to using cmake in script mode
as a proxy to the compiler and linker, passing all the rule variables
verbatim, and then having the script call the compiler or linker.

This suffers from problems with escaping of spaces, at the very least. It
seems like those compilation commands would need nested lists (a
hypothetical construct thus far): the outer list would be the list of
commands - as it is now, the inner list would be the list of arguments, and
they'd be properly escaped etc. Some of it could be solved if
COMMAND_EXPAND_LISTS could be somehow applied to normal targets, and thus
to the underlying CMAKE_<LANG>_COMPILE_OBJECT, etc.

Simplifying, thus far I set CMAKE_C_COMPILE_OBJECT to ${CMAKE_COMMAND}
-DV1=<rulevar1> ... -DVn=<rulevarn> -P
${CMAKE_CURRENT_LIST_DIR}/helper.cmake. The helper does the rest. It's
brittle because of poor escaping support. I could also use
C_COMPILER_LAUNCHER with same effect but it couldn't be a cmake script,
since cmake doesn't understand "cmake -D... -P script.cmake -- arbitrary
arguments" (it could without any trouble - it's a small patch; would it be
something worthwhile to add?).

The problem is that I don't really need the overhead of invoking cmake or
another script/process for every compiled/linked output. For both make and
ninja generators, all I'd need is to generate a custom target command that
bypasses the result of the built-in generator. But I also want my
CMakeLists to look familiar and be compatible with additional generators,
thus having a custom "add_my_executable" function wouldn't work, and
overriding "add_executable" to modify some targets, and pass others
directly to "add_executable_" (the undocumented handle to the overridden
function) seems like a big hack.

So, what I'd want to do is to have a function that can be invoked for every
target, before the target is passed to the generator, and that could
inspect the target and modify its properties and override variables in its
scope. In my case, I'd write this function so that each target would get
its own "CMAKE_C_COMPILE_OBJECT" or "CMAKE_C_LINK_EXECUTABLE", fully
expanded, without any generator expressions nor rule variables.

Does cmake already offer any hook like it? A cursory examination of the
source code doesn't seem to indicate so (btw: the code is clear and easy to
follow, so I don't have high hopes...). And if not, would it be a
worthwhile addition? It'd obviate the need for both generator expressions
and rule variables - personally I think that they are half-baked hacks,
with rule variables being even more limited and really only meshing with
gnu-like tools. I imagine that to speed things up, a pre-filter could be
applied - say that "my_function" should be invoked for all executable
targets, for C language and foocc compiler:
"CMAKE_ADD_FILTER(add_executable, my_function, LANGUAGE=c
COMPILER_ID=foocc)". For every invocation of `add_executable`, CMAKE would
check if the filters match, and if so it'd invoke the function, which then
could modify target properties and variables visible to the generator (i.e.
it could regenerate CMAKE_C_COMPILE_OBJECT).

Another approach could be to have said function act like COMPILER_LAUNCHER,
and we'd then have something like:
"CMAKE_ADD_COMPILER_LAUNCHER(my_function, LANGUAGE=c, COMPILER_ID=foocc,
TYPE=executable)"

Cheers, Kuba Ober
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190215/9962bace/attachment.html>

From zx65501 at 163.com  Sat Feb 16 00:24:24 2019
From: zx65501 at 163.com (=?GBK?B?sKGwobCh?=)
Date: Sat, 16 Feb 2019 13:24:24 +0800 (CST)
Subject: [CMake] Feedback CMAKE bug in VS2017 WDK for Windows 10,
 version 1809
Message-ID: <3c99c288.37ff.168f4c3456c.Coremail.zx65501@163.com>

If VS2017 WDK for Windows 10, version 1809 is installed, CMAKE will report an error and display an error. The C CXX compiler identification is unknown. After investigation, it is because WDK.VISX in WDK caused this problem. Uninstalling this extension cmake returns to normal, but wdk will not work. I hope to check the cause of the C CXX compiler identification is unknown and fix it. Let cmake work with WDK at the same time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190216/139ce9e2/attachment.html>

From zx65501 at 163.com  Sat Feb 16 00:25:27 2019
From: zx65501 at 163.com (=?GBK?B?sKGwobCh?=)
Date: Sat, 16 Feb 2019 13:25:27 +0800 (CST)
Subject: [CMake] Feedback CMAKE bug in VS2017 WDK for Windows 10,
 version 1809
Message-ID: <1c36cc9e.381e.168f4c439fb.Coremail.zx65501@163.com>

If VS2017 WDK for Windows 10, version 1809 is installed, CMAKE will report an error and display an error. The C CXX compiler identification is unknown. After investigation, it is because WDK.VISX in WDK caused this problem. Uninstalling this extension cmake returns to normal, but wdk will not work. I hope to check the cause of the C CXX compiler identification is unknown and fix it. Let cmake work with WDK at the same time.




 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190216/a78c0193/attachment-0001.html>

From zx65501 at 163.com  Sat Feb 16 00:29:35 2019
From: zx65501 at 163.com (=?GBK?B?sKGwobCh?=)
Date: Sat, 16 Feb 2019 13:29:35 +0800 (CST)
Subject: [CMake] Feedback CMAKE bug in VS2017 WDK for Windows 10,
 version 1809
Message-ID: <754aa1be.38b4.168f4c80286.Coremail.zx65501@163.com>

If VS2017 WDK for Windows 10, version 1809 is installed, CMAKE will report an error and display an error. The C CXX compiler identification is unknown. After investigation, it is because WDK.VISX in WDK caused this problem. Uninstalling this extension cmake returns to normal, but wdk will not work. I hope to check the cause of the C CXX compiler identification is unknown and fix it. Let cmake work with WDK at the same time.


working environment
VS2017 15.97
WDK for Windows 10, version 1809
WIN10 PRO


Uninstalling the VS extension of the WDK, CMAKE can work normally, as long as the VS extension of the WDK is installed, cmake reports that the C CXX compiler is unknown.






 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190216/915ed78e/attachment.html>

From craig.scott at crascit.com  Sat Feb 16 00:51:10 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Sat, 16 Feb 2019 16:51:10 +1100
Subject: [CMake] Feedback CMAKE bug in VS2017 WDK for Windows 10,
 version 1809
In-Reply-To: <754aa1be.38b4.168f4c80286.Coremail.zx65501@163.com>
References: <754aa1be.38b4.168f4c80286.Coremail.zx65501@163.com>
Message-ID: <CA+dygYnLbQ_4pcpGFyk45qcbB=hPmGi6BU_GR6at_Y1pOwcJPA@mail.gmail.com>

On Sat, Feb 16, 2019 at 4:44 PM ??? <zx65501 at 163.com> wrote:

> If VS2017 WDK for Windows 10, version 1809 is installed, CMAKE will report
> an error and display an error. The C CXX compiler identification is
> unknown. After investigation, it is because WDK.VISX in WDK caused this
> problem. Uninstalling this extension cmake returns to normal, but wdk will
> not work. I hope to check the cause of the C CXX compiler identification is
> unknown and fix it. Let cmake work with WDK at the same time.
>
> working environment
> VS2017 15.97
> WDK for Windows 10, version 1809
> WIN10 PRO
>
> Uninstalling the VS extension of the WDK, CMAKE can work normally, as long
> as the VS extension of the WDK is installed, cmake reports that the C CXX
> compiler is unknown.
>

This seems very similar to an issue recently reported here:

https://gitlab.kitware.com/cmake/cmake/issues/18920


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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190216/a4d2f1a9/attachment.html>

From Andreas-Naumann at gmx.net  Sat Feb 16 03:58:52 2019
From: Andreas-Naumann at gmx.net (Andreas Naumann)
Date: Sat, 16 Feb 2019 09:58:52 +0100
Subject: [CMake] fixup-bundle usability
Message-ID: <3dd4050a-dd47-0e7c-b3cd-e6bffded0b66@gmx.net>

Dear CMakers,

recently I tried to bundle an application in Windows. From the 
documentation [1] I see that I should provide the directories to the 
non-system libraries.

But these information should be already in the properties of the 
targets, arent they? Is there any extension in cmake, that provides 
these paths?

How do other users handle dependencies to external dlls?


[1] https://cmake.org/cmake/help/v3.0/module/BundleUtilities.html

Regards,
Andreas


From felix.crazzolara at gmail.com  Sat Feb 16 09:47:45 2019
From: felix.crazzolara at gmail.com (Felix Crazzolara)
Date: Sat, 16 Feb 2019 15:47:45 +0100
Subject: [CMake] Remove folders created by install
Message-ID: <1bcb702d-9d2f-5549-2569-bc3de84600cd@gmail.com>

Hi everyone

For my smaller projects I'd like to have 'uninstall' functionality. To 
remove installed files I can call:

xargs rm < build/install_manifest.txt

Unfortunately this won't delete any folders generated by the 
installation. Is there a different file that keeps track of the created 
directories, or what is the recommended way to implement such functionality?

Example:
Suppose that I install <project-name>_some_header.hpp in 
<prefix>/include/<project-name>/ using the command install(TARGETS 
<project-name> EXPORT <project-name>-targets ARCHIVE DESTINATION lib 
PUBLIC_HEADER DESTINATION include/<project-name>) then I want not only 
to remove 
<prefix>/include/<project-name>/<project-name>_some_header.hpp, but also 
the directory <prefix>/include/<project-name>/.

Cheers,

Felix Crazzolara


From paul at mad-scientist.net  Sat Feb 16 14:20:48 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Sat, 16 Feb 2019 14:20:48 -0500
Subject: [CMake] Static libraries depending on libraries: only on
 headers/options/defines
Message-ID: <9c0fbcbf5a9b4583f12ff2acb78b031bfb036e52.camel@mad-scientist.net>

Hi all;

I'm working on modernizing our large complex CMake environment.  It
builds a number of different binaries from an even larger number of
static libraries, and these libraries depend on each other as well, in
that they need to include headers and, sometimes, -D options etc.

I've used straightforward target_link_libraries() to declare the
relationship between these libraries; for example:

  add_library(foo STATIC ...)
  target_include_directories(foo PUBLIC ...)
  target_compile_definitions(foo PUBLIC ...)
  target_compile_options(foo PUBLIC ...)

  add_library(bar STATIC ...)
  target_link_libraries(bar PUBLIC foo)

  add_executable(one ...)
  target_link_libraries(one PRIVATE bar)

This works, in that everything builds properly but it has a side-effect 
we want to avoid.  Because the source tree is large many developers
have a habit of testing compilation of subsets of the code using
something like:

  make -jX bar

and expect it to just build the static library bar.  Because it's a
static library you don't need to actually build "foo" until link time. 
But we do need all the include directories, compile definitions, and
compile options to be inherited from "foo" into "bar".

However with the above formulation, building "bar" also forces the
compilation of "foo", which we don't need or want.

I've played around with the different values of PUBLIC, PRIVATE, and
INTERFACE but there doesn't seem to be a straightforward way to say,
"take the interface values for includes, definitions, and options, but
don't depend on the generated target".

I can write a function to do this myself but this seems like the most
common way someone would want to treat static libraries referencing
other static libraries, so I wondered if I was missing something that would allow this in a simpler way.

Thanks!


From Andreas-Naumann at gmx.net  Sat Feb 16 17:03:23 2019
From: Andreas-Naumann at gmx.net (Andreas Naumann)
Date: Sat, 16 Feb 2019 23:03:23 +0100
Subject: [CMake] Static libraries depending on libraries: only on
 headers/options/defines
In-Reply-To: <9c0fbcbf5a9b4583f12ff2acb78b031bfb036e52.camel@mad-scientist.net>
References: <9c0fbcbf5a9b4583f12ff2acb78b031bfb036e52.camel@mad-scientist.net>
Message-ID: <5892f856-2230-53e6-8b83-94ba9eb30f8f@gmx.net>

Hi Paul,

I understand the relationship between libraries as strict, such that you 
always build all dependent libraries before.
In your use case I thought about splitting the libraries in the actual 
target and the interface one.
For example, you could create an interface library foo_interface
add_library(foo_interface INTERFACE )
set the properties and then link foo and bar to this interface library 
using target_link_libraries.

But be aware, that now every executable, which links against bar must 
manually link against foo. If your project is large, this seems not 
really desirable. But I think you could also split the library bar in 
two bar_withoutFoo and bar. The library bar_withoutFoo would link 
against foo_interface and compile the sources, whereas bar is an 
interface library which depends on bar_withoutFoo and foo.
The developer could than build bar completely independent from foo and 
you could transport the transitive dependencies to the executable.

I don't know if this doubled structure using pure interfaces libraries 
and the actual libraries is maintainable.

Hope that helps a bit,
Andreas

Am 16.02.19 um 20:20 schrieb Paul Smith:
> Hi all;
>
> I'm working on modernizing our large complex CMake environment.  It
> builds a number of different binaries from an even larger number of
> static libraries, and these libraries depend on each other as well, in
> that they need to include headers and, sometimes, -D options etc.
>
> I've used straightforward target_link_libraries() to declare the
> relationship between these libraries; for example:
>
>    add_library(foo STATIC ...)
>    target_include_directories(foo PUBLIC ...)
>    target_compile_definitions(foo PUBLIC ...)
>    target_compile_options(foo PUBLIC ...)
>
>    add_library(bar STATIC ...)
>    target_link_libraries(bar PUBLIC foo)
>
>    add_executable(one ...)
>    target_link_libraries(one PRIVATE bar)
>
> This works, in that everything builds properly but it has a side-effect
> we want to avoid.  Because the source tree is large many developers
> have a habit of testing compilation of subsets of the code using
> something like:
>
>    make -jX bar
>
> and expect it to just build the static library bar.  Because it's a
> static library you don't need to actually build "foo" until link time.
> But we do need all the include directories, compile definitions, and
> compile options to be inherited from "foo" into "bar".
>
> However with the above formulation, building "bar" also forces the
> compilation of "foo", which we don't need or want.
>
> I've played around with the different values of PUBLIC, PRIVATE, and
> INTERFACE but there doesn't seem to be a straightforward way to say,
> "take the interface values for includes, definitions, and options, but
> don't depend on the generated target".
>
> I can write a function to do this myself but this seems like the most
> common way someone would want to treat static libraries referencing
> other static libraries, so I wondered if I was missing something that would allow this in a simpler way.
>
> Thanks!
>


From paul at mad-scientist.net  Sat Feb 16 17:46:20 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Sat, 16 Feb 2019 17:46:20 -0500
Subject: [CMake] Static libraries depending on libraries: only on
 headers/options/defines
In-Reply-To: <5892f856-2230-53e6-8b83-94ba9eb30f8f@gmx.net>
References: <9c0fbcbf5a9b4583f12ff2acb78b031bfb036e52.camel@mad-scientist.net>
 <5892f856-2230-53e6-8b83-94ba9eb30f8f@gmx.net>
Message-ID: <7f40ad8cf4de1f84ec9baa273ed8038d00f83907.camel@mad-scientist.net>

I wrote this function.  At first attempt it seems to do what I want but
I've definitely not completed my work so I may well still find issues
with it.

Basically it does everything that target_link_libraries() does (at
least, it tries to as best as I understand it other than a bunch of
properties I don't know what they are and don't use) with one caveat:
it adds libraries to INTERFACE_* but not LINK_LIBRARIES:

function(static_link_libraries tgt mode)
    foreach(lib ${ARGN})
        # Import all the source-level properties as normal
        foreach(t COMPILE_DEFINITIONS COMPILE_FEATURES COMPILE_OPTIONS
                  INCLUDE_DIRECTORIES SOURCES SYSTEM_INCLUDE_DIRECTORIES)
            if(${mode} STREQUAL "PRIVATE" OR ${mode} STREQUAL "PUBLIC")
                set_property(TARGET ${tgt} APPEND PROPERTY
                    ${t} $<TARGET_PROPERTY:${lib},INTERFACE_${t}>)
            endif()
            if(${mode} STREQUAL "PUBLIC" OR ${mode} STREQUAL "INTERFACE")
                set_property(TARGET ${tgt} APPEND PROPERTY
                    INTERFACE_${t} $<TARGET_PROPERTY:${lib},INTERFACE_${t}>)
            endif()
        endforeach()
        # Import all the library-level properties as INTERFACE only
        foreach(t LINK_DEPENDS LINK_DIRECTORIES LINK_OPTIONS)
            set_property(TARGET ${tgt} APPEND PROPERTY
                INTERFACE_${t} $<TARGET_PROPERTY:${lib},INTERFACE_${t}>)
        endforeach()
        # Import the library itself as INTERFACE only
        set_property(TARGET ${tgt} APPEND PROPERTY
            INTERFACE_LINK_LIBRARIES ${lib})
    endforeach()
endfunction()



On Sat, 2019-02-16 at 23:03 +0100, Andreas Naumann wrote:
> Hi Paul,
> 
> I understand the relationship between libraries as strict, such that you 
> always build all dependent libraries before.
> In your use case I thought about splitting the libraries in the actual 
> target and the interface one.
> For example, you could create an interface library foo_interface
> add_library(foo_interface INTERFACE )
> set the properties and then link foo and bar to this interface library 
> using target_link_libraries.
> 
> But be aware, that now every executable, which links against bar must 
> manually link against foo. If your project is large, this seems not 
> really desirable. But I think you could also split the library bar in 
> two bar_withoutFoo and bar. The library bar_withoutFoo would link 
> against foo_interface and compile the sources, whereas bar is an 
> interface library which depends on bar_withoutFoo and foo.
> The developer could than build bar completely independent from foo and 
> you could transport the transitive dependencies to the executable.
> 
> I don't know if this doubled structure using pure interfaces libraries 
> and the actual libraries is maintainable.
> 
> Hope that helps a bit,
> Andreas
> 
> Am 16.02.19 um 20:20 schrieb Paul Smith:
> > Hi all;
> > 
> > I'm working on modernizing our large complex CMake environment.  It
> > builds a number of different binaries from an even larger number of
> > static libraries, and these libraries depend on each other as well, in
> > that they need to include headers and, sometimes, -D options etc.
> > 
> > I've used straightforward target_link_libraries() to declare the
> > relationship between these libraries; for example:
> > 
> >    add_library(foo STATIC ...)
> >    target_include_directories(foo PUBLIC ...)
> >    target_compile_definitions(foo PUBLIC ...)
> >    target_compile_options(foo PUBLIC ...)
> > 
> >    add_library(bar STATIC ...)
> >    target_link_libraries(bar PUBLIC foo)
> > 
> >    add_executable(one ...)
> >    target_link_libraries(one PRIVATE bar)
> > 
> > This works, in that everything builds properly but it has a side-effect
> > we want to avoid.  Because the source tree is large many developers
> > have a habit of testing compilation of subsets of the code using
> > something like:
> > 
> >    make -jX bar
> > 
> > and expect it to just build the static library bar.  Because it's a
> > static library you don't need to actually build "foo" until link time.
> > But we do need all the include directories, compile definitions, and
> > compile options to be inherited from "foo" into "bar".
> > 
> > However with the above formulation, building "bar" also forces the
> > compilation of "foo", which we don't need or want.
> > 
> > I've played around with the different values of PUBLIC, PRIVATE, and
> > INTERFACE but there doesn't seem to be a straightforward way to say,
> > "take the interface values for includes, definitions, and options, but
> > don't depend on the generated target".
> > 
> > I can write a function to do this myself but this seems like the most
> > common way someone would want to treat static libraries referencing
> > other static libraries, so I wondered if I was missing something
> > that would allow this in a simpler way.
> > 
> > Thanks!


From workbench at gmx.at  Sat Feb 16 18:26:28 2019
From: workbench at gmx.at (Workbench@gmx.at)
Date: Sun, 17 Feb 2019 00:26:28 +0100
Subject: [CMake] Question about searching for another toolchain
Message-ID: <87d9171d-6318-52e0-dda7-e507539325af@gmx.at>

Hello everyone,

i'm realtively new to CMake and i find it awesome, the best building 
system ever !


Now to my question: I want to support either intel or amd specific 
functions in my application, that means i need either the amd or the 
intel sdk, i know how i can set another toolchain and stuff but how can 
i search for the different sdk's because the use have to install them 
and i don't know where.


how can i make cmake find the toolchain i'm searching for ?


best regards!


From domen.vrankar at gmail.com  Sun Feb 17 17:35:06 2019
From: domen.vrankar at gmail.com (Domen Vrankar)
Date: Sun, 17 Feb 2019 23:35:06 +0100
Subject: [CMake] requiring parallel building but sequential linking
Message-ID: <CAKgx6B+phmOmDtk=2nLEgVFEhGJnfSOkh-aP+vA1rVaHPeEnGQ@mail.gmail.com>

Hi,

I'm building llvm project with CMake.
While build process is compiling the code I prefer running "make -j3" on my
4 core pc (bumping processor to 100% on 3 of 4 cores and using up ~5 GB of
ram - part of it is system and not build related).
While build process is linking I must run "make" with a single job because
otherwise I run out of memory (cores do little work but ram usage goes past
23 GB).

Currently I'm handling this so that I first run "make -j3" and once I get
to about 90% (first larger linking) I hit ctrl+c and run "make".

Is there a feature in CMake that would support handling this transition of
parallel builds, sequential linking out of the box?
(while I'm mostly interested in Linux/make support, having the same feature
for Windows/nmake/ninja through the same command line cmake command would
be even better)

Thanks,
Domen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190217/c1f92f3d/attachment.html>

From craig.scott at crascit.com  Sun Feb 17 18:00:53 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Mon, 18 Feb 2019 10:00:53 +1100
Subject: [CMake] requiring parallel building but sequential linking
In-Reply-To: <CAKgx6B+phmOmDtk=2nLEgVFEhGJnfSOkh-aP+vA1rVaHPeEnGQ@mail.gmail.com>
References: <CAKgx6B+phmOmDtk=2nLEgVFEhGJnfSOkh-aP+vA1rVaHPeEnGQ@mail.gmail.com>
Message-ID: <CA+dygYnkNi_p8LTALWBz0xHa7pHQzz6ccqBuQGD8kE2BUOuhXQ@mail.gmail.com>

On Mon, Feb 18, 2019 at 9:35 AM Domen Vrankar <domen.vrankar at gmail.com>
wrote:

> Hi,
>
> I'm building llvm project with CMake.
> While build process is compiling the code I prefer running "make -j3" on
> my 4 core pc (bumping processor to 100% on 3 of 4 cores and using up ~5 GB
> of ram - part of it is system and not build related).
> While build process is linking I must run "make" with a single job because
> otherwise I run out of memory (cores do little work but ram usage goes past
> 23 GB).
>
> Currently I'm handling this so that I first run "make -j3" and once I get
> to about 90% (first larger linking) I hit ctrl+c and run "make".
>
> Is there a feature in CMake that would support handling this transition of
> parallel builds, sequential linking out of the box?
> (while I'm mostly interested in Linux/make support, having the same
> feature for Windows/nmake/ninja through the same command line cmake command
> would be even better)
>

This is available for Ninja with the JOB_POOL_LINK
<https://cmake.org/cmake/help/latest/prop_tgt/JOB_POOL_LINK.html> target
property, the default for which can be set project-wide with the
CMAKE_JOB_POOL_LINK
<https://cmake.org/cmake/help/latest/variable/CMAKE_JOB_POOL_LINK.html>
variable.
You can control the number of parallel jobs for a given pool with the
JOB_POOLS <https://cmake.org/cmake/help/latest/prop_gbl/JOB_POOLS.html> global
property.


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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190218/4b86f8e0/attachment.html>

From eric.noulard at gmail.com  Mon Feb 18 02:04:19 2019
From: eric.noulard at gmail.com (Eric Noulard)
Date: Mon, 18 Feb 2019 08:04:19 +0100
Subject: [CMake] requiring parallel building but sequential linking
In-Reply-To: <CA+dygYnkNi_p8LTALWBz0xHa7pHQzz6ccqBuQGD8kE2BUOuhXQ@mail.gmail.com>
References: <CAKgx6B+phmOmDtk=2nLEgVFEhGJnfSOkh-aP+vA1rVaHPeEnGQ@mail.gmail.com>
 <CA+dygYnkNi_p8LTALWBz0xHa7pHQzz6ccqBuQGD8kE2BUOuhXQ@mail.gmail.com>
Message-ID: <CAPASGLpCdy7cThz5mhkEAZZ1aYBL=jeMj9JWMX1K=XUJtftKEQ@mail.gmail.com>

Le lun. 18 f?vr. 2019 ? 00:01, Craig Scott <craig.scott at crascit.com> a
?crit :

>
>
> On Mon, Feb 18, 2019 at 9:35 AM Domen Vrankar <domen.vrankar at gmail.com>
> wrote:
>
>> Hi,
>>
>> I'm building llvm project with CMake.
>> While build process is compiling the code I prefer running "make -j3" on
>> my 4 core pc (bumping processor to 100% on 3 of 4 cores and using up ~5 GB
>> of ram - part of it is system and not build related).
>> While build process is linking I must run "make" with a single job
>> because otherwise I run out of memory (cores do little work but ram usage
>> goes past 23 GB).
>>
>> Currently I'm handling this so that I first run "make -j3" and once I get
>> to about 90% (first larger linking) I hit ctrl+c and run "make".
>>
>> Is there a feature in CMake that would support handling this transition
>> of parallel builds, sequential linking out of the box?
>> (while I'm mostly interested in Linux/make support, having the same
>> feature for Windows/nmake/ninja through the same command line cmake command
>> would be even better)
>>
>
> This is available for Ninja with the JOB_POOL_LINK
> <https://cmake.org/cmake/help/latest/prop_tgt/JOB_POOL_LINK.html> target
> property, the default for which can be set project-wide with the
> CMAKE_JOB_POOL_LINK
> <https://cmake.org/cmake/help/latest/variable/CMAKE_JOB_POOL_LINK.html> variable.
> You can control the number of parallel jobs for a given pool with the
> JOB_POOLS <https://cmake.org/cmake/help/latest/prop_gbl/JOB_POOLS.html> global
> property.
>

I use that a lot and I shall add that, on my side, link jobs memory
consumption heavily depends on the type of build (debug, release,
profiling, etc...), moreover
the available memory amount vary a lot as well whether if the build occurs
on a "local" developer desktop or on some CI runner.
So we end up doing some very basic CMake computation in order to
automatically adapt to the local resource.
Nothing fancy but it has been proven very useful for us:

if (CMAKE_BUILD_TYPE STREQUAL "Debug")
   cmake_host_system_information(RESULT MYMEM QUERY TOTAL_PHYSICAL_MEMORY)
   # Compute the number of authorized number of link jobs by:
   #   - "saving" 4 GiB of memory
   #   - assume each debug link job may consume 2GiB
   math(EXPR NLJ "(${MYMEM}-4096)/2048")
   set_property(GLOBAL PROPERTY JOB_POOLS link_jobs=${NLJ})
   set(CMAKE_JOB_POOL_LINK link_jobs)
elseif (CMAKE_BUILD_TYPE STREQUAL "Release")
...
endif()

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190218/ee9e2ac6/attachment.html>

From workbench at gmx.at  Mon Feb 18 09:06:35 2019
From: workbench at gmx.at (Workbench@gmx.at)
Date: Mon, 18 Feb 2019 15:06:35 +0100
Subject: [CMake] Question about set
Message-ID: <58d4a696-d837-97ca-687d-acddf1282838@gmx.at>

Hi everyone,

i've looked the web but found no result. I need a string variable that 
allows only certain values, like bool variables only allow true/false my 
string should be either "A" or "B" ...


best regards!


From francis.giraldeau at gmail.com  Mon Feb 18 09:56:44 2019
From: francis.giraldeau at gmail.com (Francis Giraldeau)
Date: Mon, 18 Feb 2019 09:56:44 -0500
Subject: [CMake] fixup-bundle usability
In-Reply-To: <3dd4050a-dd47-0e7c-b3cd-e6bffded0b66@gmx.net>
References: <3dd4050a-dd47-0e7c-b3cd-e6bffded0b66@gmx.net>
Message-ID: <CAC6yHM4vu+z5EpF8B2_qQgyMGP-bMSNss_RYYJDbxZhtdRk9ZA@mail.gmail.com>

You are right, the fixup bundle is difficult to use. Here are some
undocumented tips:

Put the install(CODE) with the fixup_bundle() call in a CMakeLists.txt in
its own directory. In your main CMakeLists.txt file, add this directory
with add_subdirectory() last. This install(CODE) will run after all the
other install directive, otherwise the fixup_bundle() might run before
other targets are installed.

The main thing is to build the library path variable. Yes, this information
can be recovered from the target itself, but fixup_bundle() won't gather
that info for you. Here is an example with Qt:

get_target_property(QT_CORE_LIB Qt5::Core LOCATION)

get_filename_component(QT_RUNTIME_DIR "${QT_CORE_LIB}" DIRECTORY)

list(APPEND LIBS_PATH "${QT_RUNTIME_DIR}")


If you are using VTK, there is already a variable:

list(APPEND LIBS_PATH "${VTK_RUNTIME_LIBRARY_DIRS}")


You might as well run windeployqt (and similar tool for other platforms)
inside install(CODE) script if you have a Qt app, such that the styles and
the plugins and other stuff gets copied.

execute_process(COMMAND windeployqt.exe --release \"\${MAIN_APP}\")


Workaround wrong tool detection using MinGW on Windows:

if(WIN32 AND NOT MSVC)

  set(GP_TOOL "objdump")

endif()


install(CODE "\

...

  include(BundleUtilities)

  set(gp_tool \"${GP_TOOL}\")

  fixup_bundle(\"\${MAIN_APP}\" \"\" \"${LIBS_PATH}\")

...


And there is the escaping... You have to escape quotes inside
the script. Escape the '$' sign if you want to refer to the
variable at install time. Remember that you don't have access

to configure-time variables at install time. Unescaped '$' prefix

will be replaced by its value at configure time, somewhat like

a macro or a template.


To see the generated script, look into ${CMAKE_BINARY_DIR} with

the directory name corresponding to the CMakeLists.txt containing

the install(CODE). Example:


${CMAKE_SOURCE_DIR}/cmake/bundle/CMakeLists.txt

-> ${CMAKE_BINARY_DIR}/cmake/bundle/cmake_install.cmake


You can check the generated script, its very

handy when things go wrong.


Also, it is easier to put all libraries and binaries in their

own directory. I have this near the begining of my project's

CMakeLists.


set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)

set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)

set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)


If you have some library that you don't want in your bundle,

you might want to disable install for it, for instance,

google test:


add_subdirectory(3rdparty/googletest/ EXCLUDE_FROM_ALL)


I'm using "ntldd.exe -R" on Windows to check the dependencies manually

(its very much like ldd on Linux). It is much more handy than

dependency walker.


Fixup_bundle is not magical either. The library dependencies must be

known beforehand. It means that if you do some dlopen() tricks at

runtime, fixup_bundle() cannot know that and you will have to install

these libraries manually yourself. One notable example of this is

Intel MKL using the Single Dynamic Library (mkl_rt). Using this

library entry point simplifies the linking and will load the

best library at runtime depending on the hardware. Fixup_bundle() will

copy only mkl_rt and you have to copy the other mkl libraries to

avoid runtime error.


Fixup bundle is tricky to put in place, but having a fixed list

of libraries to copy is even more cumbersome and flaky. When

supplied with the proper directories, the bundle is right every time.


Francis


Le sam. 16 f?vr. 2019 ? 04:04, Andreas Naumann <Andreas-Naumann at gmx.net> a
?crit :

> Dear CMakers,
>
> recently I tried to bundle an application in Windows. From the
> documentation [1] I see that I should provide the directories to the
> non-system libraries.
>
> But these information should be already in the properties of the
> targets, arent they? Is there any extension in cmake, that provides
> these paths?
>
> How do other users handle dependencies to external dlls?
>
>
> [1] https://cmake.org/cmake/help/v3.0/module/BundleUtilities.html
>
> Regards,
> Andreas
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 
Francis Giraldeau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190218/ad5e0611/attachment-0001.html>

From workbench at gmx.at  Mon Feb 18 10:48:20 2019
From: workbench at gmx.at (Workbench@gmx.at)
Date: Mon, 18 Feb 2019 16:48:20 +0100
Subject: [CMake] Question about CMAKE_MODULE_PATH
Message-ID: <a69926e5-6cc6-56c8-d296-db43559f95fb@gmx.at>

Hi everyone,


i try to load custom modules. i use


list(append CMAKE_MODULE_PATH "/mypathtomdoules")

and then i try to load the module with

include(mymodule)

but he can't find it. now i tried to output the content of 
CMAKE_MODULE_PATH with the cmake_print_variable from the 
CMakePrintHelpers module and the output of

cmake_print_variables(CMAKE_MODULE_PATH) is "" ...


what's going on here ?


best regards!


From workbench at gmx.at  Mon Feb 18 10:50:57 2019
From: workbench at gmx.at (Workbench@gmx.at)
Date: Mon, 18 Feb 2019 16:50:57 +0100
Subject: [CMake] Question about CMAKE_MODULE_PATH
In-Reply-To: <a69926e5-6cc6-56c8-d296-db43559f95fb@gmx.at>
References: <a69926e5-6cc6-56c8-d296-db43559f95fb@gmx.at>
Message-ID: <31a0bdab-e1d4-ce3e-92d0-5ca49b7b83f5@gmx.at>

Doesn't the content of CMAKE_MODULE_PATH should also include the path to 
the default modules ??

On 18.02.19 16:48, Workbench at gmx.at wrote:
> Hi everyone,
>
>
> i try to load custom modules. i use
>
>
> list(append CMAKE_MODULE_PATH "/mypathtomdoules")
>
> and then i try to load the module with
>
> include(mymodule)
>
> but he can't find it. now i tried to output the content of 
> CMAKE_MODULE_PATH with the cmake_print_variable from the 
> CMakePrintHelpers module and the output of
>
> cmake_print_variables(CMAKE_MODULE_PATH) is "" ...
>
>
> what's going on here ?
>
>
> best regards!
>

From kyle.edwards at kitware.com  Mon Feb 18 10:54:22 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Mon, 18 Feb 2019 10:54:22 -0500
Subject: [CMake] Question about CMAKE_MODULE_PATH
In-Reply-To: <31a0bdab-e1d4-ce3e-92d0-5ca49b7b83f5@gmx.at>
References: <a69926e5-6cc6-56c8-d296-db43559f95fb@gmx.at>
 <31a0bdab-e1d4-ce3e-92d0-5ca49b7b83f5@gmx.at>
Message-ID: <1550505262.2930.9.camel@kitware.com>

On Mon, 2019-02-18 at 16:50 +0100, Workbench at gmx.at wrote:
> Doesn't the content of CMAKE_MODULE_PATH should also include the path
> to?
> the default modules ??

The default modules are automatically checked by CMake, independently
of the contents of CMAKE_MODULE_PATH. They should not normally be
present in CMAKE_MODULE_PATH.

> > i try to load custom modules. i use
> > 
> > 
> > list(append CMAKE_MODULE_PATH "/mypathtomdoules")

The "append" argument should be uppercase:

list(APPEND CMAKE_MODULE_PATH "/mypathtomodules")

Did you receive any warnings about an invalid argument to list()?

Kyle

From workbench at gmx.at  Mon Feb 18 11:04:51 2019
From: workbench at gmx.at (Workbench@gmx.at)
Date: Mon, 18 Feb 2019 17:04:51 +0100
Subject: [CMake] Fwd: Re:  Question about CMAKE_MODULE_PATH
In-Reply-To: <88188dc2-5438-c22f-e655-d375a65311ee@gmx.at>
References: <88188dc2-5438-c22f-e655-d375a65311ee@gmx.at>
Message-ID: <d6f248cb-8710-6ace-53ac-81bfc6eccefd@gmx.at>




-------- Forwarded Message --------
Subject: 	Re: [CMake] Question about CMAKE_MODULE_PATH
Date: 	Mon, 18 Feb 2019 16:58:26 +0100
From: 	Workbench at gmx.at <workbench at gmx.at>
To: 	Kyle Edwards <kyle.edwards at kitware.com>



here is my code:


set(MODULE_PATH "compile/tools/cmake/modules")

LIST(APPEND CMAKE_MODULE_PATH ${MODULE_PATH})

now i try to include with

INCLUDE(basic_tests)

and i get an error that the file can't be found when typing cmake ../ 
from within my build path.



On 18.02.19 16:54, Kyle Edwards wrote:
> On Mon, 2019-02-18 at 16:50 +0100, Workbench at gmx.at wrote:
>> Doesn't the content of CMAKE_MODULE_PATH should also include the path
>> to
>> the default modules ??
> The default modules are automatically checked by CMake, independently
> of the contents of CMAKE_MODULE_PATH. They should not normally be
> present in CMAKE_MODULE_PATH.
>
>>> i try to load custom modules. i use
>>>
>>>
>>> list(append CMAKE_MODULE_PATH "/mypathtomdoules")
> The "append" argument should be uppercase:
>
> list(APPEND CMAKE_MODULE_PATH "/mypathtomodules")
>
> Did you receive any warnings about an invalid argument to list()?
>
> Kyle
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190218/14c72bbc/attachment.html>

From kyle.edwards at kitware.com  Mon Feb 18 11:10:09 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Mon, 18 Feb 2019 11:10:09 -0500
Subject: [CMake] Fwd: Re:  Question about CMAKE_MODULE_PATH
In-Reply-To: <d6f248cb-8710-6ace-53ac-81bfc6eccefd@gmx.at>
References: <88188dc2-5438-c22f-e655-d375a65311ee@gmx.at>
 <d6f248cb-8710-6ace-53ac-81bfc6eccefd@gmx.at>
Message-ID: <1550506209.2930.13.camel@kitware.com>

On Mon, 2019-02-18 at 17:04 +0100, Workbench at gmx.at wrote:
> 
> 
> 
> -------- Forwarded Message --------
> Subject:	Re: [CMake] Question about CMAKE_MODULE_PATH
> Date:	Mon, 18 Feb 2019 16:58:26 +0100
> From:	Workbench at gmx.at <workbench at gmx.at>
> To:	Kyle Edwards <kyle.edwards at kitware.com>
> 
> here is my code:
> 
> 
> set(MODULE_PATH "compile/tools/cmake/modules")
Try this instead:
set(MODULE_PATH "${CMAKE_SOURCE_DIR}/compile/tools/cmake/modules")
Kyle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190218/e5f0517d/attachment.html>

From workbench at gmx.at  Mon Feb 18 11:15:21 2019
From: workbench at gmx.at (Workbench@gmx.at)
Date: Mon, 18 Feb 2019 17:15:21 +0100
Subject: [CMake] Fwd: Re: Question about CMAKE_MODULE_PATH
In-Reply-To: <d6f248cb-8710-6ace-53ac-81bfc6eccefd@gmx.at>
References: <88188dc2-5438-c22f-e655-d375a65311ee@gmx.at>
 <d6f248cb-8710-6ace-53ac-81bfc6eccefd@gmx.at>
Message-ID: <28a4a696-ef4b-21a5-ca71-434730eac927@gmx.at>

Thank you, that did the trick. Now my other question is there a function 
in cmake that does abort the build/makefile generation process ? for 
example if i find out the system is not 64bit - is there something like 
quit() ?

On 18.02.19 17:04, Workbench at gmx.at wrote:
>
>
>
>
> -------- Forwarded Message --------
> Subject: 	Re: [CMake] Question about CMAKE_MODULE_PATH
> Date: 	Mon, 18 Feb 2019 16:58:26 +0100
> From: 	Workbench at gmx.at <workbench at gmx.at>
> To: 	Kyle Edwards <kyle.edwards at kitware.com>
>
>
>
> here is my code:
>
>
> set(MODULE_PATH "compile/tools/cmake/modules")
>
> LIST(APPEND CMAKE_MODULE_PATH ${MODULE_PATH})
>
> now i try to include with
>
> INCLUDE(basic_tests)
>
> and i get an error that the file can't be found when typing cmake ../ 
> from within my build path.
>
>
>
> On 18.02.19 16:54, Kyle Edwards wrote:
>> On Mon, 2019-02-18 at 16:50 +0100, Workbench at gmx.at wrote:
>>> Doesn't the content of CMAKE_MODULE_PATH should also include the path
>>> to
>>> the default modules ??
>> The default modules are automatically checked by CMake, independently
>> of the contents of CMAKE_MODULE_PATH. They should not normally be
>> present in CMAKE_MODULE_PATH.
>>
>>>> i try to load custom modules. i use
>>>>
>>>>
>>>> list(append CMAKE_MODULE_PATH "/mypathtomdoules")
>> The "append" argument should be uppercase:
>>
>> list(APPEND CMAKE_MODULE_PATH "/mypathtomodules")
>>
>> Did you receive any warnings about an invalid argument to list()?
>>
>> Kyle
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190218/a1ad6ee6/attachment-0001.html>

From ggarra13 at gmail.com  Mon Feb 18 11:20:40 2019
From: ggarra13 at gmail.com (=?UTF-8?Q?Gonzalo_Garramu=c3=b1o?=)
Date: Mon, 18 Feb 2019 13:20:40 -0300
Subject: [CMake] Fwd: Re: Question about CMAKE_MODULE_PATH
In-Reply-To: <28a4a696-ef4b-21a5-ca71-434730eac927@gmx.at>
References: <88188dc2-5438-c22f-e655-d375a65311ee@gmx.at>
 <d6f248cb-8710-6ace-53ac-81bfc6eccefd@gmx.at>
 <28a4a696-ef4b-21a5-ca71-434730eac927@gmx.at>
Message-ID: <3b829ccb-e450-eba5-9c6d-7bf70b00eeb3@gmail.com>

El 18/2/19 a las 13:15, Workbench at gmx.at escribi?:

> Thank you, that did the trick. Now my other question is there a 
> function in cmake that does abort the build/makefile generation 
> process ? for example if i find out the system is not 64bit - is there 
> something like quit() ?
>
>
message( FATAL_ERROR "your quit message" )

-- 
Gonzalo Garramu?o


From workbench at gmx.at  Mon Feb 18 11:41:21 2019
From: workbench at gmx.at (Workbench@gmx.at)
Date: Mon, 18 Feb 2019 17:41:21 +0100
Subject: [CMake] Fwd: Re: Question about CMAKE_MODULE_PATH
In-Reply-To: <3b829ccb-e450-eba5-9c6d-7bf70b00eeb3@gmail.com>
References: <88188dc2-5438-c22f-e655-d375a65311ee@gmx.at>
 <d6f248cb-8710-6ace-53ac-81bfc6eccefd@gmx.at>
 <28a4a696-ef4b-21a5-ca71-434730eac927@gmx.at>
 <3b829ccb-e450-eba5-9c6d-7bf70b00eeb3@gmail.com>
Message-ID: <d4fcb4f8-0e76-2ff3-26bf-2afefe9e3aeb@gmx.at>

Thanks alot!

On 18.02.19 17:20, Gonzalo Garramu?o wrote:
> El 18/2/19 a las 13:15, Workbench at gmx.at escribi?:
>
>> Thank you, that did the trick. Now my other question is there a 
>> function in cmake that does abort the build/makefile generation 
>> process ? for example if i find out the system is not 64bit - is 
>> there something like quit() ?
>>
>>
> message( FATAL_ERROR "your quit message" )
>

From Andreas-Naumann at gmx.net  Mon Feb 18 11:59:27 2019
From: Andreas-Naumann at gmx.net (Andreas Naumann)
Date: Mon, 18 Feb 2019 17:59:27 +0100
Subject: [CMake] Question about set
In-Reply-To: <58d4a696-d837-97ca-687d-acddf1282838@gmx.at>
References: <58d4a696-d837-97ca-687d-acddf1282838@gmx.at>
Message-ID: <c108515a-fbc0-1318-b026-027e48590642@gmx.net>

Hey,

I would introduce a list with the allowed values and introduce a macro 
"checked_set", which tests the setting or aborts.

Regards,
Andreas

Am 18.02.19 um 15:06 schrieb Workbench at gmx.at:
> Hi everyone,
>
> i've looked the web but found no result. I need a string variable that 
> allows only certain values, like bool variables only allow true/false 
> my string should be either "A" or "B" ...
>
>
> best regards!
>


From kyle.edwards at kitware.com  Mon Feb 18 12:16:02 2019
From: kyle.edwards at kitware.com (Kyle Edwards)
Date: Mon, 18 Feb 2019 12:16:02 -0500
Subject: [CMake] Question about set
In-Reply-To: <c108515a-fbc0-1318-b026-027e48590642@gmx.net>
References: <58d4a696-d837-97ca-687d-acddf1282838@gmx.at>
 <c108515a-fbc0-1318-b026-027e48590642@gmx.net>
Message-ID: <1550510162.2930.17.camel@kitware.com>

On Mon, 2019-02-18 at 17:59 +0100, Andreas Naumann wrote:
> Hey,
> 
> I would introduce a list with the allowed values and introduce a
> macro?
> "checked_set", which tests the setting or aborts.
> 
> Regards,
> Andreas"
> 
> Am 18.02.19 um 15:06 schrieb Workbench at gmx.at:
> > 
> > Hi everyone,
> > 
> > i've looked the web but found no result. I need a string variable
> > that?
> > allows only certain values, like bool variables only allow
> > true/false?
> > my string should be either "A" or "B" ...

Is this a cache variable or a regular variable? Cache variables have
this enum-like support in the form of the STRINGS property. Example:

set(MYSTRING "A" CACHE STRING "Documentation for the variable")
set_property(CACHE MYSTRING PROPERTY STRINGS "A;B")

If you need to do this with an ordinary variable, consider using
variable_watch().

Kyle

From Andreas-Naumann at gmx.net  Mon Feb 18 12:44:22 2019
From: Andreas-Naumann at gmx.net (Andreas Naumann)
Date: Mon, 18 Feb 2019 18:44:22 +0100
Subject: [CMake] fixup-bundle usability
In-Reply-To: <CAC6yHM4vu+z5EpF8B2_qQgyMGP-bMSNss_RYYJDbxZhtdRk9ZA@mail.gmail.com>
References: <3dd4050a-dd47-0e7c-b3cd-e6bffded0b66@gmx.net>
 <CAC6yHM4vu+z5EpF8B2_qQgyMGP-bMSNss_RYYJDbxZhtdRk9ZA@mail.gmail.com>
Message-ID: <6d50b2ae-8292-c732-a648-89954e718e17@gmx.net>

Thank you very much for your explaination. At the moment, I link only to 
boost and some in-house libraries. When experimenting with CMake and 
reading the docs, I got the same impression as you described. And I 
hoped to miss something obvious.

When I understand you correctly, one have to set the directories from 
hand. Furthermore there are additional variables (in case of VTK), which 
contain the library directories. But modern CMake works with targets and 
properties and let the dependencies propagate.

To test the idea a little bit, I startet with the following function

function(setBundle targetName dest)
 ? install(TARGETS ${targetName} DESTINATION ${dest})

 ? get_target_property(targtDeps ${targetName} LINK_LIBRARIES)
 ? file(TO_CMAKE_PATH "${CMAKE_INSTALL_PREFIX}" instPref)
 ? set(depDirs )
 ? foreach(t IN LISTS targtDeps)
 ??? #disable the INTERFACE target due to error later.
 ??? if(TARGET ${t} AND NOT ("${t}" STREQUAL "Boost::disable_autolinking"))
 ??? ? get_target_property(isImported ${t} IMPORTED)
 ??? ? if(isImported)
 ??? ??? get_target_property(depFile ${t} IMPORTED_LOCATION_DEBUG)
 ??? ??? if(depFile)
 ??? ??? ? get_filename_component(cdepDir ${depFile} DIRECTORY)
 ??? ??? ? list(APPEND depDirs ${cdepDir})
 ??? ??? endif()
 ??? ? endif()
 ??? endif()
 ? endforeach()
 ? install(CODE "include(BundleUtilities)
fixup_bundle(\"${instPref}/${dest}/$<TARGET_FILE_NAME:${targetName}>\" 
\"\" \"${depDirs}\")")
endfunction()

It is far away from optimal and has some drawbacks, especially the 
detection of interface libraries and the location of the imported target 
should be more fail proof.

How can I ask for feature requests on gitlab? I found the issue tracker, 
but nothing in regard for a feature or improvement.

Andreas

Am 18.02.19 um 15:56 schrieb Francis Giraldeau:
> You are right, the fixup bundle is difficult to use. Here are some 
> undocumented tips:
>
> Put the install(CODE) with the fixup_bundle() call in a CMakeLists.txt 
> in its own directory. In your main CMakeLists.txt file, add this 
> directory with add_subdirectory() last. This install(CODE) will run 
> after all the other install directive, otherwise the fixup_bundle() 
> might run before other targets are installed.
>
> The main thing is to build the library path variable. Yes, this 
> information can be recovered from the target itself, but 
> fixup_bundle() won't gather that info for you. Here is an example with 
> Qt:
>
> get_target_property(QT_CORE_LIBQt5::CoreLOCATION)
> get_filename_component(QT_RUNTIME_DIR"${QT_CORE_LIB}"DIRECTORY)
> list(APPENDLIBS_PATH"${QT_RUNTIME_DIR}")
>
> If you are using VTK, there is already a variable:
> list(APPENDLIBS_PATH"${VTK_RUNTIME_LIBRARY_DIRS}")
>
> You might as well run windeployqt (and similar tool for other 
> platforms) inside install(CODE) script if you have a Qt app, such that 
> the styles and the plugins and other stuff gets copied.
>
> execute_process(COMMANDwindeployqt.exe--release\"\${MAIN_APP}\")
>
> Workaround wrong tool detection using MinGW on Windows:
> if(WIN32ANDNOTMSVC)
> set(GP_TOOL"objdump")
> endif()
> install(CODE "\
> ...
> include(BundleUtilities)
> set(gp_tool\"${GP_TOOL}\")
> fixup_bundle(\"\${MAIN_APP}\"\"\"\"${LIBS_PATH}\")
> ...
> And there is the escaping... You have to escape quotes inside
> the script. Escape the '$' sign if you want to refer to the
> variable at install time. Remember that you don't have access
> to configure-time variables at install time. Unescaped '$' prefix
> will be replaced by its value at configure time, somewhat like
> a macro or a template.
>
> To see the generated script, look into ${CMAKE_BINARY_DIR} with
> the directory name corresponding to the CMakeLists.txt containing
> the install(CODE). Example:
> ${CMAKE_SOURCE_DIR}/cmake/bundle/CMakeLists.txt
> -> ${CMAKE_BINARY_DIR}/cmake/bundle/cmake_install.cmake
> You can check the generated script, its very
> handy when things go wrong.
> Also, it is easier to put all libraries and binaries in their
> own directory. I have this near the begining of my project's
> CMakeLists.
> set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY${CMAKE_BINARY_DIR}/lib)
> set(CMAKE_LIBRARY_OUTPUT_DIRECTORY${CMAKE_BINARY_DIR}/lib)
> set(CMAKE_RUNTIME_OUTPUT_DIRECTORY${CMAKE_BINARY_DIR}/bin)
> If you have some library that you don't want in your bundle,
> you might want to disable install for it, for instance,
> google test:
> add_subdirectory(3rdparty/googletest/EXCLUDE_FROM_ALL)
> I'm using "ntldd.exe -R" on Windows to check the dependencies manually
> (its very much like ldd on Linux). It is much more handy than
> dependency walker.
> Fixup_bundle is not magical either. The library dependencies must be
> known beforehand. It means that if you do some dlopen() tricks at
> runtime, fixup_bundle() cannot know that and you will have to install
> these libraries manually yourself. One notable example of this is
> Intel MKL using the Single Dynamic Library (mkl_rt). Using this
> library entry point simplifies the linking and will load the
> best library at runtime depending on the hardware. Fixup_bundle() will
> copy only mkl_rt and you have to copy the other mkl libraries to
> avoid runtime error.
> Fixup bundle is tricky to put in place, but having a fixed list
> of libraries to copy is even more cumbersome and flaky. When
> supplied with the proper directories, the bundle is right every time.
> Francis
> Le?sam. 16 f?vr. 2019 ??04:04, Andreas Naumann 
> <Andreas-Naumann at gmx.net <mailto:Andreas-Naumann at gmx.net>> a ?crit?:
>
>     Dear CMakers,
>
>     recently I tried to bundle an application in Windows. From the
>     documentation [1] I see that I should provide the directories to the
>     non-system libraries.
>
>     But these information should be already in the properties of the
>     targets, arent they? Is there any extension in cmake, that provides
>     these paths?
>
>     How do other users handle dependencies to external dlls?
>
>
>     [1] https://cmake.org/cmake/help/v3.0/module/BundleUtilities.html
>
>     Regards,
>     Andreas
>
>     -- 
>
>     Powered by www.kitware.com <http://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:
>     https://cmake.org/mailman/listinfo/cmake
>
> -- 
> Francis Giraldeau
>


From paul at mad-scientist.net  Mon Feb 18 13:01:13 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Mon, 18 Feb 2019 13:01:13 -0500
Subject: [CMake] Static libraries depending on libraries: only on
 headers/options/defines
In-Reply-To: <7f40ad8cf4de1f84ec9baa273ed8038d00f83907.camel@mad-scientist.net>
References: <9c0fbcbf5a9b4583f12ff2acb78b031bfb036e52.camel@mad-scientist.net>
 <5892f856-2230-53e6-8b83-94ba9eb30f8f@gmx.net>
 <7f40ad8cf4de1f84ec9baa273ed8038d00f83907.camel@mad-scientist.net>
Message-ID: <099083460b464608af1bf8b7e30ce991878ae800.camel@mad-scientist.net>

FYI, this function appears to work for me with one caveat: there
appears to be a bug where SYSTEM_INCLUDE_DIRECTORIES are not handled
properly so you can't use this function if you need that property to be
propagated.

I filed https://gitlab.kitware.com/cmake/cmake/issues/18940 for that.

I think I'll submit this as an enhancement request and see what the
CMake devs think of it.  It could be there are issues that I haven't
thought of.


On Sat, 2019-02-16 at 17:46 -0500, Paul Smith wrote:
> I wrote this function.  At first attempt it seems to do what I want but
> I've definitely not completed my work so I may well still find issues
> with it.
> 
> Basically it does everything that target_link_libraries() does (at
> least, it tries to as best as I understand it other than a bunch of
> properties I don't know what they are and don't use) with one caveat:
> it adds libraries to INTERFACE_* but not LINK_LIBRARIES:
> 
> function(static_link_libraries tgt mode)
>     foreach(lib ${ARGN})
>         # Import all the source-level properties as normal
>         foreach(t COMPILE_DEFINITIONS COMPILE_FEATURES COMPILE_OPTIONS
>                   INCLUDE_DIRECTORIES SOURCES SYSTEM_INCLUDE_DIRECTORIES)
>             if(${mode} STREQUAL "PRIVATE" OR ${mode} STREQUAL "PUBLIC")
>                 set_property(TARGET ${tgt} APPEND PROPERTY
>                     ${t} $<TARGET_PROPERTY:${lib},INTERFACE_${t}>)
>             endif()
>             if(${mode} STREQUAL "PUBLIC" OR ${mode} STREQUAL "INTERFACE")
>                 set_property(TARGET ${tgt} APPEND PROPERTY
>                     INTERFACE_${t} $<TARGET_PROPERTY:${lib},INTERFACE_${t}>)
>             endif()
>         endforeach()
>         # Import all the library-level properties as INTERFACE only
>         foreach(t LINK_DEPENDS LINK_DIRECTORIES LINK_OPTIONS)
>             set_property(TARGET ${tgt} APPEND PROPERTY
>                 INTERFACE_${t} $<TARGET_PROPERTY:${lib},INTERFACE_${t}>)
>         endforeach()
>         # Import the library itself as INTERFACE only
>         set_property(TARGET ${tgt} APPEND PROPERTY
>             INTERFACE_LINK_LIBRARIES ${lib})
>     endforeach()
> endfunction()
> 
> 
> 
> On Sat, 2019-02-16 at 23:03 +0100, Andreas Naumann wrote:
> > Hi Paul,
> > 
> > I understand the relationship between libraries as strict, such that you 
> > always build all dependent libraries before.
> > In your use case I thought about splitting the libraries in the actual 
> > target and the interface one.
> > For example, you could create an interface library foo_interface
> > add_library(foo_interface INTERFACE )
> > set the properties and then link foo and bar to this interface library 
> > using target_link_libraries.
> > 
> > But be aware, that now every executable, which links against bar must 
> > manually link against foo. If your project is large, this seems not 
> > really desirable. But I think you could also split the library bar in 
> > two bar_withoutFoo and bar. The library bar_withoutFoo would link 
> > against foo_interface and compile the sources, whereas bar is an 
> > interface library which depends on bar_withoutFoo and foo.
> > The developer could than build bar completely independent from foo and 
> > you could transport the transitive dependencies to the executable.
> > 
> > I don't know if this doubled structure using pure interfaces libraries 
> > and the actual libraries is maintainable.
> > 
> > Hope that helps a bit,
> > Andreas
> > 
> > Am 16.02.19 um 20:20 schrieb Paul Smith:
> > > Hi all;
> > > 
> > > I'm working on modernizing our large complex CMake environment.  It
> > > builds a number of different binaries from an even larger number of
> > > static libraries, and these libraries depend on each other as well, in
> > > that they need to include headers and, sometimes, -D options etc.
> > > 
> > > I've used straightforward target_link_libraries() to declare the
> > > relationship between these libraries; for example:
> > > 
> > >    add_library(foo STATIC ...)
> > >    target_include_directories(foo PUBLIC ...)
> > >    target_compile_definitions(foo PUBLIC ...)
> > >    target_compile_options(foo PUBLIC ...)
> > > 
> > >    add_library(bar STATIC ...)
> > >    target_link_libraries(bar PUBLIC foo)
> > > 
> > >    add_executable(one ...)
> > >    target_link_libraries(one PRIVATE bar)
> > > 
> > > This works, in that everything builds properly but it has a side-effect
> > > we want to avoid.  Because the source tree is large many developers
> > > have a habit of testing compilation of subsets of the code using
> > > something like:
> > > 
> > >    make -jX bar
> > > 
> > > and expect it to just build the static library bar.  Because it's a
> > > static library you don't need to actually build "foo" until link time.
> > > But we do need all the include directories, compile definitions, and
> > > compile options to be inherited from "foo" into "bar".
> > > 
> > > However with the above formulation, building "bar" also forces the
> > > compilation of "foo", which we don't need or want.
> > > 
> > > I've played around with the different values of PUBLIC, PRIVATE, and
> > > INTERFACE but there doesn't seem to be a straightforward way to say,
> > > "take the interface values for includes, definitions, and options, but
> > > don't depend on the generated target".
> > > 
> > > I can write a function to do this myself but this seems like the most
> > > common way someone would want to treat static libraries referencing
> > > other static libraries, so I wondered if I was missing something
> > > that would allow this in a simpler way.
> > > 
> > > Thanks!


From workbench at gmx.at  Mon Feb 18 14:38:47 2019
From: workbench at gmx.at (Workbench@gmx.at)
Date: Mon, 18 Feb 2019 20:38:47 +0100
Subject: [CMake] Question about set
In-Reply-To: <1550510162.2930.17.camel@kitware.com>
References: <58d4a696-d837-97ca-687d-acddf1282838@gmx.at>
 <c108515a-fbc0-1318-b026-027e48590642@gmx.net>
 <1550510162.2930.17.camel@kitware.com>
Message-ID: <d2aa2548-d7b3-5667-27ab-d5454e05bcbb@gmx.at>

I need it for an INTERNAL variable, for the different android 
architecture types that are supported. so he can only set one of the 
available arch types.


On 18.02.19 18:16, Kyle Edwards wrote:
> On Mon, 2019-02-18 at 17:59 +0100, Andreas Naumann wrote:
>> Hey,
>>
>> I would introduce a list with the allowed values and introduce a
>> macro
>> "checked_set", which tests the setting or aborts.
>>
>> Regards,
>> Andreas"
>>
>> Am 18.02.19 um 15:06 schrieb Workbench at gmx.at:
>>> Hi everyone,
>>>
>>> i've looked the web but found no result. I need a string variable
>>> that
>>> allows only certain values, like bool variables only allow
>>> true/false
>>> my string should be either "A" or "B" ...
> Is this a cache variable or a regular variable? Cache variables have
> this enum-like support in the form of the STRINGS property. Example:
>
> set(MYSTRING "A" CACHE STRING "Documentation for the variable")
> set_property(CACHE MYSTRING PROPERTY STRINGS "A;B")
>
> If you need to do this with an ordinary variable, consider using
> variable_watch().
>
> Kyle
>

From workbench at gmx.at  Mon Feb 18 14:43:17 2019
From: workbench at gmx.at (Workbench@gmx.at)
Date: Mon, 18 Feb 2019 20:43:17 +0100
Subject: [CMake] Question about functions
Message-ID: <75fdeb7c-7b11-bf94-e67f-c6ad7ad3bc2b@gmx.at>

Hi everyone,

i have a function like:

FUNCTION(checksyste_64Bit arg1)

 ??? IF(CMAKE_SIZEOF_VOID_P EQUAL 8)

 ??? ??? SET(${arg1} TRUE PARENT_SCOPE)

ENDFUNCTION()


but when i call it with an INTERNAL variable i've set before with

SET(SYSTEM_64BIT FALSE CACHE INTERNAL)

checksystem_64bit(${SYSTEM_64BIT})

the ${SYSTE_64BIT} variable stays the same, i thought when i use 
PARENT_SCOPE on a variable i can change it's value from inside the 
function ?


best regards!


From Andreas-Naumann at gmx.net  Mon Feb 18 15:16:05 2019
From: Andreas-Naumann at gmx.net (Andreas Naumann)
Date: Mon, 18 Feb 2019 21:16:05 +0100
Subject: [CMake] Question about functions
In-Reply-To: <75fdeb7c-7b11-bf94-e67f-c6ad7ad3bc2b@gmx.at>
References: <75fdeb7c-7b11-bf94-e67f-c6ad7ad3bc2b@gmx.at>
Message-ID: <eb9b046a-b632-9f7a-4e07-83580f23a1c5@gmx.net>

Am 18.02.19 um 20:43 schrieb Workbench at gmx.at:
> Hi everyone,
>
> i have a function like:
>
> FUNCTION(checksyste_64Bit arg1)
>
> ??? IF(CMAKE_SIZEOF_VOID_P EQUAL 8)
>
> ??? ??? SET(${arg1} TRUE PARENT_SCOPE)
>
> ENDFUNCTION()
>
>
> but when i call it with an INTERNAL variable i've set before with
>
> SET(SYSTEM_64BIT FALSE CACHE INTERNAL)
>
> checksystem_64bit(${SYSTEM_64BIT})
>
> the ${SYSTE_64BIT} variable stays the same, i thought when i use 
> PARENT_SCOPE on a variable i can change it's value from inside the 
> function ?
>
>
> best regards!
>
You should call your function without dollar and braces around the 
variable, i.e.

 ? checksystem_64bit(SYSTEM_64BIT)


From craig.scott at crascit.com  Mon Feb 18 15:46:38 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Tue, 19 Feb 2019 07:46:38 +1100
Subject: [CMake] Question about set
In-Reply-To: <1550510162.2930.17.camel@kitware.com>
References: <58d4a696-d837-97ca-687d-acddf1282838@gmx.at>
 <c108515a-fbc0-1318-b026-027e48590642@gmx.net>
 <1550510162.2930.17.camel@kitware.com>
Message-ID: <CA+dygYnC2RJ7BnL-WGMQ5F2gSbUbr0SH8LmiCmHthTnL=fNtyg@mail.gmail.com>

On Tue, Feb 19, 2019 at 4:16 AM Kyle Edwards via CMake <cmake at cmake.org>
wrote:

> On Mon, 2019-02-18 at 17:59 +0100, Andreas Naumann wrote:
> > Hey,
> >
> > I would introduce a list with the allowed values and introduce a
> > macro
> > "checked_set", which tests the setting or aborts.
> >
> > Regards,
> > Andreas"
> >
> > Am 18.02.19 um 15:06 schrieb Workbench at gmx.at:
> > >
> > > Hi everyone,
> > >
> > > i've looked the web but found no result. I need a string variable
> > > that
> > > allows only certain values, like bool variables only allow
> > > true/false
> > > my string should be either "A" or "B" ...
>
> Is this a cache variable or a regular variable? Cache variables have
> this enum-like support in the form of the STRINGS property. Example:
>
> set(MYSTRING "A" CACHE STRING "Documentation for the variable")
> set_property(CACHE MYSTRING PROPERTY STRINGS "A;B")
>

Note that this isn't an enforcing feature, only a convenience for CMake GUI
and ccmake. It tells those tools what to show as selectable options for
that cache variable, but you can still set the variable to anything you
like via the cmake -D command line option or in the project itself.

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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/9a821f11/attachment.html>

From tjwrona1992 at gmail.com  Mon Feb 18 20:45:53 2019
From: tjwrona1992 at gmail.com (Timothy Wrona)
Date: Mon, 18 Feb 2019 20:45:53 -0500
Subject: [CMake] Using CMake as a package manager vs using a dedicated
 package management tool (like Conan)
Message-ID: <CAGrOMv0tEJuy-PVS7ZYwLXY+5WXcaLoHsY6mWgy7jcSoOpzBiw@mail.gmail.com>

I have been working on a new C++ project and I am trying to decide whether
I should use CMake as my package management system or if I should use a
dedicated package management tool such as Conan.

For more information on Conan see: https://conan.io/

I am trying to understand the main difference between using Conan to manage
dependencies vs using CMakes "FetchContent" module. Are there any
compelling reasons to prefer something like Conan?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190218/be7e9f6f/attachment.html>

From workbench at gmx.at  Mon Feb 18 21:19:37 2019
From: workbench at gmx.at (Workbench@gmx.at)
Date: Tue, 19 Feb 2019 03:19:37 +0100
Subject: [CMake] Question about set
In-Reply-To: <CA+dygYnC2RJ7BnL-WGMQ5F2gSbUbr0SH8LmiCmHthTnL=fNtyg@mail.gmail.com>
References: <58d4a696-d837-97ca-687d-acddf1282838@gmx.at>
 <c108515a-fbc0-1318-b026-027e48590642@gmx.net>
 <1550510162.2930.17.camel@kitware.com>
 <CA+dygYnC2RJ7BnL-WGMQ5F2gSbUbr0SH8LmiCmHthTnL=fNtyg@mail.gmail.com>
Message-ID: <a098d757-b2c6-8959-28f9-a7ece7aa35cf@gmx.at>

Thank you.

On 18.02.19 21:46, Craig Scott wrote:
>
>
> On Tue, Feb 19, 2019 at 4:16 AM Kyle Edwards via CMake 
> <cmake at cmake.org <mailto:cmake at cmake.org>> wrote:
>
>     On Mon, 2019-02-18 at 17:59 +0100, Andreas Naumann wrote:
>     > Hey,
>     >
>     > I would introduce a list with the allowed values and introduce a
>     > macro
>     > "checked_set", which tests the setting or aborts.
>     >
>     > Regards,
>     > Andreas"
>     >
>     > Am 18.02.19 um 15:06 schrieb Workbench at gmx.at
>     <mailto:Workbench at gmx.at>:
>     > >
>     > > Hi everyone,
>     > >
>     > > i've looked the web but found no result. I need a string variable
>     > > that
>     > > allows only certain values, like bool variables only allow
>     > > true/false
>     > > my string should be either "A" or "B" ...
>
>     Is this a cache variable or a regular variable? Cache variables have
>     this enum-like support in the form of the STRINGS property. Example:
>
>     set(MYSTRING "A" CACHE STRING "Documentation for the variable")
>     set_property(CACHE MYSTRING PROPERTY STRINGS "A;B")
>
> Note that this isn't an enforcing feature, only a convenience for 
> CMake GUI and ccmake. It tells those tools what to show as selectable 
> options for that cache variable, but you can still set the variable to 
> anything you like via the cmake -D command line option or in the 
> project itself.
>
> -- 
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> Get the hand-book for every CMake user: Professional CMake: A 
> Practical Guide <https://crascit.com/professional-cmake/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/bb565dbc/attachment.html>

From workbench at gmx.at  Mon Feb 18 23:58:13 2019
From: workbench at gmx.at (Workbench@gmx.at)
Date: Tue, 19 Feb 2019 05:58:13 +0100
Subject: [CMake] Problems with EnternalProjectAdd
Message-ID: <30266687-ad23-bcf3-7b82-6b152ef43968@gmx.at>

Hi again,

i try to install my dependencies with ExternalProjectAdd but it gives me 
troubles... what's wrong with


 ??? ExternalProject_Add(
 ??? ??? freetype
 ??? ??? PREFIX "${CMAKE_BUILD_DIR}/freetype"
 ??? ??? GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
 ??? ??? GIT_TAG 64bit
 ??? ??? BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype && 
./autgen.sh && ./configure && make"
 ??? ??? LOG_DOWNLOAD ON
 ??? ??? LOG_INSTALL ON
 ??? ??? LOG_CONFIGURE ON
 ??? ??? LOG_BUILD ON
 ??? ??? LOG_TEST ON
 ??? ??? LOG_INSTALL ON
 ??? ??? )

best regards!


From workbench at gmx.at  Tue Feb 19 00:28:33 2019
From: workbench at gmx.at (Workbench@gmx.at)
Date: Tue, 19 Feb 2019 06:28:33 +0100
Subject: [CMake] Problems with EnternalProjectAdd
In-Reply-To: <30266687-ad23-bcf3-7b82-6b152ef43968@gmx.at>
References: <30266687-ad23-bcf3-7b82-6b152ef43968@gmx.at>
Message-ID: <ec5da3c9-33ff-3faf-f358-7a7b6a1d9139@gmx.at>

I forgot the error message:

CMake Error at 
/usr/local/share/cmake-3.13/Modules/ExternalProject.cmake:1659 (file):
 ? file problem creating directory: /freetype/src/freetype-stamp
Call Stack (most recent call first):
 ? /usr/local/share/cmake-3.13/Modules/ExternalProject.cmake:3057 
(_ep_set_directories)
 ? bin/tools/cmake/modules/BSBasicTests.cmake:24 (ExternalProject_Add)
 ? CMakeLists.txt:33 (bs_install_dependencies)


CMake Error at 
/usr/local/share/cmake-3.13/Modules/ExternalProject.cmake:1661 (message):
 ? dir '/freetype/src/freetype-stamp' does not exist after
 ? file(MAKE_DIRECTORY)
Call Stack (most recent call first):
 ? /usr/local/share/cmake-3.13/Modules/ExternalProject.cmake:3057 
(_ep_set_directories)
 ? bin/tools/cmake/modules/BSBasicTests.cmake:24 (ExternalProject_Add)
 ? CMakeLists.txt:33 (bs_install_dependencies)


-- Configuring incomplete, errors occurred!
See also 
"/home/stuv/data/projects/programming/bsUltimate/build/CMakeFiles/CMakeOutput.log".


On 19.02.19 05:58, Workbench at gmx.at wrote:
> Hi again,
>
> i try to install my dependencies with ExternalProjectAdd but it gives 
> me troubles... what's wrong with
>
>
> ??? ExternalProject_Add(
> ??? ??? freetype
> ??? ??? PREFIX "${CMAKE_BUILD_DIR}/freetype"
> ??? ??? GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
> ??? ??? GIT_TAG 64bit
> ??? ??? BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype && 
> ./autgen.sh && ./configure && make"
> ??? ??? LOG_DOWNLOAD ON
> ??? ??? LOG_INSTALL ON
> ??? ??? LOG_CONFIGURE ON
> ??? ??? LOG_BUILD ON
> ??? ??? LOG_TEST ON
> ??? ??? LOG_INSTALL ON
> ??? ??? )
>
> best regards!
>

From mellery451 at gmail.com  Tue Feb 19 00:43:43 2019
From: mellery451 at gmail.com (Michael Ellery)
Date: Mon, 18 Feb 2019 21:43:43 -0800
Subject: [CMake] Problems with EnternalProjectAdd
In-Reply-To: <30266687-ad23-bcf3-7b82-6b152ef43968@gmx.at>
References: <30266687-ad23-bcf3-7b82-6b152ef43968@gmx.at>
Message-ID: <2424E81C-52C1-45FA-900F-8AEB2877B8E7@gmail.com>

CMAKE_BUILD_DIR is not a standard variable (did you mean CMAKE_BINARY_DIR ?) - and the error seems to indicate that the variable is indeed empty so it tries to create the project directory at the root level.

-Mike

> On Feb 18, 2019, at 8:58 PM, Workbench at gmx.at <workbench at gmx.at> wrote:
> 
> Hi again,
> 
> i try to install my dependencies with ExternalProjectAdd but it gives me troubles... what's wrong with
> 
> 
>     ExternalProject_Add(
>         freetype
>         PREFIX "${CMAKE_BUILD_DIR}/freetype"
>         GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
>         GIT_TAG 64bit
>         BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype && ./autgen.sh && ./configure && make"
>         LOG_DOWNLOAD ON
>         LOG_INSTALL ON
>         LOG_CONFIGURE ON
>         LOG_BUILD ON
>         LOG_TEST ON
>         LOG_INSTALL ON
>         )
> 
> best regards!
> 
> -- 
> 
> 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:
> https://cmake.org/mailman/listinfo/cmake


From workbench at gmx.at  Tue Feb 19 00:51:10 2019
From: workbench at gmx.at (Workbench@gmx.at)
Date: Tue, 19 Feb 2019 06:51:10 +0100
Subject: [CMake] Problems with EnternalProjectAdd
In-Reply-To: <2424E81C-52C1-45FA-900F-8AEB2877B8E7@gmail.com>
References: <30266687-ad23-bcf3-7b82-6b152ef43968@gmx.at>
 <2424E81C-52C1-45FA-900F-8AEB2877B8E7@gmail.com>
Message-ID: <8470741e-db47-9e9f-7c1e-a4bc044660de@gmx.at>

I played around a bit a now have the following:

set(BUILD_ENV "${CMAKE_BINARY_DIR}/build_env" CACHE STRING INTERNAL)
set(LIBRARY_DIR "${CMAKE_BINARY_DIR}/lib" CACHE STRING INTERNAL)

 ??? ExternalProject_Add(
 ??? ??? freetype
 ??? ??? PREFIX "${BUILD_ENV}/freetype"
 ??? ??? GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
 ??? ??? GIT_TAG 64bit
 ??? ??? BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype && 
./autgen.sh && ./configure && make"
 ??? ??? LOG_DOWNLOAD ON
 ??? ??? LOG_INSTALL ON
 ??? ??? LOG_CONFIGURE ON
 ??? ??? LOG_BUILD ON
 ??? ??? LOG_TEST ON
 ??? ??? LOG_INSTALL ON
 ??? ??? )

The logs are telling me: CMake Error: The source directory 
"/home/stuv/data/projects/programming/bsUltimate/build/build_env/freetype/src/freetype" 
does not appear to contain CMakeLists.txt.

Isn't the BUILD_COMMAND there if there is no CMakeLists.txt file 
available for building ? not many project provide cmake build files....


best regards!






On 19.02.19 06:43, Michael Ellery wrote:
> CMAKE_BUILD_DIR is not a standard variable (did you mean CMAKE_BINARY_DIR ?) - and the error seems to indicate that the variable is indeed empty so it tries to create the project directory at the root level.
>
> -Mike
>
>> On Feb 18, 2019, at 8:58 PM, Workbench at gmx.at <workbench at gmx.at> wrote:
>>
>> Hi again,
>>
>> i try to install my dependencies with ExternalProjectAdd but it gives me troubles... what's wrong with
>>
>>
>>      ExternalProject_Add(
>>          freetype
>>          PREFIX "${CMAKE_BUILD_DIR}/freetype"
>>          GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
>>          GIT_TAG 64bit
>>          BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype && ./autgen.sh && ./configure && make"
>>          LOG_DOWNLOAD ON
>>          LOG_INSTALL ON
>>          LOG_CONFIGURE ON
>>          LOG_BUILD ON
>>          LOG_TEST ON
>>          LOG_INSTALL ON
>>          )
>>
>> best regards!
>>
>> -- 
>>
>> 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:
>> https://cmake.org/mailman/listinfo/cmake
>

From romain.leguay at gmail.com  Tue Feb 19 00:57:42 2019
From: romain.leguay at gmail.com (Romain LEGUAY)
Date: Tue, 19 Feb 2019 06:57:42 +0100
Subject: [CMake] Problems with EnternalProjectAdd
In-Reply-To: <8470741e-db47-9e9f-7c1e-a4bc044660de@gmx.at>
References: <30266687-ad23-bcf3-7b82-6b152ef43968@gmx.at>
 <2424E81C-52C1-45FA-900F-8AEB2877B8E7@gmail.com>
 <8470741e-db47-9e9f-7c1e-a4bc044660de@gmx.at>
Message-ID: <C376B051-2BBD-46A4-A69B-B9CA102F8F3E@gmail.com>

Hi,

I think you need to set the variable CONFIGURE_COMMAND to empty like this:

> ExternalProject_Add(
>         freetype
>         PREFIX "${BUILD_ENV}/freetype"
>         GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
>         GIT_TAG 64bit
         CONFIGURE_COMMAND ""
>         BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype && ./autgen.sh && ./configure && make"
>         LOG_DOWNLOAD ON
>         LOG_INSTALL ON
>         LOG_CONFIGURE ON
>         LOG_BUILD ON
>         LOG_TEST ON
>         LOG_INSTALL ON
>         )

Envoy? de mon iPad

> Le 19 f?vr. 2019 ? 06:51, Workbench at gmx.at <workbench at gmx.at> a ?crit :
> 
> I played around a bit a now have the following:
> 
> set(BUILD_ENV "${CMAKE_BINARY_DIR}/build_env" CACHE STRING INTERNAL)
> set(LIBRARY_DIR "${CMAKE_BINARY_DIR}/lib" CACHE STRING INTERNAL)
> 
>     ExternalProject_Add(
>         freetype
>         PREFIX "${BUILD_ENV}/freetype"
>         GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
>         GIT_TAG 64bit
>         BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype && ./autgen.sh && ./configure && make"
>         LOG_DOWNLOAD ON
>         LOG_INSTALL ON
>         LOG_CONFIGURE ON
>         LOG_BUILD ON
>         LOG_TEST ON
>         LOG_INSTALL ON
>         )
> 
> The logs are telling me: CMake Error: The source directory "/home/stuv/data/projects/programming/bsUltimate/build/build_env/freetype/src/freetype" does not appear to contain CMakeLists.txt.
> 
> Isn't the BUILD_COMMAND there if there is no CMakeLists.txt file available for building ? not many project provide cmake build files....
> 
> 
> best regards!
> 
> 
> 
> 
> 
> 
>> On 19.02.19 06:43, Michael Ellery wrote:
>> CMAKE_BUILD_DIR is not a standard variable (did you mean CMAKE_BINARY_DIR ?) - and the error seems to indicate that the variable is indeed empty so it tries to create the project directory at the root level.
>> 
>> -Mike
>> 
>>> On Feb 18, 2019, at 8:58 PM, Workbench at gmx.at <workbench at gmx.at> wrote:
>>> 
>>> Hi again,
>>> 
>>> i try to install my dependencies with ExternalProjectAdd but it gives me troubles... what's wrong with
>>> 
>>> 
>>>     ExternalProject_Add(
>>>         freetype
>>>         PREFIX "${CMAKE_BUILD_DIR}/freetype"
>>>         GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
>>>         GIT_TAG 64bit
>>>         BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype && ./autgen.sh && ./configure && make"
>>>         LOG_DOWNLOAD ON
>>>         LOG_INSTALL ON
>>>         LOG_CONFIGURE ON
>>>         LOG_BUILD ON
>>>         LOG_TEST ON
>>>         LOG_INSTALL ON
>>>         )
>>> 
>>> best regards!
>>> 
>>> -- 
>>> 
>>> 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:
>>> https://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:
> https://cmake.org/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/aa3c3007/attachment-0001.html>

From workbench at gmx.at  Tue Feb 19 01:04:17 2019
From: workbench at gmx.at (Workbench@gmx.at)
Date: Tue, 19 Feb 2019 07:04:17 +0100
Subject: [CMake] Problems with EnternalProjectAdd
In-Reply-To: <C376B051-2BBD-46A4-A69B-B9CA102F8F3E@gmail.com>
References: <30266687-ad23-bcf3-7b82-6b152ef43968@gmx.at>
 <2424E81C-52C1-45FA-900F-8AEB2877B8E7@gmail.com>
 <8470741e-db47-9e9f-7c1e-a4bc044660de@gmx.at>
 <C376B051-2BBD-46A4-A69B-B9CA102F8F3E@gmail.com>
Message-ID: <60e388f1-d336-1aa0-d438-81cbad04ef35@gmx.at>

Now i'm getting:

 ?Command failed: No such file or directory

 ?? 'cd 
/home/stuv/data/projects/programming/bsUltimate/build/build_env/freetype/src/freetype 
&& ./autogen.sh && ./configure && make'

but when i go to my bsUltimate path and type that command it works...


best regards!

On 19.02.19 06:57, Romain LEGUAY wrote:
> Hi,
>
> I think you need to set the variable CONFIGURE_COMMAND to empty like this:
>
>> ExternalProject_Add(
>> ??? ??? freetype
>> ??? ??? PREFIX "${BUILD_ENV}/freetype"
>> ??? ??? GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
>> ??? ??? GIT_TAG 64bit
> CONFIGURE_COMMAND ""
>> ??? BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype && 
>> ./autgen.sh && ./configure && make"
>> ??? ??? LOG_DOWNLOAD ON
>> ??? ??? LOG_INSTALL ON
>> ??? ??? LOG_CONFIGURE ON
>> ??? ??? LOG_BUILD ON
>> ??? ??? LOG_TEST ON
>> ??? ??? LOG_INSTALL ON
>> ? ? ? ? )
>
> Envoy? de mon iPad
>
> Le 19 f?vr. 2019 ? 06:51, Workbench at gmx.at <mailto:Workbench at gmx.at> 
> <workbench at gmx.at <mailto:workbench at gmx.at>> a ?crit?:
>
>> I played around a bit a now have the following:
>>
>> set(BUILD_ENV "${CMAKE_BINARY_DIR}/build_env" CACHE STRING INTERNAL)
>> set(LIBRARY_DIR "${CMAKE_BINARY_DIR}/lib" CACHE STRING INTERNAL)
>>
>> ??? ExternalProject_Add(
>> ??? ??? freetype
>> ??? ??? PREFIX "${BUILD_ENV}/freetype"
>> ??? ??? GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
>> ??? ??? GIT_TAG 64bit
>> ??? ??? BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype && 
>> ./autgen.sh && ./configure && make"
>> ??? ??? LOG_DOWNLOAD ON
>> ??? ??? LOG_INSTALL ON
>> ??? ??? LOG_CONFIGURE ON
>> ??? ??? LOG_BUILD ON
>> ??? ??? LOG_TEST ON
>> ??? ??? LOG_INSTALL ON
>> ??? ??? )
>>
>> The logs are telling me: CMake Error: The source directory 
>> "/home/stuv/data/projects/programming/bsUltimate/build/build_env/freetype/src/freetype" 
>> does not appear to contain CMakeLists.txt.
>>
>> Isn't the BUILD_COMMAND there if there is no CMakeLists.txt file 
>> available for building ? not many project provide cmake build files....
>>
>>
>> best regards!
>>
>>
>>
>>
>>
>>
>> On 19.02.19 06:43, Michael Ellery wrote:
>>> CMAKE_BUILD_DIR is not a standard variable (did you mean 
>>> CMAKE_BINARY_DIR ?) - and the error seems to indicate that the 
>>> variable is indeed empty so it tries to create the project directory 
>>> at the root level.
>>>
>>> -Mike
>>>
>>>> On Feb 18, 2019, at 8:58 PM, Workbench at gmx.at 
>>>> <mailto:Workbench at gmx.at> <workbench at gmx.at 
>>>> <mailto:workbench at gmx.at>> wrote:
>>>>
>>>> Hi again,
>>>>
>>>> i try to install my dependencies with ExternalProjectAdd but it 
>>>> gives me troubles... what's wrong with
>>>>
>>>>
>>>> ????ExternalProject_Add(
>>>> ????????freetype
>>>> ????????PREFIX "${CMAKE_BUILD_DIR}/freetype"
>>>> ????????GIT_REPOSITORY 
>>>> "https://github.com/brooklynpacket/freetype2.git"
>>>> ????????GIT_TAG 64bit
>>>> ????????BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype 
>>>> && ./autgen.sh && ./configure && make"
>>>> ????????LOG_DOWNLOAD ON
>>>> ????????LOG_INSTALL ON
>>>> ????????LOG_CONFIGURE ON
>>>> ????????LOG_BUILD ON
>>>> ????????LOG_TEST ON
>>>> ????????LOG_INSTALL ON
>>>> ????????)
>>>>
>>>> best regards!
>>>>
>>>> -- 
>>>>
>>>> Powered by www.kitware.com <http://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:
>>>> https://cmake.org/mailman/listinfo/cmake
>>>
>> -- 
>>
>> Powered by www.kitware.com <http://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:
>> https://cmake.org/mailman/listinfo/cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/e2dab93a/attachment.html>

From workbench at gmx.at  Tue Feb 19 01:25:43 2019
From: workbench at gmx.at (Workbench@gmx.at)
Date: Tue, 19 Feb 2019 07:25:43 +0100
Subject: [CMake] Problems with EnternalProjectAdd
In-Reply-To: <60e388f1-d336-1aa0-d438-81cbad04ef35@gmx.at>
References: <30266687-ad23-bcf3-7b82-6b152ef43968@gmx.at>
 <2424E81C-52C1-45FA-900F-8AEB2877B8E7@gmail.com>
 <8470741e-db47-9e9f-7c1e-a4bc044660de@gmx.at>
 <C376B051-2BBD-46A4-A69B-B9CA102F8F3E@gmail.com>
 <60e388f1-d336-1aa0-d438-81cbad04ef35@gmx.at>
Message-ID: <152aa9fb-6d9f-1774-61a3-6b92f21e029f@gmx.at>

Can't i somehow output the pwd ??

best regards!

On 19.02.19 07:04, Workbench at gmx.at wrote:
>
> Now i'm getting:
>
> ?Command failed: No such file or directory
>
> ?? 'cd 
> /home/stuv/data/projects/programming/bsUltimate/build/build_env/freetype/src/freetype 
> && ./autogen.sh && ./configure && make'
>
> but when i go to my bsUltimate path and type that command it works...
>
>
> best regards!
>
> On 19.02.19 06:57, Romain LEGUAY wrote:
>> Hi,
>>
>> I think you need to set the variable CONFIGURE_COMMAND to empty like 
>> this:
>>
>>> ExternalProject_Add(
>>> ??? ??? freetype
>>> ??? ??? PREFIX "${BUILD_ENV}/freetype"
>>> ??? ??? GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
>>> ??? ??? GIT_TAG 64bit
>> CONFIGURE_COMMAND ""
>>> ??? ??? BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype 
>>> && ./autgen.sh && ./configure && make"
>>> ??? ??? LOG_DOWNLOAD ON
>>> ??? ??? LOG_INSTALL ON
>>> ??? ??? LOG_CONFIGURE ON
>>> ??? ??? LOG_BUILD ON
>>> ??? ??? LOG_TEST ON
>>> ??? ??? LOG_INSTALL ON
>>> ? ? ? ? )
>>
>> Envoy? de mon iPad
>>
>> Le 19 f?vr. 2019 ? 06:51, Workbench at gmx.at <mailto:Workbench at gmx.at> 
>> <workbench at gmx.at <mailto:workbench at gmx.at>> a ?crit?:
>>
>>> I played around a bit a now have the following:
>>>
>>> set(BUILD_ENV "${CMAKE_BINARY_DIR}/build_env" CACHE STRING INTERNAL)
>>> set(LIBRARY_DIR "${CMAKE_BINARY_DIR}/lib" CACHE STRING INTERNAL)
>>>
>>> ??? ExternalProject_Add(
>>> ??? ??? freetype
>>> ??? ??? PREFIX "${BUILD_ENV}/freetype"
>>> ??? ??? GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
>>> ??? ??? GIT_TAG 64bit
>>> ??? ??? BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype 
>>> && ./autgen.sh && ./configure && make"
>>> ??? ??? LOG_DOWNLOAD ON
>>> ??? ??? LOG_INSTALL ON
>>> ??? ??? LOG_CONFIGURE ON
>>> ??? ??? LOG_BUILD ON
>>> ??? ??? LOG_TEST ON
>>> ??? ??? LOG_INSTALL ON
>>> ??? ??? )
>>>
>>> The logs are telling me: CMake Error: The source directory 
>>> "/home/stuv/data/projects/programming/bsUltimate/build/build_env/freetype/src/freetype" 
>>> does not appear to contain CMakeLists.txt.
>>>
>>> Isn't the BUILD_COMMAND there if there is no CMakeLists.txt file 
>>> available for building ? not many project provide cmake build files....
>>>
>>>
>>> best regards!
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 19.02.19 06:43, Michael Ellery wrote:
>>>> CMAKE_BUILD_DIR is not a standard variable (did you mean 
>>>> CMAKE_BINARY_DIR ?) - and the error seems to indicate that the 
>>>> variable is indeed empty so it tries to create the project 
>>>> directory at the root level.
>>>>
>>>> -Mike
>>>>
>>>>> On Feb 18, 2019, at 8:58 PM, Workbench at gmx.at 
>>>>> <mailto:Workbench at gmx.at> <workbench at gmx.at 
>>>>> <mailto:workbench at gmx.at>> wrote:
>>>>>
>>>>> Hi again,
>>>>>
>>>>> i try to install my dependencies with ExternalProjectAdd but it 
>>>>> gives me troubles... what's wrong with
>>>>>
>>>>>
>>>>> ????ExternalProject_Add(
>>>>> ????????freetype
>>>>> ????????PREFIX "${CMAKE_BUILD_DIR}/freetype"
>>>>> ????????GIT_REPOSITORY 
>>>>> "https://github.com/brooklynpacket/freetype2.git"
>>>>> ????????GIT_TAG 64bit
>>>>> ????????BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype 
>>>>> && ./autgen.sh && ./configure && make"
>>>>> ????????LOG_DOWNLOAD ON
>>>>> ????????LOG_INSTALL ON
>>>>> ????????LOG_CONFIGURE ON
>>>>> ????????LOG_BUILD ON
>>>>> ????????LOG_TEST ON
>>>>> ????????LOG_INSTALL ON
>>>>> ????????)
>>>>>
>>>>> best regards!
>>>>>
>>>>> -- 
>>>>>
>>>>> Powered by www.kitware.com <http://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:
>>>>> https://cmake.org/mailman/listinfo/cmake
>>>>
>>> -- 
>>>
>>> Powered by www.kitware.com <http://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:
>>> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/52e30233/attachment-0001.html>

From craig.scott at crascit.com  Tue Feb 19 05:56:05 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Tue, 19 Feb 2019 21:56:05 +1100
Subject: [CMake] [cmake-developers] Using CMake as a package manager vs
 using a dedicated package management tool (like Conan)
In-Reply-To: <CAGrOMv0tEJuy-PVS7ZYwLXY+5WXcaLoHsY6mWgy7jcSoOpzBiw@mail.gmail.com>
References: <CAGrOMv0tEJuy-PVS7ZYwLXY+5WXcaLoHsY6mWgy7jcSoOpzBiw@mail.gmail.com>
Message-ID: <CA+dygYmKa1ACx-8B=mY889kTsidYE40Fk=zNN-1zAfpJZaWsVw@mail.gmail.com>

On Tue, Feb 19, 2019 at 12:46 PM Timothy Wrona <tjwrona1992 at gmail.com>
wrote:

> I have been working on a new C++ project and I am trying to decide whether
> I should use CMake as my package management system or if I should use a
> dedicated package management tool such as Conan.
>
> For more information on Conan see: https://conan.io/
>
> I am trying to understand the main difference between using Conan to
> manage dependencies vs using CMakes "FetchContent" module. Are there any
> compelling reasons to prefer something like Conan?
>

Excellent question, one that I think deserves a more detailed answer than I
can provide here, but I'll try to hit the main points as I see them.

Personally, I think there is no "right answer" or "one size fits all" when
it comes to package management for a CMake project. What works well for one
situation, person or project may not be as convenient or suitable for
another. There are competing needs and views, some of which are personal
preferences, others are hard requirements from things like OS distribution
policies for packaging. Even just the maturity of a project can have a big
influence on how developers may prefer to handle its dependencies and
handle it as a dependency of other projects.

The key thing for me is that the developer should ideally have choices when
it comes to this area. If a project hard-codes that its dependencies must
come from a particular provider (whether that be Conan, Hunter, vcpkg or
some other system), this might not be compatible with what the developer's
situation allows. You would need to weigh up whether it makes sense to lock
the developer into a particular package manager if they want to use your
project or not. An inappropriate choice here can mean lower adoption of the
project as some may reject it for consideration based on this point alone.

If instead a project relies only on find_package() to find its
dependencies, then it is up to the developer to ensure they are all
available. This could be done using whatever package manager the developer
finds convenient, or they could build the dependency projects from source
individually or they might set up a superbuild parent project that builds
the dependencies in the required order and makes dependees available to
dependers. This gives good flexibility at the cost of more responsibility
on the developer than perhaps some would want (again, it will be highly
situation-dependent).

A drawback with find_package() is that it assumes you actually have a
packageable project. For a variety of reasons, this may not be the case.
Consider a large, complex project in its early stages and where multiple
teams are working on different subprojects which all get combined into some
larger whole. Each of the subprojects may need to be able to build on their
own with their own smaller subset of dependencies, but they also need to be
able to be incorporated into a larger build (think of different teams
working on core toolkits, rendering engines, different algorithm
strategies, multiple GUI applications, backend components, etc). No-one may
know yet how it should get packaged up and everyone might be focused on
just getting a minimal viable prototype up and running as a technical
demonstrator. For a case like that, neither find_package() nor a package
manager really fits the workflow. In this situation though, FetchContent is
a perfect fit, since it doesn't require any packaging to already be in
place, it needs no external tools other than CMake and it gives each
project precise control over its dependencies down to the individual commit
to bring in for each one.

With the above in mind, perhaps the following few questions may be helpful
in clarifying what your constraints are and maybe steering you more toward
one way or the other:

   - Will the project be incorporated into a Linux distribution at some
   point (not just be installed on Linux, but be part of the actual Linux
   distribution as provided by its own native package manager)? If so, I would
   expect this would pretty much eliminate using any package manager and
   instead require that you use find_package() to find all dependencies.
   - Are any of the dependencies of the project using a build system other
   than CMake? If so, they tend to take a bit more work to incorporate into a
   build via ExternalProject or FetchContent. If you can assume the developer
   provides those somehow, bringing them in by find_package() shifts
   responsibility for building them from the project to the developer (or
   whatever package manager they choose to use). This might be anywhere from
   entirely appropriate to entirely problematic depending on who your intended
   audience is.
   - How many dependencies does the project have and what is the maturity
   of each one? Will the project need to update any of those dependencies
   often (are they also being actively developed, do you need to follow recent
   work in them)? What will be the impact on developers working on the project
   when these dependencies need to be updated (how easy is it for them to
   update, what assumptions are you making about their development environment
   and tools)?
   - What breadth of platforms, compilers and CMake generators do you want
   to support? The bigger this set, the more it may drive you towards building
   dependencies from source rather than relying on having pre-built packages
   available to you.
   - Do you want developers to be able to use tools like sanitizers,
   perform code refactoring across projects or have source code visibility
   into dependencies within their IDE tools? FetchContent supports all of
   these requirements quite naturally, but doing so for the other methods it
   may be more difficult.
   - How will you manage repeatability of building past releases? Will you
   be able to build a year old release again if you update a build slave? In
   particular, what assumptions are you making about a CI system's build
   slaves and what dependencies they have installed (can you have multiple
   versions of any given dependency available at once, whether that be at a
   known path or via whatever package manager(s) you choose to use)?


On a side note, this is an area I'm increasingly thinking about these days
(I'm the author of the FetchContent module). I'm interested in hearing
peoples' views on dependency management and building an understanding of
what works for people and what doesn't. If you want to send feedback my
way, do feel free to get in touch.

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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/b78a43ee/attachment.html>

From mail at kai-wolf.me  Tue Feb 19 07:56:43 2019
From: mail at kai-wolf.me (Kai Wolf)
Date: Tue, 19 Feb 2019 13:56:43 +0100
Subject: [CMake] [cmake-developers] Using CMake as a package manager vs
 using a dedicated package management tool (like Conan)
In-Reply-To: <CA+dygYmKa1ACx-8B=mY889kTsidYE40Fk=zNN-1zAfpJZaWsVw@mail.gmail.com>
References: <CAGrOMv0tEJuy-PVS7ZYwLXY+5WXcaLoHsY6mWgy7jcSoOpzBiw@mail.gmail.com>
 <CA+dygYmKa1ACx-8B=mY889kTsidYE40Fk=zNN-1zAfpJZaWsVw@mail.gmail.com>
Message-ID: <668AE1DE-54BC-4FC9-9AD6-C6FB832DE44D@kai-wolf.me>

Well, as of right now, it currently isn?t possible to use Conan in a non-intrusive way. That is, using it for fetching dependencies without adapting the build configuration to it.
I?ve opened up a pull request (as well as a fix) for this issue here [1].

I?ve implemented pure CMake-based package management solutions based on ExternalProject_Add() (using a Superbuild approach) in the past as well as using Conan for managing dependencies currently for a client of mine.
Based on my experience, I?m confident that really the only reason to use Conan is that it solves the persistence of binary artifacts for you. Since Conan uses a client/server architecture you typically have something like an Artifactory server where Conan is able to store and fetch precompiled packages for you. Currently, CMake doesn?t offer something like this, but I think it should be trivially to implement (think of CDash but for storing binary artifacts).
One issue I have with Conan is that you are forced to duplicate some of your build logic that in my point of view really belongs to the build system and not to your package management solution.


[1] https://github.com/conan-io/conan/issues/4467
--
Kai Wolf
Kai Wolf - SW Consulting
www.kai-wolf.me <http://kai-wolf.me/>
XING <https://www.xing.com/profile/Kai_Wolf14> ? LinkedIn <https://www.linkedin.com/in/kw0lf/> ? GitHub <https://github.com/NewProggie>

> Am 19.02.2019 um 11:56 schrieb Craig Scott <craig.scott at crascit.com>:
> 
> 
> 
> On Tue, Feb 19, 2019 at 12:46 PM Timothy Wrona <tjwrona1992 at gmail.com <mailto:tjwrona1992 at gmail.com>> wrote:
> I have been working on a new C++ project and I am trying to decide whether I should use CMake as my package management system or if I should use a dedicated package management tool such as Conan.
> 
> For more information on Conan see: https://conan.io/ <https://conan.io/>
> 
> I am trying to understand the main difference between using Conan to manage dependencies vs using CMakes "FetchContent" module. Are there any compelling reasons to prefer something like Conan?
> 
> Excellent question, one that I think deserves a more detailed answer than I can provide here, but I'll try to hit the main points as I see them.
> 
> Personally, I think there is no "right answer" or "one size fits all" when it comes to package management for a CMake project. What works well for one situation, person or project may not be as convenient or suitable for another. There are competing needs and views, some of which are personal preferences, others are hard requirements from things like OS distribution policies for packaging. Even just the maturity of a project can have a big influence on how developers may prefer to handle its dependencies and handle it as a dependency of other projects.
> 
> The key thing for me is that the developer should ideally have choices when it comes to this area. If a project hard-codes that its dependencies must come from a particular provider (whether that be Conan, Hunter, vcpkg or some other system), this might not be compatible with what the developer's situation allows. You would need to weigh up whether it makes sense to lock the developer into a particular package manager if they want to use your project or not. An inappropriate choice here can mean lower adoption of the project as some may reject it for consideration based on this point alone.
> 
> If instead a project relies only on find_package() to find its dependencies, then it is up to the developer to ensure they are all available. This could be done using whatever package manager the developer finds convenient, or they could build the dependency projects from source individually or they might set up a superbuild parent project that builds the dependencies in the required order and makes dependees available to dependers. This gives good flexibility at the cost of more responsibility on the developer than perhaps some would want (again, it will be highly situation-dependent).
> 
> A drawback with find_package() is that it assumes you actually have a packageable project. For a variety of reasons, this may not be the case. Consider a large, complex project in its early stages and where multiple teams are working on different subprojects which all get combined into some larger whole. Each of the subprojects may need to be able to build on their own with their own smaller subset of dependencies, but they also need to be able to be incorporated into a larger build (think of different teams working on core toolkits, rendering engines, different algorithm strategies, multiple GUI applications, backend components, etc). No-one may know yet how it should get packaged up and everyone might be focused on just getting a minimal viable prototype up and running as a technical demonstrator. For a case like that, neither find_package() nor a package manager really fits the workflow. In this situation though, FetchContent is a perfect fit, since it doesn't require any packaging to already be in place, it needs no external tools other than CMake and it gives each project precise control over its dependencies down to the individual commit to bring in for each one.
> 
> With the above in mind, perhaps the following few questions may be helpful in clarifying what your constraints are and maybe steering you more toward one way or the other:
> Will the project be incorporated into a Linux distribution at some point (not just be installed on Linux, but be part of the actual Linux distribution as provided by its own native package manager)? If so, I would expect this would pretty much eliminate using any package manager and instead require that you use find_package() to find all dependencies.
> Are any of the dependencies of the project using a build system other than CMake? If so, they tend to take a bit more work to incorporate into a build via ExternalProject or FetchContent. If you can assume the developer provides those somehow, bringing them in by find_package() shifts responsibility for building them from the project to the developer (or whatever package manager they choose to use). This might be anywhere from entirely appropriate to entirely problematic depending on who your intended audience is.
> How many dependencies does the project have and what is the maturity of each one? Will the project need to update any of those dependencies often (are they also being actively developed, do you need to follow recent work in them)? What will be the impact on developers working on the project when these dependencies need to be updated (how easy is it for them to update, what assumptions are you making about their development environment and tools)?
> What breadth of platforms, compilers and CMake generators do you want to support? The bigger this set, the more it may drive you towards building dependencies from source rather than relying on having pre-built packages available to you.
> Do you want developers to be able to use tools like sanitizers, perform code refactoring across projects or have source code visibility into dependencies within their IDE tools? FetchContent supports all of these requirements quite naturally, but doing so for the other methods it may be more difficult.
> How will you manage repeatability of building past releases? Will you be able to build a year old release again if you update a build slave? In particular, what assumptions are you making about a CI system's build slaves and what dependencies they have installed (can you have multiple versions of any given dependency available at once, whether that be at a known path or via whatever package manager(s) you choose to use)?
> 
> On a side note, this is an area I'm increasingly thinking about these days (I'm the author of the FetchContent module). I'm interested in hearing peoples' views on dependency management and building an understanding of what works for people and what doesn't. If you want to send feedback my way, do feel free to get in touch.
> 
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com <https://crascit.com/>
> 
> Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-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:
> https://cmake.org/mailman/listinfo/cmake

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/c2a99acb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/c2a99acb/attachment-0001.sig>

From kai.wolf at gmail.com  Tue Feb 19 09:37:23 2019
From: kai.wolf at gmail.com (Kai Wolf)
Date: Tue, 19 Feb 2019 15:37:23 +0100
Subject: [CMake] [cmake-developers] Using CMake as a package manager vs
 using a dedicated package management tool (like Conan)
In-Reply-To: <CA+dygYmKa1ACx-8B=mY889kTsidYE40Fk=zNN-1zAfpJZaWsVw@mail.gmail.com>
References: <CAGrOMv0tEJuy-PVS7ZYwLXY+5WXcaLoHsY6mWgy7jcSoOpzBiw@mail.gmail.com>
 <CA+dygYmKa1ACx-8B=mY889kTsidYE40Fk=zNN-1zAfpJZaWsVw@mail.gmail.com>
Message-ID: <BB84627C-BE3D-4F12-A00F-D72ADF4A897A@gmail.com>

Well, as of right now, it currently isn?t possible to use Conan in a non-intrusive way. That is, using it for fetching dependencies without adapting the build configuration to it.
I?ve opened up a pull request (as well as a fix) for this issue here [1].

I?ve implemented pure CMake-based package management solutions based on ExternalProject_Add() (using a Superbuild approach) in the past as well as using Conan for managing dependencies currently for a client of mine.
Based on my experience, I?m confident that really the only reason to use Conan is that it solves the persistence of binary artifacts for you. Since Conan uses a client/server architecture you typically have something like an Artifactory server where Conan is able to store and fetch precompiled packages for you. Currently, CMake doesn?t offer something like this, but I think it should be trivially to implement (think of CDash but for storing binary artifacts).
One issue I have with Conan is that you are forced to duplicate some of your build logic that in my point of view really belongs to the build system and not to your package management solution.


[1] https://github.com/conan-io/conan/issues/4467 <https://github.com/conan-io/conan/issues/4467>
--
Kai Wolf
Kai Wolf - SW Consulting
www.kai-wolf.me <http://kai-wolf.me/>
XING <https://www.xing.com/profile/Kai_Wolf14> ? LinkedIn <https://www.linkedin.com/in/kw0lf/> ? GitHub <https://github.com/NewProggie>

> Am 19.02.2019 um 11:56 schrieb Craig Scott <craig.scott at crascit.com>:
> 
> 
> 
> On Tue, Feb 19, 2019 at 12:46 PM Timothy Wrona <tjwrona1992 at gmail.com <mailto:tjwrona1992 at gmail.com>> wrote:
> I have been working on a new C++ project and I am trying to decide whether I should use CMake as my package management system or if I should use a dedicated package management tool such as Conan.
> 
> For more information on Conan see: https://conan.io/ <https://conan.io/>
> 
> I am trying to understand the main difference between using Conan to manage dependencies vs using CMakes "FetchContent" module. Are there any compelling reasons to prefer something like Conan?
> 
> Excellent question, one that I think deserves a more detailed answer than I can provide here, but I'll try to hit the main points as I see them.
> 
> Personally, I think there is no "right answer" or "one size fits all" when it comes to package management for a CMake project. What works well for one situation, person or project may not be as convenient or suitable for another. There are competing needs and views, some of which are personal preferences, others are hard requirements from things like OS distribution policies for packaging. Even just the maturity of a project can have a big influence on how developers may prefer to handle its dependencies and handle it as a dependency of other projects.
> 
> The key thing for me is that the developer should ideally have choices when it comes to this area. If a project hard-codes that its dependencies must come from a particular provider (whether that be Conan, Hunter, vcpkg or some other system), this might not be compatible with what the developer's situation allows. You would need to weigh up whether it makes sense to lock the developer into a particular package manager if they want to use your project or not. An inappropriate choice here can mean lower adoption of the project as some may reject it for consideration based on this point alone.
> 
> If instead a project relies only on find_package() to find its dependencies, then it is up to the developer to ensure they are all available. This could be done using whatever package manager the developer finds convenient, or they could build the dependency projects from source individually or they might set up a superbuild parent project that builds the dependencies in the required order and makes dependees available to dependers. This gives good flexibility at the cost of more responsibility on the developer than perhaps some would want (again, it will be highly situation-dependent).
> 
> A drawback with find_package() is that it assumes you actually have a packageable project. For a variety of reasons, this may not be the case. Consider a large, complex project in its early stages and where multiple teams are working on different subprojects which all get combined into some larger whole. Each of the subprojects may need to be able to build on their own with their own smaller subset of dependencies, but they also need to be able to be incorporated into a larger build (think of different teams working on core toolkits, rendering engines, different algorithm strategies, multiple GUI applications, backend components, etc). No-one may know yet how it should get packaged up and everyone might be focused on just getting a minimal viable prototype up and running as a technical demonstrator. For a case like that, neither find_package() nor a package manager really fits the workflow. In this situation though, FetchContent is a perfect fit, since it doesn't require any packaging to already be in place, it needs no external tools other than CMake and it gives each project precise control over its dependencies down to the individual commit to bring in for each one.
> 
> With the above in mind, perhaps the following few questions may be helpful in clarifying what your constraints are and maybe steering you more toward one way or the other:
> Will the project be incorporated into a Linux distribution at some point (not just be installed on Linux, but be part of the actual Linux distribution as provided by its own native package manager)? If so, I would expect this would pretty much eliminate using any package manager and instead require that you use find_package() to find all dependencies.
> Are any of the dependencies of the project using a build system other than CMake? If so, they tend to take a bit more work to incorporate into a build via ExternalProject or FetchContent. If you can assume the developer provides those somehow, bringing them in by find_package() shifts responsibility for building them from the project to the developer (or whatever package manager they choose to use). This might be anywhere from entirely appropriate to entirely problematic depending on who your intended audience is.
> How many dependencies does the project have and what is the maturity of each one? Will the project need to update any of those dependencies often (are they also being actively developed, do you need to follow recent work in them)? What will be the impact on developers working on the project when these dependencies need to be updated (how easy is it for them to update, what assumptions are you making about their development environment and tools)?
> What breadth of platforms, compilers and CMake generators do you want to support? The bigger this set, the more it may drive you towards building dependencies from source rather than relying on having pre-built packages available to you.
> Do you want developers to be able to use tools like sanitizers, perform code refactoring across projects or have source code visibility into dependencies within their IDE tools? FetchContent supports all of these requirements quite naturally, but doing so for the other methods it may be more difficult.
> How will you manage repeatability of building past releases? Will you be able to build a year old release again if you update a build slave? In particular, what assumptions are you making about a CI system's build slaves and what dependencies they have installed (can you have multiple versions of any given dependency available at once, whether that be at a known path or via whatever package manager(s) you choose to use)?
> 
> On a side note, this is an area I'm increasingly thinking about these days (I'm the author of the FetchContent module). I'm interested in hearing peoples' views on dependency management and building an understanding of what works for people and what doesn't. If you want to send feedback my way, do feel free to get in touch.
> 
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com <https://crascit.com/>
> 
> Get the hand-book for every CMake user: Professional CMake: A Practical Guide <https://crascit.com/professional-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:
> https://cmake.org/mailman/listinfo/cmake

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/cb2e4f29/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/cb2e4f29/attachment.sig>

From tjwrona1992 at gmail.com  Tue Feb 19 10:33:56 2019
From: tjwrona1992 at gmail.com (Timothy Wrona)
Date: Tue, 19 Feb 2019 10:33:56 -0500
Subject: [CMake] [cmake-developers] Using CMake as a package manager vs
 using a dedicated package management tool (like Conan)
In-Reply-To: <CA+dygYmKa1ACx-8B=mY889kTsidYE40Fk=zNN-1zAfpJZaWsVw@mail.gmail.com>
References: <CAGrOMv0tEJuy-PVS7ZYwLXY+5WXcaLoHsY6mWgy7jcSoOpzBiw@mail.gmail.com>
 <CA+dygYmKa1ACx-8B=mY889kTsidYE40Fk=zNN-1zAfpJZaWsVw@mail.gmail.com>
Message-ID: <CAGrOMv2k4jk-z=Yfqzb-_KGUtOOfstUt5Kkz72UBORpdipXhtA@mail.gmail.com>

Hi Craig,

Thank you for the detailed description!

To answer some of your questions:

   - This project will not be incorporated into a Linux distribution,
   however I would like to keep it cross platform and it should work on
   Windows, Mac, and Linux.
   - All of the pieces of the project that I am writing myself are using
   CMake, but I do have some dependencies on external libs such as
   "googletest" and "boost". Conan does seem to make using these external
   dependencies very simple - especially since I am using MinGW to do my
   compilation and "googletest" doesn't seem to compile out of the box on
   MinGW without passing specific flags to the compiler. With Conan I get a
   pre-compiled binary so it just works out of the box.
   - At the current time, this project does not have many dependencies,
   although it will likely grow quite large. I don't believe the external 3rd
   party dependencies will need to update frequently, but all of the libraries
   I am writing for the project will likely change quite a bit throughout
   working on the project. I would also like to be able to compile these
   libraries independently for reuse in other projects.
   - I intend to support as many platforms/compilers as possible, I am
   currently using Qt as my dev environment which allows me to
   install/configure multiple compilers and try builds with each one - this
   way I can at least do a build with both MinGW and msvc very quickly.
   - I would like to support tools like sanitizers and code refactoring
   tools at least within my own libraries (not necessarily with any of the 3rd
   party libs)
   - I would like past releases to be repeatable/rebuildable as much as
   possible, although when the compiler is upgraded it is understandable that
   past versions may have issues. I don't have much understanding of CI
   systems at this point and it is something I have been trying to become more
   familiar with. I'd like to avoid having multiple versions of the same
   dependency, although I don't think having two versions of "googletest" for
   two separate sub-projects that don't depend on each other would cause any
   issues.
      - I imagine Conan would make past releases more repeatable since you
      can fetch binary packages instead of needing to rebuild from source and
      package versions are always explicit.

I am currently the only developer working on the project, but I would still
like to find the most efficient method of managing packages for my
particular situation since it will likely save me a lot of pain down the
road if I get it right up-front. This project is in the situation where I
have a set of different sub-projects (libraries) that all need to be able
to be compiled independently for re-use, but I have a main project that
will use them all. All of these projects have their own dependencies (some
of them 3rd party, some of them written by me). The 3rd party libs will
likely rarely change, but the ones written by me may change quite
frequently.

This is an approach I was thinking about taking:

   - *So far I have tried this and it is working well* - Manage 3rd party
   libs with Conan, since I don't need to see the source and it's quite
   convenient to not need to recompile them this seems to work pretty well.
   Using "FetchContent" on 3rd party libs and then attempting to compile them
   yourself can sometimes be tricky (for example "googletest" requires special
   compiler flags to be compiled with MinGW.) It also ensures that if two
   projects ask for the same version of a dependency I get only one copy even
   if the projects are built entirely independent of each other.
   - *I haven't tried this yet, but I am hoping it will work well* - Pull
   my sub-projects (my own custom libraries) into their own independent git
   repos and pull them into my main project using "FetchContent". Then when I
   run "FetchContent" it will checkout the sub-projects and I will have all of
   the source code available. I am hoping if I do this any changes I make to
   the sub-projects can easily be committed and pushed back to their own
   independent repositories.
   - The alternative to this would be to put my own sub-projects into their
      own Conan packages and use Conan to get them from the main project. But I
      am thinking since they will change frequently, "FetchContent" may be a
      better fit for this scenario.
      - Maybe when the sub-project libraries reach a mature and stable
      release they should be packaged into Conan and fetched in the
main project
      from Conan at that point?

Let me know what you think! :)


On Tue, Feb 19, 2019 at 5:56 AM Craig Scott <craig.scott at crascit.com> wrote:

>
>
> On Tue, Feb 19, 2019 at 12:46 PM Timothy Wrona <tjwrona1992 at gmail.com>
> wrote:
>
>> I have been working on a new C++ project and I am trying to decide
>> whether I should use CMake as my package management system or if I should
>> use a dedicated package management tool such as Conan.
>>
>> For more information on Conan see: https://conan.io/
>>
>> I am trying to understand the main difference between using Conan to
>> manage dependencies vs using CMakes "FetchContent" module. Are there any
>> compelling reasons to prefer something like Conan?
>>
>
> Excellent question, one that I think deserves a more detailed answer than
> I can provide here, but I'll try to hit the main points as I see them.
>
> Personally, I think there is no "right answer" or "one size fits all" when
> it comes to package management for a CMake project. What works well for one
> situation, person or project may not be as convenient or suitable for
> another. There are competing needs and views, some of which are personal
> preferences, others are hard requirements from things like OS distribution
> policies for packaging. Even just the maturity of a project can have a big
> influence on how developers may prefer to handle its dependencies and
> handle it as a dependency of other projects.
>
> The key thing for me is that the developer should ideally have choices
> when it comes to this area. If a project hard-codes that its dependencies
> must come from a particular provider (whether that be Conan, Hunter, vcpkg
> or some other system), this might not be compatible with what the
> developer's situation allows. You would need to weigh up whether it makes
> sense to lock the developer into a particular package manager if they want
> to use your project or not. An inappropriate choice here can mean lower
> adoption of the project as some may reject it for consideration based on
> this point alone.
>
> If instead a project relies only on find_package() to find its
> dependencies, then it is up to the developer to ensure they are all
> available. This could be done using whatever package manager the developer
> finds convenient, or they could build the dependency projects from source
> individually or they might set up a superbuild parent project that builds
> the dependencies in the required order and makes dependees available to
> dependers. This gives good flexibility at the cost of more responsibility
> on the developer than perhaps some would want (again, it will be highly
> situation-dependent).
>
> A drawback with find_package() is that it assumes you actually have a
> packageable project. For a variety of reasons, this may not be the case.
> Consider a large, complex project in its early stages and where multiple
> teams are working on different subprojects which all get combined into some
> larger whole. Each of the subprojects may need to be able to build on their
> own with their own smaller subset of dependencies, but they also need to be
> able to be incorporated into a larger build (think of different teams
> working on core toolkits, rendering engines, different algorithm
> strategies, multiple GUI applications, backend components, etc). No-one may
> know yet how it should get packaged up and everyone might be focused on
> just getting a minimal viable prototype up and running as a technical
> demonstrator. For a case like that, neither find_package() nor a package
> manager really fits the workflow. In this situation though, FetchContent is
> a perfect fit, since it doesn't require any packaging to already be in
> place, it needs no external tools other than CMake and it gives each
> project precise control over its dependencies down to the individual commit
> to bring in for each one.
>
> With the above in mind, perhaps the following few questions may be helpful
> in clarifying what your constraints are and maybe steering you more toward
> one way or the other:
>
>    - Will the project be incorporated into a Linux distribution at some
>    point (not just be installed on Linux, but be part of the actual Linux
>    distribution as provided by its own native package manager)? If so, I would
>    expect this would pretty much eliminate using any package manager and
>    instead require that you use find_package() to find all dependencies.
>    - Are any of the dependencies of the project using a build system
>    other than CMake? If so, they tend to take a bit more work to incorporate
>    into a build via ExternalProject or FetchContent. If you can assume the
>    developer provides those somehow, bringing them in by find_package() shifts
>    responsibility for building them from the project to the developer (or
>    whatever package manager they choose to use). This might be anywhere from
>    entirely appropriate to entirely problematic depending on who your intended
>    audience is.
>    - How many dependencies does the project have and what is the maturity
>    of each one? Will the project need to update any of those dependencies
>    often (are they also being actively developed, do you need to follow recent
>    work in them)? What will be the impact on developers working on the project
>    when these dependencies need to be updated (how easy is it for them to
>    update, what assumptions are you making about their development environment
>    and tools)?
>    - What breadth of platforms, compilers and CMake generators do you
>    want to support? The bigger this set, the more it may drive you towards
>    building dependencies from source rather than relying on having pre-built
>    packages available to you.
>    - Do you want developers to be able to use tools like sanitizers,
>    perform code refactoring across projects or have source code visibility
>    into dependencies within their IDE tools? FetchContent supports all of
>    these requirements quite naturally, but doing so for the other methods it
>    may be more difficult.
>    - How will you manage repeatability of building past releases? Will
>    you be able to build a year old release again if you update a build slave?
>    In particular, what assumptions are you making about a CI system's build
>    slaves and what dependencies they have installed (can you have multiple
>    versions of any given dependency available at once, whether that be at a
>    known path or via whatever package manager(s) you choose to use)?
>
>
> On a side note, this is an area I'm increasingly thinking about these days
> (I'm the author of the FetchContent module). I'm interested in hearing
> peoples' views on dependency management and building an understanding of
> what works for people and what doesn't. If you want to send feedback my
> way, do feel free to get in touch.
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> Get the hand-book for every CMake user: Professional CMake: A Practical
> Guide <https://crascit.com/professional-cmake/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/592a99c7/attachment-0001.html>

From tjwrona1992 at gmail.com  Tue Feb 19 10:37:17 2019
From: tjwrona1992 at gmail.com (Timothy Wrona)
Date: Tue, 19 Feb 2019 10:37:17 -0500
Subject: [CMake] [cmake-developers] Using CMake as a package manager vs
 using a dedicated package management tool (like Conan)
In-Reply-To: <CAGrOMv2k4jk-z=Yfqzb-_KGUtOOfstUt5Kkz72UBORpdipXhtA@mail.gmail.com>
References: <CAGrOMv0tEJuy-PVS7ZYwLXY+5WXcaLoHsY6mWgy7jcSoOpzBiw@mail.gmail.com>
 <CA+dygYmKa1ACx-8B=mY889kTsidYE40Fk=zNN-1zAfpJZaWsVw@mail.gmail.com>
 <CAGrOMv2k4jk-z=Yfqzb-_KGUtOOfstUt5Kkz72UBORpdipXhtA@mail.gmail.com>
Message-ID: <CAGrOMv0XAfWzxr37B6iswgQehZ=6RXZ+=t6ZnuALvsfTnKyisQ@mail.gmail.com>

Correction:

*I haven't tried this yet, but I am hoping it will work well* - Pull Put my
sub-projects (my own custom libraries) into their own independent git repos
and pull them into my main project using "FetchContent". Then when I run
"FetchContent" it will checkout the sub-projects and I will have all of the
source code available. I am hoping if I do this any changes I make to the
sub-projects can easily be committed and pushed back to their own
independent repositories.

On Tue, Feb 19, 2019 at 10:33 AM Timothy Wrona <tjwrona1992 at gmail.com>
wrote:

> Hi Craig,
>
> Thank you for the detailed description!
>
> To answer some of your questions:
>
>    - This project will not be incorporated into a Linux distribution,
>    however I would like to keep it cross platform and it should work on
>    Windows, Mac, and Linux.
>    - All of the pieces of the project that I am writing myself are using
>    CMake, but I do have some dependencies on external libs such as
>    "googletest" and "boost". Conan does seem to make using these external
>    dependencies very simple - especially since I am using MinGW to do my
>    compilation and "googletest" doesn't seem to compile out of the box on
>    MinGW without passing specific flags to the compiler. With Conan I get a
>    pre-compiled binary so it just works out of the box.
>    - At the current time, this project does not have many dependencies,
>    although it will likely grow quite large. I don't believe the external 3rd
>    party dependencies will need to update frequently, but all of the libraries
>    I am writing for the project will likely change quite a bit throughout
>    working on the project. I would also like to be able to compile these
>    libraries independently for reuse in other projects.
>    - I intend to support as many platforms/compilers as possible, I am
>    currently using Qt as my dev environment which allows me to
>    install/configure multiple compilers and try builds with each one - this
>    way I can at least do a build with both MinGW and msvc very quickly.
>    - I would like to support tools like sanitizers and code refactoring
>    tools at least within my own libraries (not necessarily with any of the 3rd
>    party libs)
>    - I would like past releases to be repeatable/rebuildable as much as
>    possible, although when the compiler is upgraded it is understandable that
>    past versions may have issues. I don't have much understanding of CI
>    systems at this point and it is something I have been trying to become more
>    familiar with. I'd like to avoid having multiple versions of the same
>    dependency, although I don't think having two versions of "googletest" for
>    two separate sub-projects that don't depend on each other would cause any
>    issues.
>       - I imagine Conan would make past releases more repeatable since
>       you can fetch binary packages instead of needing to rebuild from source and
>       package versions are always explicit.
>
> I am currently the only developer working on the project, but I would
> still like to find the most efficient method of managing packages for my
> particular situation since it will likely save me a lot of pain down the
> road if I get it right up-front. This project is in the situation where I
> have a set of different sub-projects (libraries) that all need to be able
> to be compiled independently for re-use, but I have a main project that
> will use them all. All of these projects have their own dependencies (some
> of them 3rd party, some of them written by me). The 3rd party libs will
> likely rarely change, but the ones written by me may change quite
> frequently.
>
> This is an approach I was thinking about taking:
>
>    - *So far I have tried this and it is working well* - Manage 3rd party
>    libs with Conan, since I don't need to see the source and it's quite
>    convenient to not need to recompile them this seems to work pretty well.
>    Using "FetchContent" on 3rd party libs and then attempting to compile them
>    yourself can sometimes be tricky (for example "googletest" requires special
>    compiler flags to be compiled with MinGW.) It also ensures that if two
>    projects ask for the same version of a dependency I get only one copy even
>    if the projects are built entirely independent of each other.
>    - *I haven't tried this yet, but I am hoping it will work well* - Pull
>    my sub-projects (my own custom libraries) into their own independent git
>    repos and pull them into my main project using "FetchContent". Then when I
>    run "FetchContent" it will checkout the sub-projects and I will have all of
>    the source code available. I am hoping if I do this any changes I make to
>    the sub-projects can easily be committed and pushed back to their own
>    independent repositories.
>    - The alternative to this would be to put my own sub-projects into
>       their own Conan packages and use Conan to get them from the main project.
>       But I am thinking since they will change frequently, "FetchContent" may be
>       a better fit for this scenario.
>       - Maybe when the sub-project libraries reach a mature and stable
>       release they should be packaged into Conan and fetched in the main project
>       from Conan at that point?
>
> Let me know what you think! :)
>
>
> On Tue, Feb 19, 2019 at 5:56 AM Craig Scott <craig.scott at crascit.com>
> wrote:
>
>>
>>
>> On Tue, Feb 19, 2019 at 12:46 PM Timothy Wrona <tjwrona1992 at gmail.com>
>> wrote:
>>
>>> I have been working on a new C++ project and I am trying to decide
>>> whether I should use CMake as my package management system or if I should
>>> use a dedicated package management tool such as Conan.
>>>
>>> For more information on Conan see: https://conan.io/
>>>
>>> I am trying to understand the main difference between using Conan to
>>> manage dependencies vs using CMakes "FetchContent" module. Are there any
>>> compelling reasons to prefer something like Conan?
>>>
>>
>> Excellent question, one that I think deserves a more detailed answer than
>> I can provide here, but I'll try to hit the main points as I see them.
>>
>> Personally, I think there is no "right answer" or "one size fits all"
>> when it comes to package management for a CMake project. What works well
>> for one situation, person or project may not be as convenient or suitable
>> for another. There are competing needs and views, some of which are
>> personal preferences, others are hard requirements from things like OS
>> distribution policies for packaging. Even just the maturity of a project
>> can have a big influence on how developers may prefer to handle its
>> dependencies and handle it as a dependency of other projects.
>>
>> The key thing for me is that the developer should ideally have choices
>> when it comes to this area. If a project hard-codes that its dependencies
>> must come from a particular provider (whether that be Conan, Hunter, vcpkg
>> or some other system), this might not be compatible with what the
>> developer's situation allows. You would need to weigh up whether it makes
>> sense to lock the developer into a particular package manager if they want
>> to use your project or not. An inappropriate choice here can mean lower
>> adoption of the project as some may reject it for consideration based on
>> this point alone.
>>
>> If instead a project relies only on find_package() to find its
>> dependencies, then it is up to the developer to ensure they are all
>> available. This could be done using whatever package manager the developer
>> finds convenient, or they could build the dependency projects from source
>> individually or they might set up a superbuild parent project that builds
>> the dependencies in the required order and makes dependees available to
>> dependers. This gives good flexibility at the cost of more responsibility
>> on the developer than perhaps some would want (again, it will be highly
>> situation-dependent).
>>
>> A drawback with find_package() is that it assumes you actually have a
>> packageable project. For a variety of reasons, this may not be the case.
>> Consider a large, complex project in its early stages and where multiple
>> teams are working on different subprojects which all get combined into some
>> larger whole. Each of the subprojects may need to be able to build on their
>> own with their own smaller subset of dependencies, but they also need to be
>> able to be incorporated into a larger build (think of different teams
>> working on core toolkits, rendering engines, different algorithm
>> strategies, multiple GUI applications, backend components, etc). No-one may
>> know yet how it should get packaged up and everyone might be focused on
>> just getting a minimal viable prototype up and running as a technical
>> demonstrator. For a case like that, neither find_package() nor a package
>> manager really fits the workflow. In this situation though, FetchContent is
>> a perfect fit, since it doesn't require any packaging to already be in
>> place, it needs no external tools other than CMake and it gives each
>> project precise control over its dependencies down to the individual commit
>> to bring in for each one.
>>
>> With the above in mind, perhaps the following few questions may be
>> helpful in clarifying what your constraints are and maybe steering you more
>> toward one way or the other:
>>
>>    - Will the project be incorporated into a Linux distribution at some
>>    point (not just be installed on Linux, but be part of the actual Linux
>>    distribution as provided by its own native package manager)? If so, I would
>>    expect this would pretty much eliminate using any package manager and
>>    instead require that you use find_package() to find all dependencies.
>>    - Are any of the dependencies of the project using a build system
>>    other than CMake? If so, they tend to take a bit more work to incorporate
>>    into a build via ExternalProject or FetchContent. If you can assume the
>>    developer provides those somehow, bringing them in by find_package() shifts
>>    responsibility for building them from the project to the developer (or
>>    whatever package manager they choose to use). This might be anywhere from
>>    entirely appropriate to entirely problematic depending on who your intended
>>    audience is.
>>    - How many dependencies does the project have and what is the
>>    maturity of each one? Will the project need to update any of those
>>    dependencies often (are they also being actively developed, do you need to
>>    follow recent work in them)? What will be the impact on developers working
>>    on the project when these dependencies need to be updated (how easy is it
>>    for them to update, what assumptions are you making about their development
>>    environment and tools)?
>>    - What breadth of platforms, compilers and CMake generators do you
>>    want to support? The bigger this set, the more it may drive you towards
>>    building dependencies from source rather than relying on having pre-built
>>    packages available to you.
>>    - Do you want developers to be able to use tools like sanitizers,
>>    perform code refactoring across projects or have source code visibility
>>    into dependencies within their IDE tools? FetchContent supports all of
>>    these requirements quite naturally, but doing so for the other methods it
>>    may be more difficult.
>>    - How will you manage repeatability of building past releases? Will
>>    you be able to build a year old release again if you update a build slave?
>>    In particular, what assumptions are you making about a CI system's build
>>    slaves and what dependencies they have installed (can you have multiple
>>    versions of any given dependency available at once, whether that be at a
>>    known path or via whatever package manager(s) you choose to use)?
>>
>>
>> On a side note, this is an area I'm increasingly thinking about these
>> days (I'm the author of the FetchContent module). I'm interested in hearing
>> peoples' views on dependency management and building an understanding of
>> what works for people and what doesn't. If you want to send feedback my
>> way, do feel free to get in touch.
>>
>> --
>> Craig Scott
>> Melbourne, Australia
>> https://crascit.com
>>
>> Get the hand-book for every CMake user: Professional CMake: A Practical
>> Guide <https://crascit.com/professional-cmake/>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/51aa95c2/attachment-0001.html>

From dev at thiagocrepaldi.com  Tue Feb 19 12:11:16 2019
From: dev at thiagocrepaldi.com (Thiago Crepaldi)
Date: Tue, 19 Feb 2019 09:11:16 -0800
Subject: [CMake] Problems with EnternalProjectAdd
In-Reply-To: <8470741e-db47-9e9f-7c1e-a4bc044660de@gmx.at>
References: <30266687-ad23-bcf3-7b82-6b152ef43968@gmx.at>
 <2424E81C-52C1-45FA-900F-8AEB2877B8E7@gmail.com>
 <8470741e-db47-9e9f-7c1e-a4bc044660de@gmx.at>
Message-ID: <CAGrNNLz1TzH+gSYtSpHuToBg-N9woodC2YZmiXsPOpc=K=6z-Q@mail.gmail.com>

try using
SOURCE_DIR = ${CMAKE_BINARY_DIR}/freetype/src/freetype
CONFIGURE_COMMAND = ./autgen.sh && ./configure
BUILD_COMMAND = make

It should git clone into SOURCE_DIR, configure the source by running
CONFIGURE_COMMAND and build it using BUILD_COMMAND, You may need
INSTALL_COMMAND = "" if you dont want to make install it


On Mon, Feb 18, 2019 at 9:51 PM Workbench at gmx.at <workbench at gmx.at> wrote:

> I played around a bit a now have the following:
>
> set(BUILD_ENV "${CMAKE_BINARY_DIR}/build_env" CACHE STRING INTERNAL)
> set(LIBRARY_DIR "${CMAKE_BINARY_DIR}/lib" CACHE STRING INTERNAL)
>
>      ExternalProject_Add(
>          freetype
>          PREFIX "${BUILD_ENV}/freetype"
>          GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
>          GIT_TAG 64bit
>          BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype &&
> ./autgen.sh && ./configure && make"
>          LOG_DOWNLOAD ON
>          LOG_INSTALL ON
>          LOG_CONFIGURE ON
>          LOG_BUILD ON
>          LOG_TEST ON
>          LOG_INSTALL ON
>          )
>
> The logs are telling me: CMake Error: The source directory
> "/home/stuv/data/projects/programming/bsUltimate/build/build_env/freetype/src/freetype"
>
> does not appear to contain CMakeLists.txt.
>
> Isn't the BUILD_COMMAND there if there is no CMakeLists.txt file
> available for building ? not many project provide cmake build files....
>
>
> best regards!
>
>
>
>
>
>
> On 19.02.19 06:43, Michael Ellery wrote:
> > CMAKE_BUILD_DIR is not a standard variable (did you mean
> CMAKE_BINARY_DIR ?) - and the error seems to indicate that the variable is
> indeed empty so it tries to create the project directory at the root level.
> >
> > -Mike
> >
> >> On Feb 18, 2019, at 8:58 PM, Workbench at gmx.at <workbench at gmx.at> wrote:
> >>
> >> Hi again,
> >>
> >> i try to install my dependencies with ExternalProjectAdd but it gives
> me troubles... what's wrong with
> >>
> >>
> >>      ExternalProject_Add(
> >>          freetype
> >>          PREFIX "${CMAKE_BUILD_DIR}/freetype"
> >>          GIT_REPOSITORY "
> https://github.com/brooklynpacket/freetype2.git"
> >>          GIT_TAG 64bit
> >>          BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype &&
> ./autgen.sh && ./configure && make"
> >>          LOG_DOWNLOAD ON
> >>          LOG_INSTALL ON
> >>          LOG_CONFIGURE ON
> >>          LOG_BUILD ON
> >>          LOG_TEST ON
> >>          LOG_INSTALL ON
> >>          )
> >>
> >> best regards!
> >>
> >> --
> >>
> >> 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:
> >> https://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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Thiago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/4934efd4/attachment.html>

From mellery451 at gmail.com  Tue Feb 19 12:11:56 2019
From: mellery451 at gmail.com (Michael Ellery)
Date: Tue, 19 Feb 2019 09:11:56 -0800
Subject: [CMake] Problems with EnternalProjectAdd
In-Reply-To: <152aa9fb-6d9f-1774-61a3-6b92f21e029f@gmx.at>
References: <30266687-ad23-bcf3-7b82-6b152ef43968@gmx.at>
 <2424E81C-52C1-45FA-900F-8AEB2877B8E7@gmail.com>
 <8470741e-db47-9e9f-7c1e-a4bc044660de@gmx.at>
 <C376B051-2BBD-46A4-A69B-B9CA102F8F3E@gmail.com>
 <60e388f1-d336-1aa0-d438-81cbad04ef35@gmx.at>
 <152aa9fb-6d9f-1774-61a3-6b92f21e029f@gmx.at>
Message-ID: <4B0307DF-86A8-439A-A849-B8AEFCA334DC@gmail.com>

Here?s a complete example that works on my system - maybe you can tweak it to your liking:


cmake_minimum_required (VERSION 3.9.0)
include (ExternalProject)
project (simple_ep)
set(BUILD_ENV "${CMAKE_BINARY_DIR}/build_env" CACHE STRING INTERNAL)
ExternalProject_Add(
  freetype
  PREFIX "${BUILD_ENV}/freetype"
  GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
  GIT_TAG 64bit
  BUILD_IN_SOURCE true
  CONFIGURE_COMMAND
    ./autogen.sh
    COMMAND
    ./configure
  BUILD_COMMAND
    make
  TEST_COMMAND ""
  INSTALL_COMMAND ""
  LOG_DOWNLOAD ON
  LOG_INSTALL ON
  LOG_CONFIGURE ON
  LOG_BUILD ON
  LOG_TEST ON
  LOG_INSTALL ON
)

add_library (ft_lib STATIC IMPORTED GLOBAL)
ExternalProject_Get_Property (freetype SOURCE_DIR)
set_target_properties (ft_lib PROPERTIES
  IMPORTED_LOCATION
    ${SOURCE_DIR}/objs/.libs/libfreetype.a)
add_dependencies (ft_lib freetype)
add_executable (app main.cpp)
target_link_libraries(app ft_lib)


-Mike

> On Feb 18, 2019, at 10:25 PM, Workbench at gmx.at <workbench at gmx.at> wrote:
> 
> Can't i somehow output the pwd ??
> 
> best regards!
> 
> On 19.02.19 07:04, Workbench at gmx.at wrote:
>> Now i'm getting:
>> 
>>  Command failed: No such file or directory
>> 
>>    'cd /home/stuv/data/projects/programming/bsUltimate/build/build_env/freetype/src/freetype && ./autogen.sh && ./configure && make'
>> 
>> but when i go to my bsUltimate path and type that command it works...
>> 
>> 
>> 
>> best regards!
>> 
>> On 19.02.19 06:57, Romain LEGUAY wrote:
>>> Hi,
>>> 
>>> I think you need to set the variable CONFIGURE_COMMAND to empty like this:
>>> 
>>>> ExternalProject_Add(
>>>>         freetype
>>>>         PREFIX "${BUILD_ENV}/freetype"
>>>>         GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
>>>>         GIT_TAG 64bit
>>>          CONFIGURE_COMMAND ""
>>>>         BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype && ./autgen.sh && ./configure && make"
>>>>         LOG_DOWNLOAD ON
>>>>         LOG_INSTALL ON
>>>>         LOG_CONFIGURE ON
>>>>         LOG_BUILD ON
>>>>         LOG_TEST ON
>>>>         LOG_INSTALL ON
>>>>         )
>>> 
>>> Envoy? de mon iPad
>>> 
>>> Le 19 f?vr. 2019 ? 06:51, Workbench at gmx.at <workbench at gmx.at> a ?crit :
>>> 
>>>> I played around a bit a now have the following:
>>>> 
>>>> set(BUILD_ENV "${CMAKE_BINARY_DIR}/build_env" CACHE STRING INTERNAL)
>>>> set(LIBRARY_DIR "${CMAKE_BINARY_DIR}/lib" CACHE STRING INTERNAL)
>>>> 
>>>>     ExternalProject_Add(
>>>>         freetype
>>>>         PREFIX "${BUILD_ENV}/freetype"
>>>>         GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
>>>>         GIT_TAG 64bit
>>>>         BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype && ./autgen.sh && ./configure && make"
>>>>         LOG_DOWNLOAD ON
>>>>         LOG_INSTALL ON
>>>>         LOG_CONFIGURE ON
>>>>         LOG_BUILD ON
>>>>         LOG_TEST ON
>>>>         LOG_INSTALL ON
>>>>         )
>>>> 
>>>> The logs are telling me: CMake Error: The source directory "/home/stuv/data/projects/programming/bsUltimate/build/build_env/freetype/src/freetype" does not appear to contain CMakeLists.txt.
>>>> 
>>>> Isn't the BUILD_COMMAND there if there is no CMakeLists.txt file available for building ? not many project provide cmake build files....
>>>> 
>>>> 
>>>> best regards!
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 19.02.19 06:43, Michael Ellery wrote:
>>>>> CMAKE_BUILD_DIR is not a standard variable (did you mean CMAKE_BINARY_DIR ?) - and the error seems to indicate that the variable is indeed empty so it tries to create the project directory at the root level.
>>>>> 
>>>>> -Mike
>>>>> 
>>>>>> On Feb 18, 2019, at 8:58 PM, Workbench at gmx.at <workbench at gmx.at> wrote:
>>>>>> 
>>>>>> Hi again,
>>>>>> 
>>>>>> i try to install my dependencies with ExternalProjectAdd but it gives me troubles... what's wrong with
>>>>>> 
>>>>>> 
>>>>>>     ExternalProject_Add(
>>>>>>         freetype
>>>>>>         PREFIX "${CMAKE_BUILD_DIR}/freetype"
>>>>>>         GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git"
>>>>>>         GIT_TAG 64bit
>>>>>>         BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype && ./autgen.sh && ./configure && make"
>>>>>>         LOG_DOWNLOAD ON
>>>>>>         LOG_INSTALL ON
>>>>>>         LOG_CONFIGURE ON
>>>>>>         LOG_BUILD ON
>>>>>>         LOG_TEST ON
>>>>>>         LOG_INSTALL ON
>>>>>>         )
>>>>>> 
>>>>>> best regards!
>>>>>> 
>>>>>> -- 
>>>>>> 
>>>>>> 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:
>>>>>> https://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:
>>>> https://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:
> https://cmake.org/mailman/listinfo/cmake


From craig.scott at crascit.com  Tue Feb 19 15:14:35 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Wed, 20 Feb 2019 07:14:35 +1100
Subject: [CMake] [cmake-developers] Using CMake as a package manager vs
 using a dedicated package management tool (like Conan)
In-Reply-To: <CAGrOMv2k4jk-z=Yfqzb-_KGUtOOfstUt5Kkz72UBORpdipXhtA@mail.gmail.com>
References: <CAGrOMv0tEJuy-PVS7ZYwLXY+5WXcaLoHsY6mWgy7jcSoOpzBiw@mail.gmail.com>
 <CA+dygYmKa1ACx-8B=mY889kTsidYE40Fk=zNN-1zAfpJZaWsVw@mail.gmail.com>
 <CAGrOMv2k4jk-z=Yfqzb-_KGUtOOfstUt5Kkz72UBORpdipXhtA@mail.gmail.com>
Message-ID: <CA+dygYkr2qiAunoMStTqacQvqKBDxaBndmyBGssBUvQjoeoXnQ@mail.gmail.com>

(dropping the cmake-developers list since this is really a user issue)


On Wed, Feb 20, 2019 at 2:34 AM Timothy Wrona <tjwrona1992 at gmail.com> wrote:

> Hi Craig,
>
> Thank you for the detailed description!
>
> To answer some of your questions:
>
>    - This project will not be incorporated into a Linux distribution,
>    however I would like to keep it cross platform and it should work on
>    Windows, Mac, and Linux.
>    - All of the pieces of the project that I am writing myself are using
>    CMake, but I do have some dependencies on external libs such as
>    "googletest" and "boost". Conan does seem to make using these external
>    dependencies very simple - especially since I am using MinGW to do my
>    compilation and "googletest" doesn't seem to compile out of the box on
>    MinGW without passing specific flags to the compiler. With Conan I get a
>    pre-compiled binary so it just works out of the box.
>    - At the current time, this project does not have many dependencies,
>    although it will likely grow quite large. I don't believe the external 3rd
>    party dependencies will need to update frequently, but all of the libraries
>    I am writing for the project will likely change quite a bit throughout
>    working on the project. I would also like to be able to compile these
>    libraries independently for reuse in other projects.
>    - I intend to support as many platforms/compilers as possible, I am
>    currently using Qt as my dev environment which allows me to
>    install/configure multiple compilers and try builds with each one - this
>    way I can at least do a build with both MinGW and msvc very quickly.
>    - I would like to support tools like sanitizers and code refactoring
>    tools at least within my own libraries (not necessarily with any of the 3rd
>    party libs)
>    - I would like past releases to be repeatable/rebuildable as much as
>    possible, although when the compiler is upgraded it is understandable that
>    past versions may have issues. I don't have much understanding of CI
>    systems at this point and it is something I have been trying to become more
>    familiar with. I'd like to avoid having multiple versions of the same
>    dependency, although I don't think having two versions of "googletest" for
>    two separate sub-projects that don't depend on each other would cause any
>    issues.
>       - I imagine Conan would make past releases more repeatable since
>       you can fetch binary packages instead of needing to rebuild from source and
>       package versions are always explicit.
>
> I am currently the only developer working on the project, but I would
> still like to find the most efficient method of managing packages for my
> particular situation since it will likely save me a lot of pain down the
> road if I get it right up-front. This project is in the situation where I
> have a set of different sub-projects (libraries) that all need to be able
> to be compiled independently for re-use, but I have a main project that
> will use them all. All of these projects have their own dependencies (some
> of them 3rd party, some of them written by me). The 3rd party libs will
> likely rarely change, but the ones written by me may change quite
> frequently.
>
> This is an approach I was thinking about taking:
>
>    - *So far I have tried this and it is working well* - Manage 3rd party
>    libs with Conan, since I don't need to see the source and it's quite
>    convenient to not need to recompile them this seems to work pretty well.
>    Using "FetchContent" on 3rd party libs and then attempting to compile them
>    yourself can sometimes be tricky (for example "googletest" requires special
>    compiler flags to be compiled with MinGW.) It also ensures that if two
>    projects ask for the same version of a dependency I get only one copy even
>    if the projects are built entirely independent of each other.
>    - *I haven't tried this yet, but I am hoping it will work well* - Put
>    my sub-projects (my own custom libraries) into their own independent git
>    repos and pull them into my main project using "FetchContent". Then when I
>    run "FetchContent" it will checkout the sub-projects and I will have all of
>    the source code available. I am hoping if I do this any changes I make to
>    the sub-projects can easily be committed and pushed back to their own
>    independent repositories.
>    - The alternative to this would be to put my own sub-projects into
>       their own Conan packages and use Conan to get them from the main project.
>       But I am thinking since they will change frequently, "FetchContent" may be
>       a better fit for this scenario.
>       - Maybe when the sub-project libraries reach a mature and stable
>       release they should be packaged into Conan and fetched in the main project
>       from Conan at that point?
>
> Let me know what you think! :)
>

Sounds like you are making progress exploring things already, you'll need
to make your own evaluations about which approach will work best for you.

As a data point, in my day job, most of the time I'm working with a project
hierarchy that spans about 40+ dependencies, most of which are internal
projects that can all be built standalone or as part of a larger whole.
Some are small and relatively trivial, others are much larger and have
varying age with the associated quirks that come with that. Most come from
git but some come from svn and a small number from release tarballs. Some
have code generators that also produce CMakeLists.txt files that other
parts of the build need to consume (see this stack overflow Q&A
<https://stackoverflow.com/q/36084785/1938798> for more on that). We use
both GoogleTest and Boost, plus various other third party projects (OpenSSL
is probably the one that gives us the most pain). We build for Linux,
Windows, Mac, Solaris, iOS and Android. We support our devs building with
Make, Ninja, Xcode or Visual Studio (we don't use MinGW). Many of the
projects are actively undergoing change across multiple teams and people,
most of whom don't have an interest in learning about CMake and build
systems and just want to focus on coding. The flexibility and robustness
that FetchContent has given us has been a critical factor in being able to
work effectively and efficiently. That and ccache. ;) We don't use a
package manager other than letting the OS provide some common things on a
few platforms. For some larger dependencies (e.g. NDK, Qt) we rely on
having pre-built packages installed at predictable locations and accept
that we will have to maintain these on our build slaves, although this is
an area that is still evolving.

I recently posted
<https://gitlab.kitware.com/cmake/cmake/issues/18831#note_509194> how I'm
currently working on bringing Boost into our build via a FetchContent-based
mechanism. That is still somewhat of a work-in-progress and has holes for
multi-config generators (i.e. Visual Studio and Xcode), but they don't look
insurmountable if those are important to you. It's by no means the only
approach, but it's a starting point if you want to explore it (once Boost
completes its move to CMake, I hope to be able to drop this and just bring
Boost into the build via add_subdirectory() like most of our other
dependencies).



>
>
> On Tue, Feb 19, 2019 at 5:56 AM Craig Scott <craig.scott at crascit.com>
> wrote:
>
>>
>>
>> On Tue, Feb 19, 2019 at 12:46 PM Timothy Wrona <tjwrona1992 at gmail.com>
>> wrote:
>>
>>> I have been working on a new C++ project and I am trying to decide
>>> whether I should use CMake as my package management system or if I should
>>> use a dedicated package management tool such as Conan.
>>>
>>> For more information on Conan see: https://conan.io/
>>>
>>> I am trying to understand the main difference between using Conan to
>>> manage dependencies vs using CMakes "FetchContent" module. Are there any
>>> compelling reasons to prefer something like Conan?
>>>
>>
>> Excellent question, one that I think deserves a more detailed answer than
>> I can provide here, but I'll try to hit the main points as I see them.
>>
>> Personally, I think there is no "right answer" or "one size fits all"
>> when it comes to package management for a CMake project. What works well
>> for one situation, person or project may not be as convenient or suitable
>> for another. There are competing needs and views, some of which are
>> personal preferences, others are hard requirements from things like OS
>> distribution policies for packaging. Even just the maturity of a project
>> can have a big influence on how developers may prefer to handle its
>> dependencies and handle it as a dependency of other projects.
>>
>> The key thing for me is that the developer should ideally have choices
>> when it comes to this area. If a project hard-codes that its dependencies
>> must come from a particular provider (whether that be Conan, Hunter, vcpkg
>> or some other system), this might not be compatible with what the
>> developer's situation allows. You would need to weigh up whether it makes
>> sense to lock the developer into a particular package manager if they want
>> to use your project or not. An inappropriate choice here can mean lower
>> adoption of the project as some may reject it for consideration based on
>> this point alone.
>>
>> If instead a project relies only on find_package() to find its
>> dependencies, then it is up to the developer to ensure they are all
>> available. This could be done using whatever package manager the developer
>> finds convenient, or they could build the dependency projects from source
>> individually or they might set up a superbuild parent project that builds
>> the dependencies in the required order and makes dependees available to
>> dependers. This gives good flexibility at the cost of more responsibility
>> on the developer than perhaps some would want (again, it will be highly
>> situation-dependent).
>>
>> A drawback with find_package() is that it assumes you actually have a
>> packageable project. For a variety of reasons, this may not be the case.
>> Consider a large, complex project in its early stages and where multiple
>> teams are working on different subprojects which all get combined into some
>> larger whole. Each of the subprojects may need to be able to build on their
>> own with their own smaller subset of dependencies, but they also need to be
>> able to be incorporated into a larger build (think of different teams
>> working on core toolkits, rendering engines, different algorithm
>> strategies, multiple GUI applications, backend components, etc). No-one may
>> know yet how it should get packaged up and everyone might be focused on
>> just getting a minimal viable prototype up and running as a technical
>> demonstrator. For a case like that, neither find_package() nor a package
>> manager really fits the workflow. In this situation though, FetchContent is
>> a perfect fit, since it doesn't require any packaging to already be in
>> place, it needs no external tools other than CMake and it gives each
>> project precise control over its dependencies down to the individual commit
>> to bring in for each one.
>>
>> With the above in mind, perhaps the following few questions may be
>> helpful in clarifying what your constraints are and maybe steering you more
>> toward one way or the other:
>>
>>    - Will the project be incorporated into a Linux distribution at some
>>    point (not just be installed on Linux, but be part of the actual Linux
>>    distribution as provided by its own native package manager)? If so, I would
>>    expect this would pretty much eliminate using any package manager and
>>    instead require that you use find_package() to find all dependencies.
>>    - Are any of the dependencies of the project using a build system
>>    other than CMake? If so, they tend to take a bit more work to incorporate
>>    into a build via ExternalProject or FetchContent. If you can assume the
>>    developer provides those somehow, bringing them in by find_package() shifts
>>    responsibility for building them from the project to the developer (or
>>    whatever package manager they choose to use). This might be anywhere from
>>    entirely appropriate to entirely problematic depending on who your intended
>>    audience is.
>>    - How many dependencies does the project have and what is the
>>    maturity of each one? Will the project need to update any of those
>>    dependencies often (are they also being actively developed, do you need to
>>    follow recent work in them)? What will be the impact on developers working
>>    on the project when these dependencies need to be updated (how easy is it
>>    for them to update, what assumptions are you making about their development
>>    environment and tools)?
>>    - What breadth of platforms, compilers and CMake generators do you
>>    want to support? The bigger this set, the more it may drive you towards
>>    building dependencies from source rather than relying on having pre-built
>>    packages available to you.
>>    - Do you want developers to be able to use tools like sanitizers,
>>    perform code refactoring across projects or have source code visibility
>>    into dependencies within their IDE tools? FetchContent supports all of
>>    these requirements quite naturally, but doing so for the other methods it
>>    may be more difficult.
>>    - How will you manage repeatability of building past releases? Will
>>    you be able to build a year old release again if you update a build slave?
>>    In particular, what assumptions are you making about a CI system's build
>>    slaves and what dependencies they have installed (can you have multiple
>>    versions of any given dependency available at once, whether that be at a
>>    known path or via whatever package manager(s) you choose to use)?
>>
>>
>> On a side note, this is an area I'm increasingly thinking about these
>> days (I'm the author of the FetchContent module). I'm interested in hearing
>> peoples' views on dependency management and building an understanding of
>> what works for people and what doesn't. If you want to send feedback my
>> way, do feel free to get in touch.
>>
>
-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190220/a885fa73/attachment-0001.html>

From mike.jackson at bluequartz.net  Tue Feb 19 17:05:17 2019
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Tue, 19 Feb 2019 17:05:17 -0500
Subject: [CMake] CMake Dependence on C: drive?
Message-ID: <796A6AC9-9B1F-444F-81D6-7EE5299AB3A5@bluequartz.net>

Currently using CMake 3.13.3 on Windows 10. I have ?installed? cmake through the .zip download and placed it in E:\DREAM3D_SDK\ cmake-3.13.3-win64-x64. 

 

If I now try to use that cmake to configure my source codes I get very strange errors (It cannot parse a simple project command) and then complains that it cannot find a CMake_MAKE_PROGRAM matching the ?-G Ninja?.

 

I then went back to using the same version of CMake, but placed on the C:/DREAM3D_SDK/cmake-3.13.3-win64-x64 and now everything works as in the past, no problems. I have a .bat file that sets up my environment with needed paths and such. The ONLY difference between the 2 invocations was that I changed the path to reflect the alternate location of CMake. I can have 2 difference command prompts open based on this difference and one works and one does not. 


Was/Is there a known limitation where CMake _must_ be run from the C: drive?

 

--

Michael Jackson | Owner, President

      BlueQuartz Software

[e] mike.jackson at bluequartz.net

[w] www.bluequartz.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/be81f53d/attachment.html>

From calebwherry at gmail.com  Tue Feb 19 19:21:22 2019
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Tue, 19 Feb 2019 19:21:22 -0500
Subject: [CMake] CMake Dependence on C: drive?
In-Reply-To: <796A6AC9-9B1F-444F-81D6-7EE5299AB3A5@bluequartz.net>
References: <796A6AC9-9B1F-444F-81D6-7EE5299AB3A5@bluequartz.net>
Message-ID: <CAJxY6XoxWgYOhyfc1khkL9-Q1dt7P-q+cz85rFa4woA_BR8Xmw@mail.gmail.com>

Seems strange. Just yesterday I pulled down 3.13.4 and had no issues. I
check cmake into our repo so it gets invoked on an assortment of different
drives. I do the same thing you do and just change our bat config file to
point to the new cmake binary. Never had any issues.

I am running on Win7 but colleagues use Win10 and have not had any issues
either.

All that to say: shouldn?t be an issue.

-Caleb

On Tue, Feb 19, 2019 at 5:05 PM Michael Jackson <mike.jackson at bluequartz.net>
wrote:

> Currently using CMake 3.13.3 on Windows 10. I have ?installed? cmake
> through the .zip download and placed it in E:\DREAM3D_SDK\ cmake-3.13.3-win64-x64.
>
>
>
>
> If I now try to use that cmake to configure my source codes I get very
> strange errors (It cannot parse a simple project command) and then
> complains that it cannot find a CMake_MAKE_PROGRAM matching the ?-G Ninja?.
>
>
>
> I then went back to using the same version of CMake, but placed on the
> C:/DREAM3D_SDK/cmake-3.13.3-win64-x64 and now everything works as in the
> past, no problems. I have a .bat file that sets up my environment with
> needed paths and such. The ONLY difference between the 2 invocations was
> that I changed the path to reflect the alternate location of CMake. I can
> have 2 difference command prompts open based on this difference and one
> works and one does not.
>
>
> Was/Is there a known limitation where CMake _*must*_ be run from the C:
> drive?
>
>
>
> --
>
> Michael Jackson | Owner, President
>
>       BlueQuartz Software
>
> [e] mike.jackson at bluequartz.net
>
> [w] www.bluequartz.net
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 
Sent from my iPhone SE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/4e1b21d4/attachment.html>

From kuba at mareimbrium.org  Tue Feb 19 21:03:54 2019
From: kuba at mareimbrium.org (Kuba Ober)
Date: Tue, 19 Feb 2019 21:03:54 -0500
Subject: [CMake] Remove folders created by install
In-Reply-To: <1bcb702d-9d2f-5549-2569-bc3de84600cd@gmail.com>
References: <1bcb702d-9d2f-5549-2569-bc3de84600cd@gmail.com>
Message-ID: <E8B5F35D-47B7-4B12-BEAC-B23C118FCEC1@mareimbrium.org>

Use something to read the manifest, extract paths from it, remove the duplicates, then iterate them, and remove the ones that are empty. It?d be a bad idea probably to remove ones that are not empty.

Cheers, Kuba

> 16 feb. 2019 kl. 09:47 skrev Felix Crazzolara <felix.crazzolara at gmail.com>:
> 
> Hi everyone
> 
> For my smaller projects I'd like to have 'uninstall' functionality. To remove installed files I can call:
> 
> xargs rm < build/install_manifest.txt
> 
> Unfortunately this won't delete any folders generated by the installation. Is there a different file that keeps track of the created directories, or what is the recommended way to implement such functionality?
> 
> Example:
> Suppose that I install <project-name>_some_header.hpp in <prefix>/include/<project-name>/ using the command install(TARGETS <project-name> EXPORT <project-name>-targets ARCHIVE DESTINATION lib PUBLIC_HEADER DESTINATION include/<project-name>) then I want not only to remove <prefix>/include/<project-name>/<project-name>_some_header.hpp, but also the directory <prefix>/include/<project-name>/.
> 
> Cheers,
> 
> Felix Crazzolara
> 
> -- 
> 
> 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:
> https://cmake.org/mailman/listinfo/cmake

From tjwrona1992 at gmail.com  Tue Feb 19 23:32:31 2019
From: tjwrona1992 at gmail.com (Timothy Wrona)
Date: Tue, 19 Feb 2019 23:32:31 -0500
Subject: [CMake] Using FetchContent fails when two subprojects have a target
 with the same name
Message-ID: <CAGrOMv0KooGLuqE6fG8ycrszsAG1FvpGq3FisiiawFJ6u_bXMg@mail.gmail.com>

I am having an issue with using FetchContent to grab two subprojects that
both contain a "doxygen" target to build the documentation.

Both of these subprojects need to be able to be built independently and
when built on their own they compile fine (along with their documentation),
but when I pull them into one project using "FetchContent" I get an error
saying I can't define the "doxygen" target more than once.

I imagine this kind of issue would come up all of the time when using a
"superbuild" pattern. Is there a typical way of handling this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/5e1e35d8/attachment.html>

From tjwrona1992 at gmail.com  Tue Feb 19 23:36:16 2019
From: tjwrona1992 at gmail.com (Timothy Wrona)
Date: Tue, 19 Feb 2019 23:36:16 -0500
Subject: [CMake] Using FetchContent fails when two subprojects have a
 target with the same name
In-Reply-To: <CAGrOMv0KooGLuqE6fG8ycrszsAG1FvpGq3FisiiawFJ6u_bXMg@mail.gmail.com>
References: <CAGrOMv0KooGLuqE6fG8ycrszsAG1FvpGq3FisiiawFJ6u_bXMg@mail.gmail.com>
Message-ID: <CAGrOMv2_GOysvd9qryV28__wD3wOvi2B0t1roNnQ3k1+ztWzPA@mail.gmail.com>

(Included cmake-developers list as well in case this may have just been
something that should work that was overlooked with the FetchContent module)

On Tue, Feb 19, 2019 at 11:32 PM Timothy Wrona <tjwrona1992 at gmail.com>
wrote:

> I am having an issue with using FetchContent to grab two subprojects that
> both contain a "doxygen" target to build the documentation.
>
> Both of these subprojects need to be able to be built independently and
> when built on their own they compile fine (along with their documentation),
> but when I pull them into one project using "FetchContent" I get an error
> saying I can't define the "doxygen" target more than once.
>
> I imagine this kind of issue would come up all of the time when using a
> "superbuild" pattern. Is there a typical way of handling this?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190219/b94df1cb/attachment-0001.html>

From eric.noulard at gmail.com  Wed Feb 20 07:22:29 2019
From: eric.noulard at gmail.com (Eric Noulard)
Date: Wed, 20 Feb 2019 13:22:29 +0100
Subject: [CMake] Remove folders created by install
In-Reply-To: <1bcb702d-9d2f-5549-2569-bc3de84600cd@gmail.com>
References: <1bcb702d-9d2f-5549-2569-bc3de84600cd@gmail.com>
Message-ID: <CAPASGLqZKYv+ua+6i23yZxDUuTCjoBmC+BqBZOHvPbMfGWK1qQ@mail.gmail.com>

There are some possible solutions and reference here:
https://stackoverflow.com/questions/41471620/cmake-support-make-uninstall

Le sam. 16 f?vr. 2019 ? 15:48, Felix Crazzolara <felix.crazzolara at gmail.com>
a ?crit :

> Hi everyone
>
> For my smaller projects I'd like to have 'uninstall' functionality. To
> remove installed files I can call:
>
> xargs rm < build/install_manifest.txt
>
> Unfortunately this won't delete any folders generated by the
> installation. Is there a different file that keeps track of the created
> directories, or what is the recommended way to implement such
> functionality?
>
> Example:
> Suppose that I install <project-name>_some_header.hpp in
> <prefix>/include/<project-name>/ using the command install(TARGETS
> <project-name> EXPORT <project-name>-targets ARCHIVE DESTINATION lib
> PUBLIC_HEADER DESTINATION include/<project-name>) then I want not only
> to remove
> <prefix>/include/<project-name>/<project-name>_some_header.hpp, but also
> the directory <prefix>/include/<project-name>/.
>
> Cheers,
>
> Felix Crazzolara
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190220/0da10fbd/attachment.html>

From craig.scott at crascit.com  Wed Feb 20 08:22:35 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Thu, 21 Feb 2019 00:22:35 +1100
Subject: [CMake] [cmake-developers] Using FetchContent fails when two
 subprojects have a target with the same name
In-Reply-To: <CAGrOMv2_GOysvd9qryV28__wD3wOvi2B0t1roNnQ3k1+ztWzPA@mail.gmail.com>
References: <CAGrOMv0KooGLuqE6fG8ycrszsAG1FvpGq3FisiiawFJ6u_bXMg@mail.gmail.com>
 <CAGrOMv2_GOysvd9qryV28__wD3wOvi2B0t1roNnQ3k1+ztWzPA@mail.gmail.com>
Message-ID: <CA+dygY=rH=xhHRBvyRo4aoRx_9Pn1fsts9fFqe0As9CVzQ8e4w@mail.gmail.com>

On Wed, Feb 20, 2019 at 3:36 PM Timothy Wrona <tjwrona1992 at gmail.com> wrote:

> (Included cmake-developers list as well in case this may have just been
> something that should work that was overlooked with the FetchContent module)
>
> On Tue, Feb 19, 2019 at 11:32 PM Timothy Wrona <tjwrona1992 at gmail.com>
> wrote:
>
>> I am having an issue with using FetchContent to grab two subprojects that
>> both contain a "doxygen" target to build the documentation.
>>
>> Both of these subprojects need to be able to be built independently and
>> when built on their own they compile fine (along with their documentation),
>> but when I pull them into one project using "FetchContent" I get an error
>> saying I can't define the "doxygen" target more than once.
>>
>> I imagine this kind of issue would come up all of the time when using a
>> "superbuild" pattern. Is there a typical way of handling this?
>>
>
I thought this limitation was already mentioned in the FetchContent docs,
but it seems it isn't. If two different dependencies define the same global
target name, then they cannot be combined into the same build via
add_subdirectory(). CMake doesn't allow a target to be redefined (although
it does allow additional commands to be added to an existing custom
target). I'll try to add some docs to FetchContent to mention this
limitation, but they will not make it into the 3.14 release - the
limitation has always been there right from when FetchContent was first
introduced in 3.11.

A traditional superbuild that uses ExternalProject won't have a problem
with this because a subproject's own targets are not combined with targets
of other subprojects into a single build. Instead, the top level project
only sees the targets that ExternalProject itself creates. This is most
likely the best workaround if you are not able to modify the target names
used in the subprojects you want to combine.

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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190221/6b073562/attachment.html>

From lassi.niemisto at wapice.com  Wed Feb 20 08:33:16 2019
From: lassi.niemisto at wapice.com (=?iso-8859-1?Q?Lassi_Niemist=F6?=)
Date: Wed, 20 Feb 2019 13:33:16 +0000
Subject: [CMake] Mandatory export of a static library dependency
Message-ID: <AM6PR0302MB3269A3D50457C64EC89BFF94F87D0@AM6PR0302MB3269.eurprd03.prod.outlook.com>

Hello,

I use CMake 3.13RC1. My project produces, installs and exports a shared library target "fooshared". Some logical parts of "fooshared" are reused in an executable, so I have placed those sources into an internal static library target "barstatic". I have used target_link_libraries(fooshared barstatic) to make this work.

Problem: when I try to:
install(TARGETS fooshared DESTINATION <dest> EXPORT myexport)
install(EXPORT myexport DESTINATION <dest>)
..I get a whine about dependency to "barstatic" which is not in the export group "myexport".

I wouldn't like to export "barstatic" at all, it should remain under the hood. I tried to use target_link_libraries(fooshared PRIVATE barstatic) which cut the export chaining, but then symbols from "barstatic" were not available for users of "fooshared" anymore. So I worked around this by converting "barstatic" into an object library, but it feels ugly.

Why would CMake require exporting statically linked dependency targets among the targets that use them? Feels like a bug to me...unless someone can explain why :)

Regards,
-Lassi Niemist?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190220/e4d6bf72/attachment-0001.html>

From rjvbertin at gmail.com  Wed Feb 20 08:51:56 2019
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Wed, 20 Feb 2019 14:51:56 +0100
Subject: [CMake] CMAKE_AR/NM/RANLIB require full path?!
Message-ID: <1804749.OtAdDEy6tV@portia.local>

Hi,

I just got some build failures when changes to my build scripts led to configuring with -DCMAKE_AR=ar (RANLIB=ranlib, etc).

The documentation isn't explicit on what these parameters expect so I assumed that it should be fine to set them to a command name, as with CMAKE_<LANG>_COMPILER.

Wrong! CMake will apparently prepend CMAKE_BINARY_DIR to these commands.

If this is intentional, why isn't it documented in the CMAKE_AR (etc) description?

Thanks,

R.

From tjwrona1992 at gmail.com  Wed Feb 20 09:05:14 2019
From: tjwrona1992 at gmail.com (Timothy Wrona)
Date: Wed, 20 Feb 2019 09:05:14 -0500
Subject: [CMake] [cmake-developers] Using FetchContent fails when two
 subprojects have a target with the same name
In-Reply-To: <CA+dygY=rH=xhHRBvyRo4aoRx_9Pn1fsts9fFqe0As9CVzQ8e4w@mail.gmail.com>
References: <CAGrOMv0KooGLuqE6fG8ycrszsAG1FvpGq3FisiiawFJ6u_bXMg@mail.gmail.com>
 <CAGrOMv2_GOysvd9qryV28__wD3wOvi2B0t1roNnQ3k1+ztWzPA@mail.gmail.com>
 <CA+dygY=rH=xhHRBvyRo4aoRx_9Pn1fsts9fFqe0As9CVzQ8e4w@mail.gmail.com>
Message-ID: <CAGrOMv1=jNQkTEdJB-QW0wY3dYgAWMc7TGSyG8-F1QcxjiykSQ@mail.gmail.com>

Okay that makes sense. I will give ExternalProject_Add a try. I think it
would be very useful if FetchContent were able to support targets with the
same name and that would be a great feature to add (although it is
understandable if it is a language limitation).

I much prefer the simplicity of FetchContent :)

Thanks,
Tim

On Wed, Feb 20, 2019 at 8:22 AM Craig Scott <craig.scott at crascit.com> wrote:

>
>
> On Wed, Feb 20, 2019 at 3:36 PM Timothy Wrona <tjwrona1992 at gmail.com>
> wrote:
>
>> (Included cmake-developers list as well in case this may have just been
>> something that should work that was overlooked with the FetchContent module)
>>
>> On Tue, Feb 19, 2019 at 11:32 PM Timothy Wrona <tjwrona1992 at gmail.com>
>> wrote:
>>
>>> I am having an issue with using FetchContent to grab two subprojects
>>> that both contain a "doxygen" target to build the documentation.
>>>
>>> Both of these subprojects need to be able to be built independently and
>>> when built on their own they compile fine (along with their documentation),
>>> but when I pull them into one project using "FetchContent" I get an error
>>> saying I can't define the "doxygen" target more than once.
>>>
>>> I imagine this kind of issue would come up all of the time when using a
>>> "superbuild" pattern. Is there a typical way of handling this?
>>>
>>
> I thought this limitation was already mentioned in the FetchContent docs,
> but it seems it isn't. If two different dependencies define the same global
> target name, then they cannot be combined into the same build via
> add_subdirectory(). CMake doesn't allow a target to be redefined (although
> it does allow additional commands to be added to an existing custom
> target). I'll try to add some docs to FetchContent to mention this
> limitation, but they will not make it into the 3.14 release - the
> limitation has always been there right from when FetchContent was first
> introduced in 3.11.
>
> A traditional superbuild that uses ExternalProject won't have a problem
> with this because a subproject's own targets are not combined with targets
> of other subprojects into a single build. Instead, the top level project
> only sees the targets that ExternalProject itself creates. This is most
> likely the best workaround if you are not able to modify the target names
> used in the subprojects you want to combine.
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> Get the hand-book for every CMake user: Professional CMake: A Practical
> Guide <https://crascit.com/professional-cmake/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190220/e4b60ca6/attachment.html>

From mike.jackson at bluequartz.net  Wed Feb 20 09:14:00 2019
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Wed, 20 Feb 2019 09:14:00 -0500
Subject: [CMake] CMake Dependence on C: drive?
In-Reply-To: <CAJxY6XoxWgYOhyfc1khkL9-Q1dt7P-q+cz85rFa4woA_BR8Xmw@mail.gmail.com>
References: <796A6AC9-9B1F-444F-81D6-7EE5299AB3A5@bluequartz.net>
 <CAJxY6XoxWgYOhyfc1khkL9-Q1dt7P-q+cz85rFa4woA_BR8Xmw@mail.gmail.com>
Message-ID: <CAEqXkzdd7HzumfCDNbv5a+sOUKG=z4O+5ruJ+x2rqYMUq06BPg@mail.gmail.com>

Thanks for the sanity check. I'm not really sure what is going wrong then.
Not a big deal per se but would really like to figure out what the issue
is. Maybe something funky with my PATH variable. This is on Windows 10 x64.

--
Mike Jackson

On Tue, Feb 19, 2019 at 7:21 PM J. Caleb Wherry <calebwherry at gmail.com>
wrote:

> Seems strange. Just yesterday I pulled down 3.13.4 and had no issues. I
> check cmake into our repo so it gets invoked on an assortment of different
> drives. I do the same thing you do and just change our bat config file to
> point to the new cmake binary. Never had any issues.
>
> I am running on Win7 but colleagues use Win10 and have not had any issues
> either.
>
> All that to say: shouldn?t be an issue.
>
> -Caleb
>
> On Tue, Feb 19, 2019 at 5:05 PM Michael Jackson <
> mike.jackson at bluequartz.net> wrote:
>
>> Currently using CMake 3.13.3 on Windows 10. I have ?installed? cmake
>> through the .zip download and placed it in E:\DREAM3D_SDK\ cmake-3.13.3-win64-x64.
>>
>>
>>
>>
>> If I now try to use that cmake to configure my source codes I get very
>> strange errors (It cannot parse a simple project command) and then
>> complains that it cannot find a CMake_MAKE_PROGRAM matching the ?-G Ninja?.
>>
>>
>>
>> I then went back to using the same version of CMake, but placed on the
>> C:/DREAM3D_SDK/cmake-3.13.3-win64-x64 and now everything works as in the
>> past, no problems. I have a .bat file that sets up my environment with
>> needed paths and such. The ONLY difference between the 2 invocations was
>> that I changed the path to reflect the alternate location of CMake. I can
>> have 2 difference command prompts open based on this difference and one
>> works and one does not.
>>
>>
>> Was/Is there a known limitation where CMake _*must*_ be run from the C:
>> drive?
>>
>>
>>
>> --
>>
>> Michael Jackson | Owner, President
>>
>>       BlueQuartz Software
>>
>> [e] mike.jackson at bluequartz.net
>>
>> [w] www.bluequartz.net
>> --
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190220/c1203ba1/attachment.html>

From francis.giraldeau at gmail.com  Wed Feb 20 16:22:28 2019
From: francis.giraldeau at gmail.com (Francis Giraldeau)
Date: Wed, 20 Feb 2019 16:22:28 -0500
Subject: [CMake] Mixted C++/Fortran library on Windows [resolved]
Message-ID: <CAC6yHM4T49c0CXWznqc2oRv50QWqXRGfD-rD39KkWCDPdRn7MQ@mail.gmail.com>

I just wanted to share a solution for mixing C++ and Fortran programs
on Windows using Visual Studio and Intel Fortran. The build was
failing at link time with undefined symbols comming from fortran code.
Actually, none of the fortran sources were compiled, even though it
was working fine on Linux using Makefiles.

When generating a shared library with both fortran and c++ sources like this:

    add_library(mix foo.f bar.cpp)

It produces the following .vcxproj (snippet):

  <ItemGroup>
    <ClCompile Include="C:\path\to\foo.f" />
    <None Include="C:\path\to\bar.cpp" />
  </ItemGroup>

The None compiler, well, does nothing.

The trick is to create two libraries, one for C++ code and the other
for the fortran code:

    add_library(foo foo.f)
    add_library(bar bar.cpp)

Then, both .vcxproj and .vfproj gets created and the fortran code is compiled.

It might be useful to document it somewhere. Perhaps it is already
documented and I haven't found it?

Cheers,

Francis

From tjwrona1992 at gmail.com  Wed Feb 20 17:52:55 2019
From: tjwrona1992 at gmail.com (Timothy Wrona)
Date: Wed, 20 Feb 2019 17:52:55 -0500
Subject: [CMake] Automatically updating Doxygen documentation and making it
 readily available to users with CMake
Message-ID: <CAGrOMv2+e+=-xcnvHX22BK8VmxQ3h+rZgPw_iNG=2NmQ7Vj-nQ@mail.gmail.com>

I have worked on multiple C++ libraries that are built with CMake and run
Doxygen to generate HTML documentation. In every one of these libraries,
the documentation get's built into an "html" folder in the CMake "build"
directory and never gets looked at by anyone.

*Because let's be honest, most people don't like to read documentation at
all - let alone search for it.*

This leads to a few questions:

   1.

   Is there a standard location to put the documentation once it is built
   where it makes it very clear to the users of a library that documentation
   is available for a library?
   2.

   How can I ensure that every time my library is built, the documentation
   will be *automatically *updated and placed in this standard location?
   3.

   Is there any standard way to keep past versions of documentation for
   reference in case someone is using an earlier version of the library?

I have also posted this question on stack overflow. If you would like, you
can answer there instead because it may help a wider audience:
https://stackoverflow.com/questions/54796513/automatically-updating-doxygen-documentation-and-making-it-readily-available-to

Thanks,
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190220/27458c13/attachment.html>

From kuba at mareimbrium.org  Wed Feb 20 17:55:03 2019
From: kuba at mareimbrium.org (Kuba Ober)
Date: Wed, 20 Feb 2019 17:55:03 -0500
Subject: [CMake] Is there an idiomatic way of setting platform specific
 compiler options in a generic way?
Message-ID: <91F06EC0-DEB4-4EAB-BB93-961A140E735D@mareimbrium.org>

I am developing platform support for an embedded target (Z8 Encore!), and it mostly works ? but I?d like to make it easier to set the compiler and linker flags, as there?s a ton of them: and they are nothing like GNU flags, so they only apply when building for that particular target. 

Thus a question: is there a preferred way for the user to set platform-specific flags without having to know them exactly? I?m thinking of having some sort of platform-agnostic means of selecting compile and link flags, and then translating those for the platform the target is generated for.

Specifically, I want to avoid having the following in CMakeLists for the project:

if("${COMPILER_ID}" strequal "ez8cc")
target_compile_options(target1 PRIVATE -const:RAM)
elseif("${COMPILER_ID}" strequal "gcc" and "${CMAKE_SYSTEM_PROCESSOR}" strequal "somecpu")
target_compile_definitions(target1 PRIVATE ram rom far near) # those shall be empty
endif()

I?d like to do something like this instead:

set_target_properties(target1 PROPERTIES  OPT_CONST RAM OPT_PACK TIGHT ?)

Then, a process_target_opts() function called at the end of CMakeLists would iterate the targets, and for each target call process_${COMPILER_ID}_opts() (if such function would be present or issue a warning otherwise). That function then converts the OPT_ options to platform-specific flags, based on cpu and/or compiler.

Is it something that would be more-or-less idiomatic, or is there another preferred way of doing it? I really don?t want to list the options manually for each target/platform combo, as they?d differ quite a bit, and I have lots of targets (hundreds).

I?d appreciate any hints.

Cheers, Kuba Ober


From Alan.W.Irwin1234 at gmail.com  Thu Feb 21 01:44:33 2019
From: Alan.W.Irwin1234 at gmail.com (Alan W. Irwin)
Date: Wed, 20 Feb 2019 22:44:33 -0800 (PST)
Subject: [CMake] Automatically updating Doxygen documentation and making
 it readily available to users with CMake
In-Reply-To: <CAGrOMv2+e+=-xcnvHX22BK8VmxQ3h+rZgPw_iNG=2NmQ7Vj-nQ@mail.gmail.com>
References: <CAGrOMv2+e+=-xcnvHX22BK8VmxQ3h+rZgPw_iNG=2NmQ7Vj-nQ@mail.gmail.com>
Message-ID: <nycvar.QRO.7.76.1902202231560.5109@zreyva.zlyna.ubzr>

On 2019-02-20 17:52-0500 Timothy Wrona wrote:

> I have worked on multiple C++ libraries that are built with CMake and run
> Doxygen to generate HTML documentation. In every one of these libraries,
> the documentation get's built into an "html" folder in the CMake "build"
> directory and never gets looked at by anyone.
>
> *Because let's be honest, most people don't like to read documentation at
> all - let alone search for it.*
>
> This leads to a few questions:
>
>   1.
>
>   Is there a standard location to put the documentation once it is built
>   where it makes it very clear to the users of a library that documentation
>   is available for a library?
>   2.
>
>   How can I ensure that every time my library is built, the documentation
>   will be *automatically *updated and placed in this standard location?
>   3.
>
>   Is there any standard way to keep past versions of documentation for
>   reference in case someone is using an earlier version of the library?
>
> I have also posted this question on stack overflow. If you would like, you
> can answer there instead because it may help a wider audience:
> https://stackoverflow.com/questions/54796513/automatically-updating-doxygen-documentation-and-making-it-readily-available-to

I am not aware of any standard responses to your 3 questions above.

What I do for a couple of my projects that have doxygen-generated
documentation is I have a special custom command/target that copies
the doxygen-generated documentation from the build tree back to a
special directory in the source tree, and I only invoke that target if
I am creating a source tarball.  And similarly for DocBook-generated
documentation.  Furthermore, I configure my VCS in each case to ignore
those generated directories in the source tree so there are no VCS
complications, yet tarball users get a chance to access the generated
documentation.

Of course, if someone here has a better or more standardized scheme, I would like to hear it.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); 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
__________________________

From starka at fit.vutbr.cz  Thu Feb 21 05:48:56 2019
From: starka at fit.vutbr.cz (Starka =?iso-8859-2?b?VG9t4bk=?=)
Date: Thu, 21 Feb 2019 11:48:56 +0100
Subject: [CMake] transitive interface dependency problem
Message-ID: <20190221114856.140549jeidxfmzvc@email.fit.vutbr.cz>

Hi all,
following my previous post 'link only with targets feature' I have  
found yet another unpleasant consequence of not being able to tell  
cmake that it is the target name in the parameters of  
target_link_libraries (without the use of :: notation, that is  
optional and inconsistent). When I have library A which have an  
interface dependency interfaceDep and when using the export sets to  
automaticaly generate the configs while simultaneously internaly  
building an example app that is using lib A. I have encountered the  
following problem:
  In the cmake of lib A I do NOT search for the interfaceDep since  
there is no reason to, because the lib A compiles and links without  
it. But to relate that dependency to autogenerated config I need to  
state target_link_libraries(A INTERFACE interfaceDep), and then, for  
downstreamers, I need to handle the finding of it by hand in the  
config before the *Targets.cmake gets included (that's kind of ok and  
could be automated by cmake if we had consistent target naming  
syntax). Back to the build tree of the project for lib A. In the later  
subdirectories where I build an example app the  
target_link_libraries(example A) makes it wants interfaceDep.lib  
(which is non-existent since its only interface lib) eventhough there  
is correct interfaceDep target found prior to that in the app cmake.  
The thing is that the interfaceDep is resolved not in the application  
cmake but in the lib A cmake where there is no target of that name and  
the target_link_libraries doesn't know that it is supposed to be a  
target. I hope I didn't lost you yet.
I have come with two solutions. One is to not use INTERFACE  
dependencies ever and injecting them by hand in the config scripts for  
downstreamers - which seems more dirty and confusing and then in the  
same buildtree doing the same for all the apps/libs that uses lib A.  
The other solution is to create a dummy target -  
add_library(interfaceDep INTERFACE IMPORTED) in the lib A cmake just  
before you call target_link_libraries(A INTERFACE interfaceDep), which  
is less dirty but dirty nontheless.
Is there any other idiomatic approach? And NOTE that "use  
interfaceDep::interfaceDep" named target is not possible since it  
could be target created by 3rd party and you can't alias an IMPORTED  
target ;) (e.g. glm). It would realy help if there would be a 'link  
only with targets feature' in the cmake with all the consequences.
If you see it fit, you can also forward this to the developer only  
mailing-list. But I've started a new thread since it opens (and  
possibly resolves) a new isssue.

Hope posing these points will help
forry


From tjwrona1992 at gmail.com  Thu Feb 21 09:18:58 2019
From: tjwrona1992 at gmail.com (Timothy Wrona)
Date: Thu, 21 Feb 2019 09:18:58 -0500
Subject: [CMake] Automatically updating Doxygen documentation and making
 it readily available to users with CMake
In-Reply-To: <nycvar.QRO.7.76.1902202231560.5109@zreyva.zlyna.ubzr>
References: <CAGrOMv2+e+=-xcnvHX22BK8VmxQ3h+rZgPw_iNG=2NmQ7Vj-nQ@mail.gmail.com>
 <nycvar.QRO.7.76.1902202231560.5109@zreyva.zlyna.ubzr>
Message-ID: <CAGrOMv2PURzsu5hrBJcWtk1FpJkO=4w=R9v5z1_MVtoq-xLTXg@mail.gmail.com>

Perhaps there is a standard location to "install" the documentation when
running the install command for a project?

Either way having it as an "index.html" file somewhere on the hard-disk is
not very intuitive. It would make much more sense for it to be on a web
server where you can access it with a sensible URL.

On Thu, Feb 21, 2019 at 1:44 AM Alan W. Irwin <Alan.W.Irwin1234 at gmail.com>
wrote:

> On 2019-02-20 17:52-0500 Timothy Wrona wrote:
>
> > I have worked on multiple C++ libraries that are built with CMake and run
> > Doxygen to generate HTML documentation. In every one of these libraries,
> > the documentation get's built into an "html" folder in the CMake "build"
> > directory and never gets looked at by anyone.
> >
> > *Because let's be honest, most people don't like to read documentation at
> > all - let alone search for it.*
> >
> > This leads to a few questions:
> >
> >   1.
> >
> >   Is there a standard location to put the documentation once it is built
> >   where it makes it very clear to the users of a library that
> documentation
> >   is available for a library?
> >   2.
> >
> >   How can I ensure that every time my library is built, the documentation
> >   will be *automatically *updated and placed in this standard location?
> >   3.
> >
> >   Is there any standard way to keep past versions of documentation for
> >   reference in case someone is using an earlier version of the library?
> >
> > I have also posted this question on stack overflow. If you would like,
> you
> > can answer there instead because it may help a wider audience:
> >
> https://stackoverflow.com/questions/54796513/automatically-updating-doxygen-documentation-and-making-it-readily-available-to
>
> I am not aware of any standard responses to your 3 questions above.
>
> What I do for a couple of my projects that have doxygen-generated
> documentation is I have a special custom command/target that copies
> the doxygen-generated documentation from the build tree back to a
> special directory in the source tree, and I only invoke that target if
> I am creating a source tarball.  And similarly for DocBook-generated
> documentation.  Furthermore, I configure my VCS in each case to ignore
> those generated directories in the source tree so there are no VCS
> complications, yet tarball users get a chance to access the generated
> documentation.
>
> Of course, if someone here has a better or more standardized scheme, I
> would like to hear it.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); 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
> __________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190221/d7aaa930/attachment-0001.html>

From rwan.work at gmail.com  Thu Feb 21 10:21:36 2019
From: rwan.work at gmail.com (Raymond Wan)
Date: Thu, 21 Feb 2019 23:21:36 +0800
Subject: [CMake] Automatically updating Doxygen documentation and making
 it readily available to users with CMake
In-Reply-To: <CAGrOMv2PURzsu5hrBJcWtk1FpJkO=4w=R9v5z1_MVtoq-xLTXg@mail.gmail.com>
References: <CAGrOMv2+e+=-xcnvHX22BK8VmxQ3h+rZgPw_iNG=2NmQ7Vj-nQ@mail.gmail.com>
 <nycvar.QRO.7.76.1902202231560.5109@zreyva.zlyna.ubzr>
 <CAGrOMv2PURzsu5hrBJcWtk1FpJkO=4w=R9v5z1_MVtoq-xLTXg@mail.gmail.com>
Message-ID: <b9be93cf-9040-ada4-bf25-93d59730e4fe@gmail.com>


Hi Timothy,

This is not something I'm very familiar with, but maybe I 
can still add a little to the discussion by answering both 
of your messages together.


On 21/2/2019 10:18 PM, Timothy Wrona wrote:
> Perhaps there is a standard location to "install" the 
> documentation when running the install command for a project?
> 
> Either way having it as an "index.html" file somewhere on 
> the hard-disk is not very intuitive. It would make much more 
> sense for it to be on a web server where you can access it 
> with a sensible URL.


You're right that it isn't intuitive, but then you're 
assuming that users will all install a (Apache, etc.) web 
server.  And many users do not.

If you're doing cross-platform development, then I am fairly 
sure that most of the people I know who use Microsoft 
Windows do not install a web server.

On my Ubuntu-based computer, I have installed a local 
version of the Boost library.  The HTML documentation is 
installed in:  $BOOST_ROOT/doc/html/ .  In my case, 
$BOOST_ROOT is /usr/local/boost_<version>/, but some people 
might install it in /opt, for example.

As for your 3 questions, I don't know the definitive answer 
but my gut feeling is:


>      >? ?1.
>      >
>      >? ?Is there a standard location to put the
>     documentation once it is built
>      >? ?where it makes it very clear to the users of a
>     library that documentation
>      >? ?is available for a library?


For packages installed using Ubuntu's package management 
system, documentation tends to go to /usr/share/doc/ or 
/usr/share/man/.  But I'm sure the path is different for 
CentOS, RedHat, etc.

If you're not installing software through a package manager, 
then the documentation probably goes into /usr/local or /opt 
(See: 
https://unix.stackexchange.com/questions/11544/what-is-the-difference-between-opt-and-usr-local).

For software that I've developed myself, I've placed the 
documentation together with the software, similar to the 
Boost library.  That is, within the root directory, I threw 
it into a directory called doc/.  If sysadmin access is 
required and it goes into /usr/local/<software>/, then like 
Boost, it would go inside that directory.

With other people's programs that I've downloaded myself, I 
normally look in the root directory (of that program) for a 
doc/ directory too.  So, perhaps the answer to your question 
about "standard location" is to just ask yourself if your 
role was reversed -- i.e., you're just a user -- where would 
you look for documentation?


>      >? ?2.
>      >
>      >? ?How can I ensure that every time my library is
>     built, the documentation
>      >? ?will be *automatically *updated and placed in this
>     standard location?


Since this is your software and you wrote the CMake file, as 
long as you've defined and then fixed the installation 
target from version to version, then it should be ok.

I don't know what kind of automation you were looking for. 
Someone still has to do a "cmake ..; make; make install" or 
something like that.  You're not talking about automation 
along the lines of some cron job, are you?


>      >? ?3.
>      >
>      >? ?Is there any standard way to keep past versions of
>     documentation for
>      >? ?reference in case someone is using an earlier
>     version of the library?


I think when you've asked "standard way", it sounds like 
you're looking for Doxygen and/or CMake having standardized 
the location.  But, based on my examples above, it seems it 
is OS dependent.

And it depends whether you're distributing the source files 
or the binaries only (i.e., like an Ubuntu/Debian .deb 
package).  In the case of the former, you've defined it 
using your CMake file.  In the latter case, you've compiled 
it and then wrote some instructions for Debian's package 
management software so that the documentation goes into 
/usr/share/doc, /usr/share/man/, etc.

Just my 2 cents...I'm happy to hear what others think.

Ray



From csiga.biga at aol.com  Thu Feb 21 10:23:46 2019
From: csiga.biga at aol.com (csiga.biga at aol.com)
Date: Thu, 21 Feb 2019 15:23:46 +0000 (UTC)
Subject: [CMake] CUDA language support with host compiler flags
References: <1542223442.2988574.1550762626182.ref@mail.yahoo.com>
Message-ID: <1542223442.2988574.1550762626182@mail.yahoo.com>

Hi All!
I am trying to compile CUDA code with controlling both host and device compiler flags.
Currently my CMakeLists.txt looks like:
```
cmake_minimum_required(VERSION 3.8) # CUDA language support

project(CUDA_test LANGUAGES CXX CUDA)

if (MSVC)
? string(REGEX REPLACE "/W[0-9]" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
endif (MSVC)

set(Hdrs)

set(Srcs Main.cu)

add_executable(${PROJECT_NAME} ${Hdrs} ${Srcs})

target_include_directories(${PROJECT_NAME} PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})

target_compile_options(${PROJECT_NAME} PRIVATE $<$<OR:$<CXX_COMPILER_ID:GNU>,$<CXX_COMPILER_ID:Clang>>:-Wall -Wextra -pedantic>
?????????????????????????????????????????????? $<$<CXX_COMPILER_ID:MSVC>:/W4>)

set_target_properties(${PROJECT_NAME} PROPERTIES CUDA_SEPARABLE_COMPILATION ON
???????????????????????????????????????????????? CUDA_STANDARD 14
???????????????????????????????????????????????? CUDA_STANDARD_REQUIRED ON
???????????????????????????????????????????????? CUDA_EXTENSIONS OFF
???????????????????????????????????????????????? CXX_STANDARD 14
???????????????????????????????????????????????? CXX_STANDARD_REQUIRED ON
???????????????????????????????????????????????? CXX_EXTENSIONS OFF)

source_group ("Headers" FILES ${Hdrs})
source_group ("Sources" FILES ${Srcs})```

However, when I compile the code I get the following error:
[1/3] Building CUDA object CMakeFiles/CUDA_test.dir/Main.cu.o
FAILED: CMakeFiles/CUDA_test.dir/Main.cu.o 
/usr/bin/nvcc?? -I/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL -g?? -Wall -Wextra -pedantic -std=c++14 -x cu -dc /var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL/Main.cu -o CMakeFiles/CUDA_test.dir/Main.cu.o && /usr/bin/nvcc?? -I/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL -g?? -Wall -Wextra -pedantic -std=c++14 -x cu -M /var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL/Main.cu -MT CMakeFiles/CUDA_test.dir/Main.cu.o -o CMakeFiles/CUDA_test.dir/Main.cu.o.d
nvcc fatal?? : Unknown option 'Wall'
ninja: build stopped: subcommand failed.
CMake seems to pass -Wall -Wextra -pedantic to the device compiler as well, even though it is neither GNU nor Clang, but CUDA. How can I specify warning and similar flags separatly for the host and device compilers?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190221/47c42c27/attachment.html>

From csiga.biga at aol.com  Thu Feb 21 11:15:40 2019
From: csiga.biga at aol.com (csiga.biga at aol.com)
Date: Thu, 21 Feb 2019 16:15:40 +0000 (UTC)
Subject: [CMake] [cmake-developers] [MSVC] Setting warning level on
 target feels like long-time bug
In-Reply-To: <CABUeae_jJECpPSk6fxSonoi6gwWE10x3SyFKQNNxwY1p8vPGSw@mail.gmail.com>
References: <CABUeae9h_wLr6KDwtW8Ttu6admSReFk0ApLjrna9+n050jqHoQ@mail.gmail.com>
 <CA+dygY==fNbC5etuFQNk6ebKZu4QmUDJbmH3gdjP5sHbetV-aQ@mail.gmail.com>
 <CABUeae-ZbQh_GRnn1JbOYOomAf1NBdq+CZ9hX-6r10F0f-tsjA@mail.gmail.com>
 <b2752ab5-ebb7-4f7a-835a-1d0d8f438cc2@Spark>
 <CABUeae_jJECpPSk6fxSonoi6gwWE10x3SyFKQNNxwY1p8vPGSw@mail.gmail.com>
Message-ID: <654009243.3008960.1550765740908@mail.yahoo.com>

 I was just about to write a mail with similar content than this one, so allow me to add my 5 cents.
Fear of reyling on defaults in case Microsoft decides to change them?
1) Defaults don't change often. BTW, don't we rely on defaults for GCC and Clang anyway?2) Defaults change to benefit users. If the default changes from /W3 to /W4 per say, it would be because windows.h headers and the STL would be cleaned up for the warnings in /W4 and MS felt that it would be better if users relied on all the warning they packed there. (Currently it is not the case)
As for having to call string() on CMAKE_CXX_FLAGS to up my warning level for a single compiler... these sort of idiosincrecies are the ones that drive people away from CMake to Meson and other, more modern build systems. Not being able to clean up decades worth of sediments in script style will result in CMake's demise.

if (MSVC)? string(REGEX REPLACE "/W[0-9]""" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})endif (MSVC)?add_executable(${PROJECT_NAME}main.cpp)?target_compile_options(${PROJECT_NAME}PRIVATE$<$<OR:$<CXX_COMPILER_ID:GNU>,$<CXX_COMPILER_ID:Clang>>:-Wall-Wextra -pedantic>????????????????????????????????????????  $<$<CXX_COMPILER_ID:MSVC>:/W4>) 
Instead of
?add_executable(${PROJECT_NAME}main.cpp)?target_compile_options(${PROJECT_NAME}PRIVATE$<$<OR:$<CXX_COMPILER_ID:GNU>,$<CXX_COMPILER_ID:Clang>>:-Wall-Wextra -pedantic>????????????????????????????????????????  $<$<CXX_COMPILER_ID:MSVC>:/W4>)
Or even
add_executable(${PROJECT_NAME}main.cpp)
set_target_properties(${PROJECT_NAME}PROPERTIES WARNING_LEVEL HIGH)
is nonsense. There should be direct support for a few pre-defined, commonly accepted warning levels. If not this, having to explain to C++ freshmen why we're running regexes over lists default args to clean them up BEFORE even stating our bussiness...


Please, remove this default because it hurts CMake as a whole.
Cheers,M?t?

-----Original Message-----
From: Mateusz Loskot <mateusz at loskot.net>
To: marc.chevrier <marc.chevrier at gmail.com>
Cc: cmake-developers <cmake-developers at cmake.org>; cmake <cmake at cmake.org>
Sent: Sun, Dec 9, 2018 2:55 pm
Subject: Re: [cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug

On Sun, 9 Dec 2018 at 14:09, Marc CHEVRIER <marc.chevrier at gmail.com> wrote:
>
> I think the discussion is shifting from the initial problem which was unwanted warning ? Command line warning D9025: overriding '/W3' with '/W4' ?.

I disagree with your opinion.
Fixing just the warning would be a symptomatic treatment.

> Changing defaults is not a good idea from my point of view because relying on defaults can be problematic if Microsoft decide to change the default behaviour.

Although I think it is a long shot at something that is (highly)
unlikely to change, YAGNI consideration,
I understand CMake developers may be reluctant to change the long-time defaults.

> The real question is how to manage cleanly target specific flags overriding global or directory defaults?

>From end-user point of view (I have not checekd CMake implementation),
I'd either do not explicitly set -W defaults or strip any -W option
prior re-setting
with (possibly) new value passed to target_compile_options.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190221/fb2ef42b/attachment-0001.html>

From rleigh at codelibre.net  Thu Feb 21 15:51:23 2019
From: rleigh at codelibre.net (Roger Leigh)
Date: Thu, 21 Feb 2019 20:51:23 +0000
Subject: [CMake] Automatically updating Doxygen documentation and making
 it readily available to users with CMake
In-Reply-To: <CAGrOMv2PURzsu5hrBJcWtk1FpJkO=4w=R9v5z1_MVtoq-xLTXg@mail.gmail.com>
References: <CAGrOMv2+e+=-xcnvHX22BK8VmxQ3h+rZgPw_iNG=2NmQ7Vj-nQ@mail.gmail.com>
 <nycvar.QRO.7.76.1902202231560.5109@zreyva.zlyna.ubzr>
 <CAGrOMv2PURzsu5hrBJcWtk1FpJkO=4w=R9v5z1_MVtoq-xLTXg@mail.gmail.com>
Message-ID: <0187f42f-3567-ee87-2715-81c03940d50a@codelibre.net>

On 21/02/2019 14:18, Timothy Wrona wrote:
> Perhaps there is a standard location to "install" the documentation when 
> running the install command for a project?

This collection builds and installs the documentation into a standard 
location, as well as reporting undocumented code.  Feel free to copy and 
adapt.  Could be turned into an official module if there was interest 
for a generic solution for doxygen docs building and installing.

 
https://gitlab.com/codelibre/ome-common-cpp/blob/master/docs/doxygen/CMakeLists.txt

 
https://gitlab.com/codelibre/ome-common-cpp/blob/master/docs/doxygen/api.dox.cmake

 
https://gitlab.com/codelibre/ome-common-cpp/blob/master/cmake/Doxygen.cmake

 
https://gitlab.com/codelibre/ome-common-cpp/blob/master/cmake/DoxygenCheck.cmake

Dependent modules can also cross-reference documentation for modules 
they depend upon.  See lines 44-56 for overriding the tagfiles, which 
are then substituted into the generated doxyfile configuration.  This 
could also be generalised to make into a reusable module.

 
https://gitlab.com/codelibre/ome-files-cpp/blob/master/docs/doxygen/CMakeLists.txt

You can see this on the GitLab documentation pages (linked from the 
README) for the project(s) in question.

Hope that's potentially of some use for anyone interested.


Roger

From cmake at cmake.org  Fri Feb 22 04:02:17 2019
From: cmake at cmake.org (=?UTF-8?Q?M=c3=a1t=c3=a9_Ferenc_Nagy-Egri_via_CMake?=)
Date: Fri, 22 Feb 2019 10:02:17 +0100
Subject: [CMake] CUDA language support with host compiler flags
In-Reply-To: <1542223442.2988574.1550762626182.ref@mail.yahoo.com>
References: <1542223442.2988574.1550762626182.ref@mail.yahoo.com>
Message-ID: <565fd4e9-fa49-d576-3469-9e9ff9f67d90@numalliance.com>

Hi All!

I am trying to compile CUDA code with controlling both host and device 
compiler flags.

Currently my CMakeLists.txt looks like:

```
cmake_minimum_required(VERSION 3.8) # CUDA language support

project(CUDA_test LANGUAGES CXX CUDA)

if (MSVC)
 ? string(REGEX REPLACE "/W[0-9]" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
endif (MSVC)

set(Hdrs)

set(Srcs Main.cu)

add_executable(${PROJECT_NAME} ${Hdrs} ${Srcs})

target_include_directories(${PROJECT_NAME} PRIVATE 
${CMAKE_CURRENT_SOURCE_DIR})

target_compile_options(${PROJECT_NAME} PRIVATE 
$<$<OR:$<CXX_COMPILER_ID:GNU>,$<CXX_COMPILER_ID:Clang>>:-Wall -Wextra 
-pedantic>
$<$<CXX_COMPILER_ID:MSVC>:/W4>)

set_target_properties(${PROJECT_NAME} PROPERTIES 
CUDA_SEPARABLE_COMPILATION ON
 ???????????????????????????????????????????????? CUDA_STANDARD 14
CUDA_STANDARD_REQUIRED ON
CUDA_EXTENSIONS OFF
 ???????????????????????????????????????????????? CXX_STANDARD 14
CXX_STANDARD_REQUIRED ON
CXX_EXTENSIONS OFF)

source_group ("Headers" FILES ${Hdrs})
source_group ("Sources" FILES ${Srcs})
```

However, when I compile the code I get the following error:

[1/3] Building CUDA object CMakeFiles/CUDA_test.dir/Main.cu.o
FAILED: CMakeFiles/CUDA_test.dir/Main.cu.o
/usr/bin/nvcc 
-I/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL -g?? 
-Wall -Wextra -pedantic -std=c++14 -x cu -dc 
/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL/Main.cu 
-o CMakeFiles/CUDA_test.dir/Main.cu.o && /usr/bin/nvcc 
-I/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL -g?? 
-Wall -Wextra -pedantic -std=c++14 -x cu -M 
/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL/Main.cu 
-MT CMakeFiles/CUDA_test.dir/Main.cu.o -o 
CMakeFiles/CUDA_test.dir/Main.cu.o.d
nvcc fatal?? : Unknown option 'Wall'
ninja: build stopped: subcommand failed.

CMake seems to pass -Wall -Wextra -pedantic to the device compiler as 
well, even though it is neither GNU nor Clang, but CUDA. How can I 
specify warning and similar flags separatly for the host and device 
compilers?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190222/02a8a87b/attachment.html>
-------------- next part --------------
-- 

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:
https://cmake.org/mailman/listinfo/cmake


From marc.herbert at gmail.com  Fri Feb 22 12:02:28 2019
From: marc.herbert at gmail.com (Marc Herbert)
Date: Fri, 22 Feb 2019 09:02:28 -0800
Subject: [CMake] Automatically updating Doxygen documentation and making
 it readily available to users with CMake
In-Reply-To: <CAGrOMv2PURzsu5hrBJcWtk1FpJkO=4w=R9v5z1_MVtoq-xLTXg@mail.gmail.com>
References: <CAGrOMv2+e+=-xcnvHX22BK8VmxQ3h+rZgPw_iNG=2NmQ7Vj-nQ@mail.gmail.com>
 <nycvar.QRO.7.76.1902202231560.5109@zreyva.zlyna.ubzr>
 <CAGrOMv2PURzsu5hrBJcWtk1FpJkO=4w=R9v5z1_MVtoq-xLTXg@mail.gmail.com>
Message-ID: <CA+rkZbj1++8DEiqFP4dp=7vaWY=yy3ER3YJLUt3YUUsxiZ-r_w@mail.gmail.com>

Le jeu. 21 f?vr. 2019 ? 06:19, Timothy Wrona <tjwrona1992 at gmail.com> a
?crit :

>
> Either way having it as an "index.html" file somewhere on the hard-disk is
> not very intuitive. It would make much more sense for it to be on a web
> server where you can access it with a sensible URL.
>

Unless it's linked from some front page you know users often go to, I don't
see why http://some.server/doc/mylibrary/index.html is more "intuitive"
than file://some/directory/mylibrary/index.html. The difference between the
two is sharing vs not, it's not about "intuitiveness".

BTW your questions are really not clear on the topic of sharing. The
problem of a developer building documentation without realizing it is very
different from the problem of user not building anything, even when the
latter is not curious about documentation either.

PS: I suggested some cmake fine-tuning on stackoverflow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190222/29b1abed/attachment.html>

From tjwrona1992 at gmail.com  Sat Feb 23 00:14:32 2019
From: tjwrona1992 at gmail.com (Timothy Wrona)
Date: Sat, 23 Feb 2019 00:14:32 -0500
Subject: [CMake] Ensuring an external project is built and installed before
 trying to call "find_package" on it
Message-ID: <CAGrOMv0=HydGXZOqK6OeM7akk3pjXjgRL7w-y8Dd7A=VX-E3Qg@mail.gmail.com>

I am working on a CMake project that depends on a couple other projects I
have previously written. I would like to include those other projects using
"ExternalProject_Add", but I am having some issues.

The basic layout of the project is this:

cmake_minimum_required(VERSION 3.14.0)

project(ProjectWithDependencies)

include(ExternalProject)
ExternalProject_Add(Dependency1
    GIT_REPOSITORY <URL to git repo>
)
ExternalProject_Add(Dependency2
    GIT_REPOSITORY <URL to git repo>
)

find_package(Dependency1 Required)
find_package(Dependency2 Required)

# Use targets

I was under the assumption that "ExternalProject_Add" would automatically
build and install the dependencies before getting to the "find_package"
calls (they are CMake projects so the default build and install commands
should be fine) but this doesn't seem to be how it works.

When I get to "find_package" it fails because the dependency hasn't been
installed yet.

How can I ensure that the dependencies are fully compiled and installed
before attempting to find them? (Note: FetchContent doesn't work here
because the two projects "Dependency1" and "Dependency2" have targets with
the same name which causes FetchContent to fail.)

Any help is appreciated.

Thanks,
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190223/68e448b8/attachment.html>

From craig.scott at crascit.com  Sat Feb 23 02:32:07 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Sat, 23 Feb 2019 18:32:07 +1100
Subject: [CMake] Ensuring an external project is built and installed
 before trying to call "find_package" on it
In-Reply-To: <CAGrOMv0=HydGXZOqK6OeM7akk3pjXjgRL7w-y8Dd7A=VX-E3Qg@mail.gmail.com>
References: <CAGrOMv0=HydGXZOqK6OeM7akk3pjXjgRL7w-y8Dd7A=VX-E3Qg@mail.gmail.com>
Message-ID: <CA+dygY=Z5FAoJcY4x8Qc6QXGNzcR1TLEY-rDaEq7cKwBkDtEMg@mail.gmail.com>

On Sat, Feb 23, 2019 at 4:14 PM Timothy Wrona <tjwrona1992 at gmail.com> wrote:

> I am working on a CMake project that depends on a couple other projects I
> have previously written. I would like to include those other projects using
> "ExternalProject_Add", but I am having some issues.
>
> The basic layout of the project is this:
>
> cmake_minimum_required(VERSION 3.14.0)
>
> project(ProjectWithDependencies)
>
> include(ExternalProject)
> ExternalProject_Add(Dependency1
>     GIT_REPOSITORY <URL to git repo>
> )
> ExternalProject_Add(Dependency2
>     GIT_REPOSITORY <URL to git repo>
> )
>
> find_package(Dependency1 Required)
> find_package(Dependency2 Required)
>
> # Use targets
>
> I was under the assumption that "ExternalProject_Add" would automatically
> build and install the dependencies before getting to the "find_package"
> calls (they are CMake projects so the default build and install commands
> should be fine) but this doesn't seem to be how it works.
>
> When I get to "find_package" it fails because the dependency hasn't been
> installed yet.
>
> How can I ensure that the dependencies are fully compiled and installed
> before attempting to find them? (Note: FetchContent doesn't work here
> because the two projects "Dependency1" and "Dependency2" have targets with
> the same name which causes FetchContent to fail.)
>
> Any help is appreciated.
>

find_package() requires that the dependencies have been built already, as
you've noted. When CMake runs and processes your example CMakeLists.txt
file, it sets up the build rules for Dependency1 and Dependency2, but they
won't actually be configured, built and installed until you build the main
project. Since your find_package() calls will be processed during the
configure stage of the main project (i.e. before the build stage), it's too
early.

To address this, you need to make your main project a true superbuild where
it basically contains nothing more than a set of ExternalProject_Add()
calls. Rather than putting the find_package() calls and use of targets
directly in the main build, you can add it as another sub-build. Note that
this will mean that none of the targets you define in the mainBuild will be
visible as targets in your top level superbuild project. I'd also advise
you to override the default install location of your dependencies.
Otherwise they will typically try to install to a system-wide location,
which is not usually a good thing. Putting it together, the top level
superbuild project would look something like this:

cmake_minimum_required(VERSION 3.14.0)
project(ProjectWithDependencies)

set(installDir ${CMAKE_CURRENT_BINARY_DIR}/install)

include(ExternalProject)
ExternalProject_Add(Dependency1
    GIT_REPOSITORY <URL to git repo>
    INSTALL_DIR    ${installDir}
    CMAKE_ARGS     -DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>
)
ExternalProject_Add(Dependency2
    GIT_REPOSITORY <URL to git repo>
    INSTALL_DIR    ${installDir}
    CMAKE_ARGS     -DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>
)
ExternalProject_Add(mainBuild
    SOURCE_DIR  <path_to_some_subdir_in_this_repo>
    INSTALL_DIR ${installDir}
    DEPENDS     Dependency1 Dependency2
    CMAKE_ARGS  -DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>
                -DCMAKE_PREFIX_PATH:PATH=<INSTALL_DIR>
)

Or you could make the superbuild a completely separate repo and then use
GIT_REPOSITORY rather than SOURCE_DIR for the "mainBuild" part.

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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190223/88fda536/attachment.html>

From jason.heeris at gmail.com  Sat Feb 23 02:48:56 2019
From: jason.heeris at gmail.com (Jason Heeris)
Date: Sat, 23 Feb 2019 18:48:56 +1100
Subject: [CMake] Toolchain file for TI in CMake 3.10: how do I override
 compiler options and specify tools?
Message-ID: <CA+Zd3FdzHxouGQb_e8Y35X9JAyjzdZ6t7uaSkAUb86NboC=kRw@mail.gmail.com>

I am trying to use CMake (3.10) to build an ANSI C project that may be
compiled on PC with eg. GCC, but also needs to compile with Texas
Instruments' compilers for their microprocessors. So I have about a million
questions.

According to[1] it seems like the way to do this is via a toolchain file.
So I'm trying to write a toolchain file to use TI's compiler/linker/etc,
which do not (always) take the same arguments as eg. GCC or Clang.

Is there a complete list of tools I can override in a toolchain file?
Specifically, I want to set the C compiler, C++ compiler, assembler and
linker. I know about CMAKE_C(XX)_COMPILER, but what about the others? Are
they documented anywhere? (I could guess, but I don't think that's wise.)

As I mentioned, TI's tools aren't the same as GCC, so I need to pare back a
lot of options and start from almost-scratch (there are some
commonalities). Options like "-D" and "-I" are fine, which is good because
then eg. target_include_directories() still works. But certain other flags
are just going to cause errors. How do I completely remove all compile
flags from the generated Makefiles and replace them with my own? I can do
this:

set(CMAKE_C_FLAGS ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_DEBUG ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_RELEASE ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_RELWITHDEBINFO ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_MINSIZEREL ${MINIMAL_FLAGS} CACHE STRING "" FORCE)

But I *still* see flags in the generated makefiles that I didn't put there
such as "--compile_only" and "--c_file=...". How do I get rid of these and
specify what's correct for my toolchain? (Also, why do I need the CACHE
STRING "" FORCE options? I pulled that out of various Stackoverflow posts
but I have no idea why it's necessary. Is that documented? What about the
configurations... where are they listed? Do I have them all?)

(I keep asking "is this documented anywhere" because I like to provide
references in code for future maintainers. I'm not trying to be unkind.
Maybe once I know enough I can volunteer to write any missing docs myself.)

How do I add default flags that involve the source file name eg. for a file
"main.c" I want to have a C compiler flag "--some_option='main.x'"?

Finally, this really seems like a lot of work despite the fact that
toolchain files are (I thought) meant to be the way to define a different
toolchain. It really feels like I'm swimming against the tide here. Is
there another, more-CMake-ish way to accomplish what I'm trying to do?

[1]
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/CrossCompiling

Thanks for any help.

- Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190223/e8f1bfd9/attachment-0001.html>

From patrick.griffiths at gmail.com  Sat Feb 23 13:52:06 2019
From: patrick.griffiths at gmail.com (Patrick Griffiths)
Date: Sat, 23 Feb 2019 11:52:06 -0700
Subject: [CMake] Toolchain file for TI in CMake 3.10: how do I override
 compiler options and specify tools?
In-Reply-To: <CA+Zd3FdzHxouGQb_e8Y35X9JAyjzdZ6t7uaSkAUb86NboC=kRw@mail.gmail.com>
References: <CA+Zd3FdzHxouGQb_e8Y35X9JAyjzdZ6t7uaSkAUb86NboC=kRw@mail.gmail.com>
Message-ID: <CANqUTaQxuHRLunGdJz=c3hFK_tw2MXv9Ad6TLGEf3A-GjB3F-Q@mail.gmail.com>

On Sat, Feb 23, 2019 at 12:49 AM Jason Heeris <jason.heeris at gmail.com>
wrote:

> I am trying to use CMake (3.10) to build an ANSI C project that may be
> compiled on PC with eg. GCC, but also needs to compile with Texas
> Instruments' compilers for their microprocessors. So I have about a million
> questions.
>
> According to[1] it seems like the way to do this is via a toolchain file.
> So I'm trying to write a toolchain file to use TI's compiler/linker/etc,
> which do not (always) take the same arguments as eg. GCC or Clang.
>
> Is there a complete list of tools I can override in a toolchain file?
> Specifically, I want to set the C compiler, C++ compiler, assembler and
> linker. I know about CMAKE_C(XX)_COMPILER, but what about the others? Are
> they documented anywhere? (I could guess, but I don't think that's wise.)
>
> As I mentioned, TI's tools aren't the same as GCC, so I need to pare back
> a lot of options and start from almost-scratch (there are some
> commonalities). Options like "-D" and "-I" are fine, which is good because
> then eg. target_include_directories() still works. But certain other flags
> are just going to cause errors. How do I completely remove all compile
> flags from the generated Makefiles and replace them with my own? I can do
> this:
>
> set(CMAKE_C_FLAGS ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
> set(CMAKE_C_FLAGS_DEBUG ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
> set(CMAKE_C_FLAGS_RELEASE ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
> set(CMAKE_C_FLAGS_RELWITHDEBINFO ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
> set(CMAKE_C_FLAGS_MINSIZEREL ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
>
> But I *still* see flags in the generated makefiles that I didn't put there
> such as "--compile_only" and "--c_file=...". How do I get rid of these and
> specify what's correct for my toolchain? (Also, why do I need the CACHE
> STRING "" FORCE options? I pulled that out of various Stackoverflow posts
> but I have no idea why it's necessary. Is that documented? What about the
> configurations... where are they listed? Do I have them all?)
>
> (I keep asking "is this documented anywhere" because I like to provide
> references in code for future maintainers. I'm not trying to be unkind.
> Maybe once I know enough I can volunteer to write any missing docs myself.)
>
> How do I add default flags that involve the source file name eg. for a
> file "main.c" I want to have a C compiler flag "--some_option='main.x'"?
>
> Finally, this really seems like a lot of work despite the fact that
> toolchain files are (I thought) meant to be the way to define a different
> toolchain. It really feels like I'm swimming against the tide here. Is
> there another, more-CMake-ish way to accomplish what I'm trying to do?
>
> [1]
> https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/CrossCompiling
>
> Thanks for any help.
>
> - Jason
> --
>
>

I've written toolchain files for cross-compiling with gcc and/or clang, but
not for for proprietary compilers, but maybe this brain dump can help:

In addition to CMAKE_<LANG>_COMPILER, you'll probably need to look at:

CMAKE_<LANG>_FLAGS_INIT
CMAKE_<LANG>_FLAGS_DEBUG_INIT
etc ...

Sounds like you need to set them all explicitly since CMake doesn't know
anything about your toolchain out of the box. The configurations (debug,
release, etc) are handled by the variable naming. You should be able to set
exactly what you want.  CMake glues the various flag variables together so
you might need to experiment a little to see what the result is.

You might want to look at the CMAKE_TRY_COMPILE_* variable as it sounds
like you're compiling for baremetal or an RTOS.

Unfortunately, I think you're best best is  to dig through the
documentation and trial and error. The variables and toolchain sections
will be helpful:

https://cmake.org/cmake/help/v3.10/index.html

cmake has command line options you might find useful like --trace and
--debug-trycompile.

You can do make VERBOSE=1 to see what's executed.

FWIW, I suggest starting with a single .c file with an empty main. Once
that compiles, start adding complexity. Good luck.

HTH
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190223/72d0c0a7/attachment.html>

From cristian.adam at gmail.com  Sat Feb 23 14:24:35 2019
From: cristian.adam at gmail.com (Cristian Adam)
Date: Sat, 23 Feb 2019 20:24:35 +0100
Subject: [CMake] Toolchain file for TI in CMake 3.10: how do I override
 compiler options and specify tools?
In-Reply-To: <CA+Zd3FdzHxouGQb_e8Y35X9JAyjzdZ6t7uaSkAUb86NboC=kRw@mail.gmail.com>
References: <CA+Zd3FdzHxouGQb_e8Y35X9JAyjzdZ6t7uaSkAUb86NboC=kRw@mail.gmail.com>
Message-ID: <CA+u+m-JeYV9w3ugkDVGTSnF_JburRuPMH=vSdFs+k4UmuUbFuQ@mail.gmail.com>

On Sat, Feb 23, 2019 at 8:49 AM Jason Heeris <jason.heeris at gmail.com> wrote:

> I am trying to use CMake (3.10) to build an ANSI C project that may be
> compiled on PC with eg. GCC, but also needs to compile with Texas
> Instruments' compilers for their microprocessors. So I have about a million
> questions.
>
> According to[1] it seems like the way to do this is via a toolchain file.
> So I'm trying to write a toolchain file to use TI's compiler/linker/etc,
> which do not (always) take the same arguments as eg. GCC or Clang.
>
> Is there a complete list of tools I can override in a toolchain file?
> Specifically, I want to set the C compiler, C++ compiler, assembler and
> linker. I know about CMAKE_C(XX)_COMPILER, but what about the others? Are
> they documented anywhere? (I could guess, but I don't think that's wise.)
>
> As I mentioned, TI's tools aren't the same as GCC, so I need to pare back
> a lot of options and start from almost-scratch (there are some
> commonalities). Options like "-D" and "-I" are fine, which is good because
> then eg. target_include_directories() still works. But certain other flags
> are just going to cause errors. How do I completely remove all compile
> flags from the generated Makefiles and replace them with my own? I can do
> this:
>
> set(CMAKE_C_FLAGS ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
> set(CMAKE_C_FLAGS_DEBUG ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
> set(CMAKE_C_FLAGS_RELEASE ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
> set(CMAKE_C_FLAGS_RELWITHDEBINFO ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
> set(CMAKE_C_FLAGS_MINSIZEREL ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
>
> But I *still* see flags in the generated makefiles that I didn't put there
> such as "--compile_only" and "--c_file=...". How do I get rid of these and
> specify what's correct for my toolchain? (Also, why do I need the CACHE
> STRING "" FORCE options? I pulled that out of various Stackoverflow posts
> but I have no idea why it's necessary. Is that documented? What about the
> configurations... where are they listed? Do I have them all?)
>
>
Regarding the CMAKE_<LANG>_FLAGS_<CONFIG> have a look at this blog post:
https://cristianadam.eu/20190223/modifying-the-default-cmake-build-types/

You "just" need to modify the CMAKE_<LANG>_FLAGS_<CONFIG>_INIT variables,
no need to force the cache entries.

The "Modules" CMake folder is your friend, you can see how CMake handles
other compilers.
For debugging use CMake's "--trace-expand" command line parameter.

Cheers,
Cristian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190223/823a79cb/attachment.html>

From paul at mad-scientist.net  Sat Feb 23 15:24:28 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Sat, 23 Feb 2019 15:24:28 -0500
Subject: [CMake] Getting the path to object files?
Message-ID: <5eaedde5735d330e0783975625676d9229ab1be3.camel@mad-scientist.net>

Hi all.  I'm using CMake 3.13.4 across Linux, MacOS, and Windows, with
various generators.

I need to write a script (this only runs on Linux actually) that will
do some processing on all the object files in a shared library and
generate a linker version file.  I'm trying to write a custom command
using PRE_LINK that will invoke that script and pass along enough
information to find all those object files so it can generate the
version file, and I can't come up with it.

For example, using a Makefile generator for a file "libsrc.cpp" built
for a library "solib" in a directory "LibDir" on Linux my object file
paths look like:

  LibDir/CMakeFiles/solib.dir/libsrc.cpp.o

I can use something like this:

  get_target_property(srcs solib SOURCES)

  add_custom_command(TARGET solib PRE_LINK
      COMMAND foo ${srcs}
      VERBATIM)

(for some reason if I try to use a generator expression like
$<TARGET_PROPERTY:SOURCES> etc. it's always passed as a single quoted
argument and I can't figure out how break it up, but if I use
get_target_property() then it works correctly).

However this only gives me the source file names, not the object file
names, and no directory information to search.  My problem is I'm
actually compiling these same source files multiple times in different
ways for different libraries, so I can't just search for "libsrc.cpp.o"
I need to get this particular .o.

So then I added $<TARGET_PROPERTY:BINARY_DIR> which looked promising,
but it only gives me the path to the source directory; i.e. above it
gives me LibDir.

I tried lots of different likely-looking properties, but I can't find
any property which will tell me the path I'm looking for.

Can I get CMake to tell me the path where the object files being
created will be put for a given target?  Or do I just need to hard-code 
it based on my observations of how cmake generators actually create the
output?


From frodak17 at gmail.com  Sat Feb 23 16:46:18 2019
From: frodak17 at gmail.com (frodak17)
Date: Sat, 23 Feb 2019 16:46:18 -0500
Subject: [CMake] Toolchain file for TI in CMake 3.10: how do I override
 compiler options and specify tools?
In-Reply-To: <CA+u+m-JeYV9w3ugkDVGTSnF_JburRuPMH=vSdFs+k4UmuUbFuQ@mail.gmail.com>
References: <CA+Zd3FdzHxouGQb_e8Y35X9JAyjzdZ6t7uaSkAUb86NboC=kRw@mail.gmail.com>
 <CA+u+m-JeYV9w3ugkDVGTSnF_JburRuPMH=vSdFs+k4UmuUbFuQ@mail.gmail.com>
Message-ID: <CAM_JqVkmGqVZXR2xw=v1cVamisT9ga+BD=SrnVjqcNxkx5=32A@mail.gmail.com>

On Sat, Feb 23, 2019 at 2:24 PM Cristian Adam <cristian.adam at gmail.com>
wrote:

>
>
> On Sat, Feb 23, 2019 at 8:49 AM Jason Heeris <jason.heeris at gmail.com>
> wrote:
>
>> I am trying to use CMake (3.10) to build an ANSI C project that may be
>> compiled on PC with eg. GCC, but also needs to compile with Texas
>> Instruments' compilers for their microprocessors. So I have about a million
>> questions.
>>
>> According to[1] it seems like the way to do this is via a toolchain file.
>> So I'm trying to write a toolchain file to use TI's compiler/linker/etc,
>> which do not (always) take the same arguments as eg. GCC or Clang.
>>
>> Is there a complete list of tools I can override in a toolchain file?
>> Specifically, I want to set the C compiler, C++ compiler, assembler and
>> linker. I know about CMAKE_C(XX)_COMPILER, but what about the others? Are
>> they documented anywhere? (I could guess, but I don't think that's wise.)
>>
>> As I mentioned, TI's tools aren't the same as GCC, so I need to pare back
>> a lot of options and start from almost-scratch (there are some
>> commonalities). Options like "-D" and "-I" are fine, which is good because
>> then eg. target_include_directories() still works. But certain other flags
>> are just going to cause errors. How do I completely remove all compile
>> flags from the generated Makefiles and replace them with my own? I can do
>> this:
>>
>> set(CMAKE_C_FLAGS ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
>> set(CMAKE_C_FLAGS_DEBUG ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
>> set(CMAKE_C_FLAGS_RELEASE ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
>> set(CMAKE_C_FLAGS_RELWITHDEBINFO ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
>> set(CMAKE_C_FLAGS_MINSIZEREL ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
>>
>> But I *still* see flags in the generated makefiles that I didn't put
>> there such as "--compile_only" and "--c_file=...". How do I get rid of
>> these and specify what's correct for my toolchain? (Also, why do I need the
>> CACHE STRING "" FORCE options? I pulled that out of various Stackoverflow
>> posts but I have no idea why it's necessary. Is that documented? What about
>> the configurations... where are they listed? Do I have them all?)
>>
>>
> Regarding the CMAKE_<LANG>_FLAGS_<CONFIG> have a look at this blog post:
> https://cristianadam.eu/20190223/modifying-the-default-cmake-build-types/
>
> You "just" need to modify the CMAKE_<LANG>_FLAGS_<CONFIG>_INIT variables,
> no need to force the cache entries.
>
> The "Modules" CMake folder is your friend, you can see how CMake handles
> other compilers.
> For debugging use CMake's "--trace-expand" command line parameter.
>
> Cheers,
> Cristian.
>
>
Take a look at Modules/CMakeCInformation.cmake.
Also CMAKE_USER_MAKE_RULES_OVERRIDE may be useful to you.
There are a few others that may also be used depending on what languages
you are trying to use.

StackOverflow isn't always correct even if something is marked as answered
and up-voted.

FYI, The "--compile_only" and "--c_file" probably come from the file
Modules/Compiler/TI-C.cmake.  At some point TI compilers were using those
options to build files but I guess in your case the compiler is no longer
compatible with what it used to be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190223/1f4070bb/attachment-0001.html>

From marc.herbert at gmail.com  Mon Feb 25 14:41:07 2019
From: marc.herbert at gmail.com (Marc Herbert)
Date: Mon, 25 Feb 2019 11:41:07 -0800
Subject: [CMake] Better way than: SET(CMAKE_C_ARCHIVE_CREATE "<CMAKE_AR>
 my_flags ... ?
Message-ID: <CA+rkZbgsA4wi9ovyZmmp=CN_hasZrUMPhtXe+hLHuEqd70gL1Q@mail.gmail.com>

Hi,

1.  I found the hack below in the list's archive. However it seems...
hackish. Among others it can't _append_ a flag, it can only replace all
flags. Any newer and better way to append some extra flags?

2. Bonus question: how would you query "ar" and append some extra flags
*only* when ar/ranlib are new enough to support them?

Thanks in advance,

Marc

SET(CMAKE_C_ARCHIVE_CREATE "<CMAKE_AR> -qcD <TARGET> <LINK_FLAGS>
<OBJECTS>")
SET(CMAKE_C_ARCHIVE_FINISH "<CMAKE_RANLIB> -D <TARGET>")
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190225/3358047a/attachment.html>

From nick at appletonaudio.com  Mon Feb 25 21:56:35 2019
From: nick at appletonaudio.com (nick at appletonaudio.com)
Date: Tue, 26 Feb 2019 13:56:35 +1100
Subject: [CMake] include_extenal_msproject() dependency behavior change
 between 3.13.4 and 3.14.0-rc2 (possible bug in rc2)
Message-ID: <78cc55eac8fe2797e4f5fff59084bafe@appletonaudio.com>

Hello,

We have a fairly large CMake project which uses 
include_extenal_msproject() when we are producing Visual Studio 
solutions to bring in projects produced using another build metadata 
generator. We've noticed most of our Visual Studio builds have started 
failing after switching to CMake 3.14.0-rc2 (not sure where betweenn 
3.13.4 and 3.14.0-rc2 this issue was introduced).

An example of how the behavior differs can be realised with the 
following example:

dependencies/CMakeLists.txt:

# several duplications of the following block exist replacing fooN with 
foo1, foo2, foo3, etc.
add_library(fooN_cmake STATIC IMPORTED GLOBAL)
if(MSVC)
   include_external_msproject(fooN_cmake_extern "fooN.vcproj")
else()
   # other external things happen here using ExternalProject_add to end 
up creating fooN_cmake_extern for non-VS/non-Windows builds.
endif()
add_dependencies(fooN_cmake fooN_cmake_extern)
set_property(TARGET fooN_cmake PROPERTY INTERFACE_INCLUDE_DIRECTORIES 
"path to foo include files")
set_property(TARGET fooN_cmake PROPERTY IMPORTED_LOCATION_DEBUG "path to 
foo static library")
# ... more properties possibly set

frontend1/CMakeLists.txt:

add_subdirectory(../dependencies "${CMAKE_CURRENT_BINARY_DIR}/ext_deps" 
EXCLUDE_FROM_ALL)
add_executable(frontend1 main.c)
target_link_libraries(frontend1 foo1_cmake foo2_cmake)

frontend2/CMakeLists.txt:

add_subdirectory(../dependencies "${CMAKE_CURRENT_BINARY_DIR}/ext_deps" 
EXCLUDE_FROM_ALL)
add_executable(frontend2 main.c)
target_link_libraries(frontend2 foo3_cmake foo2_cmake)

The old behavior: we could invoke CMake using a source directory of 
frontend1 or frontend2 to get Visual Studio solutions. Only the Visual 
Studio projects which are imported using include_extenal_msproject() 
that are dependencies of that particular frontend are included in the 
solution i.e. the VS solution for frontend1 will not include foo3_cmake 
as part of the build at all. I expect this due to the use of 
EXCLUDE_FROM_ALL.

The new behavior: all frontends will include every single project 
defined using include_extenal_msproject that CMake encounters. They will 
all attempt to be built regardless of if there is a dependency. I would 
only have expected this behavior if EXCLUDE_FROM_ALL was *not* set when 
using add_subdirectory().

Could someone help me to understand if the behavior change is expected 
or if this is just a bug?

Thanks!

Nick Appleton

From craig.scott at crascit.com  Tue Feb 26 03:44:08 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Tue, 26 Feb 2019 19:44:08 +1100
Subject: [CMake] include_extenal_msproject() dependency behavior change
 between 3.13.4 and 3.14.0-rc2 (possible bug in rc2)
In-Reply-To: <78cc55eac8fe2797e4f5fff59084bafe@appletonaudio.com>
References: <78cc55eac8fe2797e4f5fff59084bafe@appletonaudio.com>
Message-ID: <CA+dygYn7BpzQSto+71+32FECL4w4OTGMJH2rkU_ZYKmyae=B4Q@mail.gmail.com>

If you're able to build CMake from sources yourself, you may want to check
if the changes from this merge request
<https://gitlab.kitware.com/cmake/cmake/merge_requests/2816> are what has
led to the change you're seeing. That relates to how the EXCLUDE_FROM_ALL
target property is initialised when a target is created.


On Tue, Feb 26, 2019 at 2:20 PM <nick at appletonaudio.com> wrote:

> Hello,
>
> We have a fairly large CMake project which uses
> include_extenal_msproject() when we are producing Visual Studio
> solutions to bring in projects produced using another build metadata
> generator. We've noticed most of our Visual Studio builds have started
> failing after switching to CMake 3.14.0-rc2 (not sure where betweenn
> 3.13.4 and 3.14.0-rc2 this issue was introduced).
>
> An example of how the behavior differs can be realised with the
> following example:
>
> dependencies/CMakeLists.txt:
>
> # several duplications of the following block exist replacing fooN with
> foo1, foo2, foo3, etc.
> add_library(fooN_cmake STATIC IMPORTED GLOBAL)
> if(MSVC)
>    include_external_msproject(fooN_cmake_extern "fooN.vcproj")
> else()
>    # other external things happen here using ExternalProject_add to end
> up creating fooN_cmake_extern for non-VS/non-Windows builds.
> endif()
> add_dependencies(fooN_cmake fooN_cmake_extern)
> set_property(TARGET fooN_cmake PROPERTY INTERFACE_INCLUDE_DIRECTORIES
> "path to foo include files")
> set_property(TARGET fooN_cmake PROPERTY IMPORTED_LOCATION_DEBUG "path to
> foo static library")
> # ... more properties possibly set
>
> frontend1/CMakeLists.txt:
>
> add_subdirectory(../dependencies "${CMAKE_CURRENT_BINARY_DIR}/ext_deps"
> EXCLUDE_FROM_ALL)
> add_executable(frontend1 main.c)
> target_link_libraries(frontend1 foo1_cmake foo2_cmake)
>
> frontend2/CMakeLists.txt:
>
> add_subdirectory(../dependencies "${CMAKE_CURRENT_BINARY_DIR}/ext_deps"
> EXCLUDE_FROM_ALL)
> add_executable(frontend2 main.c)
> target_link_libraries(frontend2 foo3_cmake foo2_cmake)
>
> The old behavior: we could invoke CMake using a source directory of
> frontend1 or frontend2 to get Visual Studio solutions. Only the Visual
> Studio projects which are imported using include_extenal_msproject()
> that are dependencies of that particular frontend are included in the
> solution i.e. the VS solution for frontend1 will not include foo3_cmake
> as part of the build at all. I expect this due to the use of
> EXCLUDE_FROM_ALL.
>
> The new behavior: all frontends will include every single project
> defined using include_extenal_msproject that CMake encounters. They will
> all attempt to be built regardless of if there is a dependency. I would
> only have expected this behavior if EXCLUDE_FROM_ALL was *not* set when
> using add_subdirectory().
>
> Could someone help me to understand if the behavior change is expected
> or if this is just a bug?
>
> Thanks!
>
> Nick Appleton
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>


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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190226/6c197ec7/attachment.html>

From nick at appletonaudio.com  Tue Feb 26 06:05:59 2019
From: nick at appletonaudio.com (nick at appletonaudio.com)
Date: Tue, 26 Feb 2019 22:05:59 +1100
Subject: [CMake] include_extenal_msproject() dependency behavior change
 between 3.13.4 and 3.14.0-rc2 (possible bug in rc2)
In-Reply-To: <CA+dygYn7BpzQSto+71+32FECL4w4OTGMJH2rkU_ZYKmyae=B4Q@mail.gmail.com>
References: <78cc55eac8fe2797e4f5fff59084bafe@appletonaudio.com>
 <CA+dygYn7BpzQSto+71+32FECL4w4OTGMJH2rkU_ZYKmyae=B4Q@mail.gmail.com>
Message-ID: <9356f18f75bfd776b936a749e2f9f873@appletonaudio.com>

Hi Craig,

Thanks for the info. I've verified that the revision you pointed me to 
(24b6e4830d9027e63db7dfafa500aaeb652d3a4c) is where the behavior broke 
(I built CMake using the revision directly before this one and 
everything still works fine). I'm no expert with CMake development - 
could someone chime in on whether what I am seeing is expected or 
whether something has inadvertently been broken?

Testing this is actually quite simple. There is no need to even have 
valid external vcproj files on the file system - CMake does not appear 
to care if they exist or not when generating the solution. The most 
trivial test I can give to reproduce the behavior is:

./CMakeLists.txt:
cmake_minimum_required(VERSION 3.4)
project(frontend_test)
add_subdirectory(deps "${CMAKE_CURRENT_BINARY_DIR}/ext_deps" 
EXCLUDE_FROM_ALL)
add_executable(frontend1 main.c)
target_link_libraries(frontend1 foo1_cmake)

./main.c:
/* nothing - unimportant for the test */

./deps/CMakeLists.txt:
cmake_minimum_required(VERSION 3.4)
add_library(foo1_cmake STATIC IMPORTED GLOBAL)
include_external_msproject(foo1_cmake_extern "foo1.vcproj")
add_dependencies(foo1_cmake foo1_cmake_extern)
set_property(TARGET foo1_cmake PROPERTY IMPORTED_LOCATION_DEBUG 
"foo1.lib")
add_library(foo2_cmake STATIC IMPORTED GLOBAL)
include_external_msproject(foo2_cmake_extern "foo2.vcproj")
add_dependencies(foo2_cmake foo2_cmake_extern)
set_property(TARGET foo2_cmake PROPERTY IMPORTED_LOCATION_DEBUG 
"foo2.lib")

Invoking CMake before revision 24b6e4830d9027e63db7dfafa500aaeb652d3a4c 
and opening the solution will show that Visual Studio would like to open 
foo1_cmake_extern (and it will show as unavailable in the solution 
explorer on account of the file not actually existing).

Invoking CMake at or after revision 
24b6e4830d9027e63db7dfafa500aaeb652d3a4c and opening the solution will 
show that Visual Studio would like to open foo1_cmake_extern AND 
foo2_cmake_extern (and both will show as unavailable in the solution 
explorer on account of the file not actually existing).

Just as an FYI for the mailing list (I don't actually care about this): 
I needed to update on my machine CMake (I was previously running version 
3.6) to build CMake. This might be acceptable - but I figured that CMake 
should have used cmake_version_minimum to indicate the version I was 
using was not new enough. I did not investigate, but 3.6 bombed out with 
the following:

C:\cmakegit\cmake\build> cmake .. -G "Visual Studio 14 2015 Win64"
CMake Error at Tests/RunCMake/CMakeLists.txt:279 (if):
   if given arguments:

     "(" "CMAKE_CXX_COMPILER_VERSION" "VERSION_GREATER_EQUAL" 
"19.0.24215.1" "AND" "CMAKE_CXX_COMPILER_VERSION" "VERSION_LESS" "19.10" 
")" "OR" "CMAKE_CXX_COMPILER_VERSION" "VERSION_GREATER_EQUAL" 
"19.10.25017"

   Unknown arguments specified

Nick Appleton

On 2019-02-26 19:44, Craig Scott wrote:
> If you're able to build CMake from sources yourself, you may want to
> check if the changes from this merge request [2] are what has led to
> the change you're seeing. That relates to how the EXCLUDE_FROM_ALL
> target property is initialised when a target is created.
> 
> On Tue, Feb 26, 2019 at 2:20 PM <nick at appletonaudio.com> wrote:
> 
>> Hello,
>> 
>> We have a fairly large CMake project which uses
>> include_extenal_msproject() when we are producing Visual Studio
>> solutions to bring in projects produced using another build metadata
>> 
>> generator. We've noticed most of our Visual Studio builds have
>> started
>> failing after switching to CMake 3.14.0-rc2 (not sure where betweenn
>> 
>> 3.13.4 and 3.14.0-rc2 this issue was introduced).
>> 
>> An example of how the behavior differs can be realised with the
>> following example:
>> 
>> dependencies/CMakeLists.txt:
>> 
>> # several duplications of the following block exist replacing fooN
>> with
>> foo1, foo2, foo3, etc.
>> add_library(fooN_cmake STATIC IMPORTED GLOBAL)
>> if(MSVC)
>> include_external_msproject(fooN_cmake_extern "fooN.vcproj")
>> else()
>> # other external things happen here using ExternalProject_add to
>> end
>> up creating fooN_cmake_extern for non-VS/non-Windows builds.
>> endif()
>> add_dependencies(fooN_cmake fooN_cmake_extern)
>> set_property(TARGET fooN_cmake PROPERTY
>> INTERFACE_INCLUDE_DIRECTORIES
>> "path to foo include files")
>> set_property(TARGET fooN_cmake PROPERTY IMPORTED_LOCATION_DEBUG
>> "path to
>> foo static library")
>> # ... more properties possibly set
>> 
>> frontend1/CMakeLists.txt:
>> 
>> add_subdirectory(../dependencies
>> "${CMAKE_CURRENT_BINARY_DIR}/ext_deps"
>> EXCLUDE_FROM_ALL)
>> add_executable(frontend1 main.c)
>> target_link_libraries(frontend1 foo1_cmake foo2_cmake)
>> 
>> frontend2/CMakeLists.txt:
>> 
>> add_subdirectory(../dependencies
>> "${CMAKE_CURRENT_BINARY_DIR}/ext_deps"
>> EXCLUDE_FROM_ALL)
>> add_executable(frontend2 main.c)
>> target_link_libraries(frontend2 foo3_cmake foo2_cmake)
>> 
>> The old behavior: we could invoke CMake using a source directory of
>> frontend1 or frontend2 to get Visual Studio solutions. Only the
>> Visual
>> Studio projects which are imported using include_extenal_msproject()
>> 
>> that are dependencies of that particular frontend are included in
>> the
>> solution i.e. the VS solution for frontend1 will not include
>> foo3_cmake
>> as part of the build at all. I expect this due to the use of
>> EXCLUDE_FROM_ALL.
>> 
>> The new behavior: all frontends will include every single project
>> defined using include_extenal_msproject that CMake encounters. They
>> will
>> all attempt to be built regardless of if there is a dependency. I
>> would
>> only have expected this behavior if EXCLUDE_FROM_ALL was *not* set
>> when
>> using add_subdirectory().
>> 
>> Could someone help me to understand if the behavior change is
>> expected
>> or if this is just a bug?
>> 
>> Thanks!
>> 
>> Nick Appleton
>> --
>> 
>> Powered by www.kitware.com [1]
>> 
>> 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:
>> https://cmake.org/mailman/listinfo/cmake
> 
> --
> 
> Craig Scott
> Melbourne, Australia
> https://crascit.com
> 
> Get the hand-book for every CMake user: Professional CMake: A
> Practical Guide [3]
> 
> 
> Links:
> ------
> [1] http://www.kitware.com
> [2] https://gitlab.kitware.com/cmake/cmake/merge_requests/2816
> [3] https://crascit.com/professional-cmake/

From craig.scott at crascit.com  Tue Feb 26 06:36:06 2019
From: craig.scott at crascit.com (Craig Scott)
Date: Tue, 26 Feb 2019 22:36:06 +1100
Subject: [CMake] include_extenal_msproject() dependency behavior change
 between 3.13.4 and 3.14.0-rc2 (possible bug in rc2)
In-Reply-To: <9356f18f75bfd776b936a749e2f9f873@appletonaudio.com>
References: <78cc55eac8fe2797e4f5fff59084bafe@appletonaudio.com>
 <CA+dygYn7BpzQSto+71+32FECL4w4OTGMJH2rkU_ZYKmyae=B4Q@mail.gmail.com>
 <9356f18f75bfd776b936a749e2f9f873@appletonaudio.com>
Message-ID: <CA+dygYki0KQF8=E8hbfriDXNrPnb4ddxQrSi4RH47Pwegp9dCw@mail.gmail.com>

On Tue, Feb 26, 2019 at 10:06 PM <nick at appletonaudio.com> wrote:

> Hi Craig,
>
> Thanks for the info. I've verified that the revision you pointed me to
> (24b6e4830d9027e63db7dfafa500aaeb652d3a4c) is where the behavior broke
> (I built CMake using the revision directly before this one and
> everything still works fine). I'm no expert with CMake development -
> could someone chime in on whether what I am seeing is expected or
> whether something has inadvertently been broken?
>
> Testing this is actually quite simple. There is no need to even have
> valid external vcproj files on the file system - CMake does not appear
> to care if they exist or not when generating the solution. The most
> trivial test I can give to reproduce the behavior is:
>
> ./CMakeLists.txt:
> cmake_minimum_required(VERSION 3.4)
> project(frontend_test)
> add_subdirectory(deps "${CMAKE_CURRENT_BINARY_DIR}/ext_deps"
> EXCLUDE_FROM_ALL)
> add_executable(frontend1 main.c)
> target_link_libraries(frontend1 foo1_cmake)
>
> ./main.c:
> /* nothing - unimportant for the test */
>
> ./deps/CMakeLists.txt:
> cmake_minimum_required(VERSION 3.4)
> add_library(foo1_cmake STATIC IMPORTED GLOBAL)
> include_external_msproject(foo1_cmake_extern "foo1.vcproj")
> add_dependencies(foo1_cmake foo1_cmake_extern)
> set_property(TARGET foo1_cmake PROPERTY IMPORTED_LOCATION_DEBUG
> "foo1.lib")
> add_library(foo2_cmake STATIC IMPORTED GLOBAL)
> include_external_msproject(foo2_cmake_extern "foo2.vcproj")
> add_dependencies(foo2_cmake foo2_cmake_extern)
> set_property(TARGET foo2_cmake PROPERTY IMPORTED_LOCATION_DEBUG
> "foo2.lib")
>
> Invoking CMake before revision 24b6e4830d9027e63db7dfafa500aaeb652d3a4c
> and opening the solution will show that Visual Studio would like to open
> foo1_cmake_extern (and it will show as unavailable in the solution
> explorer on account of the file not actually existing).
>
> Invoking CMake at or after revision
> 24b6e4830d9027e63db7dfafa500aaeb652d3a4c and opening the solution will
> show that Visual Studio would like to open foo1_cmake_extern AND
> foo2_cmake_extern (and both will show as unavailable in the solution
> explorer on account of the file not actually existing).
>

Thanks, I've recorded this in the bug tracker as issue 18986
<https://gitlab.kitware.com/cmake/cmake/issues/18986>




> Just as an FYI for the mailing list (I don't actually care about this):
> I needed to update on my machine CMake (I was previously running version
> 3.6) to build CMake. This might be acceptable - but I figured that CMake
> should have used cmake_version_minimum to indicate the version I was
> using was not new enough. I did not investigate, but 3.6 bombed out with
> the following:
>
> C:\cmakegit\cmake\build> cmake .. -G "Visual Studio 14 2015 Win64"
> CMake Error at Tests/RunCMake/CMakeLists.txt:279 (if):
>    if given arguments:
>
>      "(" "CMAKE_CXX_COMPILER_VERSION" "VERSION_GREATER_EQUAL"
> "19.0.24215.1" "AND" "CMAKE_CXX_COMPILER_VERSION" "VERSION_LESS" "19.10"
> ")" "OR" "CMAKE_CXX_COMPILER_VERSION" "VERSION_GREATER_EQUAL"
> "19.10.25017"
>
>    Unknown arguments specified
>

This looks unintentional too. Recorded as issue 18987
<https://gitlab.kitware.com/cmake/cmake/issues/18987>.



>
> Nick Appleton
>
> On 2019-02-26 19:44, Craig Scott wrote:
> > If you're able to build CMake from sources yourself, you may want to
> > check if the changes from this merge request [2] are what has led to
> > the change you're seeing. That relates to how the EXCLUDE_FROM_ALL
> > target property is initialised when a target is created.
> >
> > On Tue, Feb 26, 2019 at 2:20 PM <nick at appletonaudio.com> wrote:
> >
> >> Hello,
> >>
> >> We have a fairly large CMake project which uses
> >> include_extenal_msproject() when we are producing Visual Studio
> >> solutions to bring in projects produced using another build metadata
> >>
> >> generator. We've noticed most of our Visual Studio builds have
> >> started
> >> failing after switching to CMake 3.14.0-rc2 (not sure where betweenn
> >>
> >> 3.13.4 and 3.14.0-rc2 this issue was introduced).
> >>
> >> An example of how the behavior differs can be realised with the
> >> following example:
> >>
> >> dependencies/CMakeLists.txt:
> >>
> >> # several duplications of the following block exist replacing fooN
> >> with
> >> foo1, foo2, foo3, etc.
> >> add_library(fooN_cmake STATIC IMPORTED GLOBAL)
> >> if(MSVC)
> >> include_external_msproject(fooN_cmake_extern "fooN.vcproj")
> >> else()
> >> # other external things happen here using ExternalProject_add to
> >> end
> >> up creating fooN_cmake_extern for non-VS/non-Windows builds.
> >> endif()
> >> add_dependencies(fooN_cmake fooN_cmake_extern)
> >> set_property(TARGET fooN_cmake PROPERTY
> >> INTERFACE_INCLUDE_DIRECTORIES
> >> "path to foo include files")
> >> set_property(TARGET fooN_cmake PROPERTY IMPORTED_LOCATION_DEBUG
> >> "path to
> >> foo static library")
> >> # ... more properties possibly set
> >>
> >> frontend1/CMakeLists.txt:
> >>
> >> add_subdirectory(../dependencies
> >> "${CMAKE_CURRENT_BINARY_DIR}/ext_deps"
> >> EXCLUDE_FROM_ALL)
> >> add_executable(frontend1 main.c)
> >> target_link_libraries(frontend1 foo1_cmake foo2_cmake)
> >>
> >> frontend2/CMakeLists.txt:
> >>
> >> add_subdirectory(../dependencies
> >> "${CMAKE_CURRENT_BINARY_DIR}/ext_deps"
> >> EXCLUDE_FROM_ALL)
> >> add_executable(frontend2 main.c)
> >> target_link_libraries(frontend2 foo3_cmake foo2_cmake)
> >>
> >> The old behavior: we could invoke CMake using a source directory of
> >> frontend1 or frontend2 to get Visual Studio solutions. Only the
> >> Visual
> >> Studio projects which are imported using include_extenal_msproject()
> >>
> >> that are dependencies of that particular frontend are included in
> >> the
> >> solution i.e. the VS solution for frontend1 will not include
> >> foo3_cmake
> >> as part of the build at all. I expect this due to the use of
> >> EXCLUDE_FROM_ALL.
> >>
> >> The new behavior: all frontends will include every single project
> >> defined using include_extenal_msproject that CMake encounters. They
> >> will
> >> all attempt to be built regardless of if there is a dependency. I
> >> would
> >> only have expected this behavior if EXCLUDE_FROM_ALL was *not* set
> >> when
> >> using add_subdirectory().
> >>
> >> Could someone help me to understand if the behavior change is
> >> expected
> >> or if this is just a bug?
> >>
> >> Thanks!
> >>
> >> Nick Appleton
>
> >
> > Links:
> > ------
> > [1] http://www.kitware.com
> > [2] https://gitlab.kitware.com/cmake/cmake/merge_requests/2816
>

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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-cmake/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190226/aec7e233/attachment.html>

From mathieu.garaud at gmail.com  Tue Feb 26 10:30:21 2019
From: mathieu.garaud at gmail.com (Mathieu Garaud)
Date: Tue, 26 Feb 2019 16:30:21 +0100
Subject: [CMake] Compilation Error: Modern Compiler + Old STL
Message-ID: <CAHesz5r76Q3L1JYDxXo1_EnJnwYZwxNHKEKJMO3q7_JFH4ojeg@mail.gmail.com>

Hello,

While compiling cmake3.13.4 using pkgsrc I had an error because I'm using a
new version of clang7.0.1 witth an old version of libstdc++5.4.0.

I propose to change the preprocess tests using __cplusplus >= xxx  in
Source/cmAlgorithms.h by their appropriate define like you do for
unique_ptr using: CMake_HAVE_CXX_UNIQUE_PTR.

To make it work you need to add the extra cm_check_cxx_feature
in Source/Checks/cm_cxx_features.cmake and the test files in
Source/Checks: cm_cxx_size_t.cxx, cm_cxx_cbegin.cxx and cm_cxx_cend.cxx.

I attached the files I modified as example it won't take more than 15min to
diff, integrate and commit I promise. What do you think?

Best,

Mathieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190226/4399ecf7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cm_cxx_cbegin.cxx
Type: application/octet-stream
Size: 102 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190226/4399ecf7/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cm_cxx_size_t.cxx
Type: application/octet-stream
Size: 85 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190226/4399ecf7/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cm_cxx_features.cmake
Type: application/octet-stream
Size: 2796 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190226/4399ecf7/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cm_cxx_cend.cxx
Type: application/octet-stream
Size: 106 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190226/4399ecf7/attachment-0008.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmAlgorithms.h
Type: application/octet-stream
Size: 10289 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20190226/4399ecf7/attachment-0009.obj>

From roeber at dkrz.de  Wed Feb 27 04:51:46 2019
From: roeber at dkrz.de (=?UTF-8?Q?Niklas_R=c3=b6ber?=)
Date: Wed, 27 Feb 2019 10:51:46 +0100
Subject: [CMake] Can not find MPI ...
Message-ID: <e74f8c9a-c6f0-38bf-ce1d-aaf5aa93a147@dkrz.de>

Hi,

since the last makeover of CMake for ParaView, I have trouble with MPI 
configuration, similar as described in here:

https://gitlab.kitware.com/cmake/cmake/issues/18570

I made an entry onto ParaView's discourse two weeks ago with no response:

https://discourse.paraview.org/t/could-not-find-mpi/1285

It appears that all libraries and compilers are found, for C++ and 
Fortran, yet I still get that message that something is wrong. On our 
HPC system, we can't use the native compilers and need to resort to 
others. It is not life threatening, but I can't use the last version of 
ParaView which has some features that I need. I am not sure if this will 
be resolved for their next release, but maybe anybody of you has an 
idea, or even better, a workaround?

Looking forward to any replay!

Thanks and Cheers from Hamburg, Niklas


-- 
______________________________________________

Dr. Niklas R?ber
Visualisierung
Abteilung Anwendungen

Deutsches Klimarechenzentrum GmbH (DKRZ)
Bundesstra?e 45 a ? D-20146 Hamburg ? Germany

email: roeber at dkrz.de
phone: +49 (0)40 460094 283
   fax: +49 (0)40 460094 270
   web: http://www.dkrz.de/
   
Gesch?ftsf?hrer: Prof. Dr. Thomas Ludwig
Sitz der Gesellschaft: Hamburg
Amtsgericht Hamburg HRB 39784
______________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190227/1fe1e107/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5339 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://cmake.org/pipermail/cmake/attachments/20190227/1fe1e107/attachment.bin>

From robert.maynard at kitware.com  Wed Feb 27 08:39:53 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 27 Feb 2019 08:39:53 -0500
Subject: [CMake] Getting the path to object files?
In-Reply-To: <5eaedde5735d330e0783975625676d9229ab1be3.camel@mad-scientist.net>
References: <5eaedde5735d330e0783975625676d9229ab1be3.camel@mad-scientist.net>
Message-ID: <CAFzjYVqM8pYXGKeYd+_Xuo3QGg=SPVennMOnZG_Uve2wSmBYDg@mail.gmail.com>

CMake only provides an official way to get the location of the object
files for OBJECT targets ( $<TARGET_OBJECTS:objLib> ). For other
target types the location is an implementation detail.

On Sat, Feb 23, 2019 at 3:24 PM Paul Smith <paul at mad-scientist.net> wrote:
>
> Hi all.  I'm using CMake 3.13.4 across Linux, MacOS, and Windows, with
> various generators.
>
> I need to write a script (this only runs on Linux actually) that will
> do some processing on all the object files in a shared library and
> generate a linker version file.  I'm trying to write a custom command
> using PRE_LINK that will invoke that script and pass along enough
> information to find all those object files so it can generate the
> version file, and I can't come up with it.
>
> For example, using a Makefile generator for a file "libsrc.cpp" built
> for a library "solib" in a directory "LibDir" on Linux my object file
> paths look like:
>
>   LibDir/CMakeFiles/solib.dir/libsrc.cpp.o
>
> I can use something like this:
>
>   get_target_property(srcs solib SOURCES)
>
>   add_custom_command(TARGET solib PRE_LINK
>       COMMAND foo ${srcs}
>       VERBATIM)
>
> (for some reason if I try to use a generator expression like
> $<TARGET_PROPERTY:SOURCES> etc. it's always passed as a single quoted
> argument and I can't figure out how break it up, but if I use
> get_target_property() then it works correctly).
>
> However this only gives me the source file names, not the object file
> names, and no directory information to search.  My problem is I'm
> actually compiling these same source files multiple times in different
> ways for different libraries, so I can't just search for "libsrc.cpp.o"
> I need to get this particular .o.
>
> So then I added $<TARGET_PROPERTY:BINARY_DIR> which looked promising,
> but it only gives me the path to the source directory; i.e. above it
> gives me LibDir.
>
> I tried lots of different likely-looking properties, but I can't find
> any property which will tell me the path I'm looking for.
>
> Can I get CMake to tell me the path where the object files being
> created will be put for a given target?  Or do I just need to hard-code
> it based on my observations of how cmake generators actually create the
> output?
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake

From brad.king at kitware.com  Wed Feb 27 09:00:37 2019
From: brad.king at kitware.com (Brad King)
Date: Wed, 27 Feb 2019 09:00:37 -0500
Subject: [CMake] Compilation Error: Modern Compiler + Old STL
In-Reply-To: <CAHesz5r76Q3L1JYDxXo1_EnJnwYZwxNHKEKJMO3q7_JFH4ojeg@mail.gmail.com>
References: <CAHesz5r76Q3L1JYDxXo1_EnJnwYZwxNHKEKJMO3q7_JFH4ojeg@mail.gmail.com>
Message-ID: <24350a13-203a-f6ed-713a-94e988be8dc1@kitware.com>

On 2/26/19 10:30 AM, Mathieu Garaud wrote:
> While compiling cmake3.13.4 using pkgsrc I had an error because I'm using a
> new version of clang7.0.1 witth an old version of libstdc++5.4.0.

Thanks.  For reference in list archives, Mathieu opened a MR here:

  https://gitlab.kitware.com/cmake/cmake/merge_requests/3030

-Brad

From robert.maynard at kitware.com  Wed Feb 27 09:00:11 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 27 Feb 2019 09:00:11 -0500
Subject: [CMake] CUDA language support with host compiler flags
In-Reply-To: <565fd4e9-fa49-d576-3469-9e9ff9f67d90@numalliance.com>
References: <1542223442.2988574.1550762626182.ref@mail.yahoo.com>
 <565fd4e9-fa49-d576-3469-9e9ff9f67d90@numalliance.com>
Message-ID: <CAFzjYVqRUDOcvVZVvoU7JXi1tAwGQUe=gJJkp4UGH7N72k0H5g@mail.gmail.com>

You need to guard the flags with `$<COMPILE_LANGUAGE:CXX>` the
evaluation on a given compiler id is done for all sources of a target,
and not on each target source file.

So you will need something like:

set(cxx_flags "$<$<OR:$<CXX_COMPILER_ID:GNU>,$<CXX_COMPILER_ID:Clang>>:-Wall
-Wextra -pedantic>
                                               $<$<CXX_COMPILER_ID:MSVC>:/W4")
target_compile_options(${PROJECT_NAME} PRIVATE
$<$<COMPILE_LANGUAGE:CXX>:${cxx_flags}>)

On Fri, Feb 22, 2019 at 4:11 AM M?t? Ferenc Nagy-Egri via CMake
<cmake at cmake.org> wrote:
>
> Hi All!
>
> I am trying to compile CUDA code with controlling both host and device compiler flags.
>
> Currently my CMakeLists.txt looks like:
>
> ```
> cmake_minimum_required(VERSION 3.8) # CUDA language support
>
> project(CUDA_test LANGUAGES CXX CUDA)
>
> if (MSVC)
>   string(REGEX REPLACE "/W[0-9]" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
> endif (MSVC)
>
> set(Hdrs)
>
> set(Srcs Main.cu)
>
> add_executable(${PROJECT_NAME} ${Hdrs} ${Srcs})
>
> target_include_directories(${PROJECT_NAME} PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})
>
> target_compile_options(${PROJECT_NAME} PRIVATE $<$<OR:$<CXX_COMPILER_ID:GNU>,$<CXX_COMPILER_ID:Clang>>:-Wall -Wextra -pedantic>
>                                                $<$<CXX_COMPILER_ID:MSVC>:/W4>)
>
> set_target_properties(${PROJECT_NAME} PROPERTIES CUDA_SEPARABLE_COMPILATION ON
>                                                  CUDA_STANDARD 14
>                                                  CUDA_STANDARD_REQUIRED ON
>                                                  CUDA_EXTENSIONS OFF
>                                                  CXX_STANDARD 14
>                                                  CXX_STANDARD_REQUIRED ON
>                                                  CXX_EXTENSIONS OFF)
>
> source_group ("Headers" FILES ${Hdrs})
> source_group ("Sources" FILES ${Srcs})
> ```
>
> However, when I compile the code I get the following error:
>
> [1/3] Building CUDA object CMakeFiles/CUDA_test.dir/Main.cu.o
> FAILED: CMakeFiles/CUDA_test.dir/Main.cu.o
> /usr/bin/nvcc   -I/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL -g   -Wall -Wextra -pedantic -std=c++14 -x cu -dc /var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL/Main.cu -o CMakeFiles/CUDA_test.dir/Main.cu.o && /usr/bin/nvcc   -I/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL -g   -Wall -Wextra -pedantic -std=c++14 -x cu -M /var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL/Main.cu -MT CMakeFiles/CUDA_test.dir/Main.cu.o -o CMakeFiles/CUDA_test.dir/Main.cu.o.d
> nvcc fatal   : Unknown option 'Wall'
> ninja: build stopped: subcommand failed.
>
> CMake seems to pass -Wall -Wextra -pedantic to the device compiler as well, even though it is neither GNU nor Clang, but CUDA. How can I specify warning and similar flags separatly for the host and device compilers?
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake

From robert.maynard at kitware.com  Wed Feb 27 09:03:17 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 27 Feb 2019 09:03:17 -0500
Subject: [CMake] transitive interface dependency problem
In-Reply-To: <20190221114856.140549jeidxfmzvc@email.fit.vutbr.cz>
References: <20190221114856.140549jeidxfmzvc@email.fit.vutbr.cz>
Message-ID: <CAFzjYVr5V7jQ-DHH7YwPN8OMmt83Ty+cwdjioWogHdPoy_1rkg@mail.gmail.com>

If `interfaceDep` is an actual interface target, consuming libraries
of libA inside the project ( example ) should resolve it as an
interface target and not drop it on the lnik line.

If you have a small self contained example that would help track down
this issue.

On Thu, Feb 21, 2019 at 5:49 AM Starka Tom?? <starka at fit.vutbr.cz> wrote:
>
> Hi all,
> following my previous post 'link only with targets feature' I have
> found yet another unpleasant consequence of not being able to tell
> cmake that it is the target name in the parameters of
> target_link_libraries (without the use of :: notation, that is
> optional and inconsistent). When I have library A which have an
> interface dependency interfaceDep and when using the export sets to
> automaticaly generate the configs while simultaneously internaly
> building an example app that is using lib A. I have encountered the
> following problem:
>   In the cmake of lib A I do NOT search for the interfaceDep since
> there is no reason to, because the lib A compiles and links without
> it. But to relate that dependency to autogenerated config I need to
> state target_link_libraries(A INTERFACE interfaceDep), and then, for
> downstreamers, I need to handle the finding of it by hand in the
> config before the *Targets.cmake gets included (that's kind of ok and
> could be automated by cmake if we had consistent target naming
> syntax). Back to the build tree of the project for lib A. In the later
> subdirectories where I build an example app the
> target_link_libraries(example A) makes it wants interfaceDep.lib
> (which is non-existent since its only interface lib) eventhough there
> is correct interfaceDep target found prior to that in the app cmake.
> The thing is that the interfaceDep is resolved not in the application
> cmake but in the lib A cmake where there is no target of that name and
> the target_link_libraries doesn't know that it is supposed to be a
> target. I hope I didn't lost you yet.
> I have come with two solutions. One is to not use INTERFACE
> dependencies ever and injecting them by hand in the config scripts for
> downstreamers - which seems more dirty and confusing and then in the
> same buildtree doing the same for all the apps/libs that uses lib A.
> The other solution is to create a dummy target -
> add_library(interfaceDep INTERFACE IMPORTED) in the lib A cmake just
> before you call target_link_libraries(A INTERFACE interfaceDep), which
> is less dirty but dirty nontheless.
> Is there any other idiomatic approach? And NOTE that "use
> interfaceDep::interfaceDep" named target is not possible since it
> could be target created by 3rd party and you can't alias an IMPORTED
> target ;) (e.g. glm). It would realy help if there would be a 'link
> only with targets feature' in the cmake with all the consequences.
> If you see it fit, you can also forward this to the developer only
> mailing-list. But I've started a new thread since it opens (and
> possibly resolves) a new isssue.
>
> Hope posing these points will help
> forry
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake

From paul at mad-scientist.net  Wed Feb 27 09:06:54 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Wed, 27 Feb 2019 09:06:54 -0500
Subject: [CMake] Getting the path to object files?
In-Reply-To: <CAFzjYVqM8pYXGKeYd+_Xuo3QGg=SPVennMOnZG_Uve2wSmBYDg@mail.gmail.com>
References: <5eaedde5735d330e0783975625676d9229ab1be3.camel@mad-scientist.net>
 <CAFzjYVqM8pYXGKeYd+_Xuo3QGg=SPVennMOnZG_Uve2wSmBYDg@mail.gmail.com>
Message-ID: <8984e4ea069426835c2328a85d656537337fc857.camel@mad-scientist.net>

On Wed, 2019-02-27 at 08:39 -0500, Robert Maynard wrote:
> CMake only provides an official way to get the location of the object
> files for OBJECT targets ( $<TARGET_OBJECTS:objLib> ). For other
> target types the location is an implementation detail.

Yes, but sometimes (as in my case) I need to know it :).  I need to
examine the object files as part of my link processing.

Exactly _because_ it's an implementation detail, it would be nice if
there were some way to retrieve it from CMake.  I can file an
enhancement request if that seems appropriate.

I could use an OBJECT target if it weren't for the Xcode restriction
that a STATIC or SHARED library must have at least one source file and
can't consist solely of an OBJECT library.

I'm hopeful we can throw away our MacOS builds entirely but until that
happens...


Thanks for the reply Robert!


From robert.maynard at kitware.com  Wed Feb 27 09:34:59 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 27 Feb 2019 09:34:59 -0500
Subject: [CMake] Getting the path to object files?
In-Reply-To: <8984e4ea069426835c2328a85d656537337fc857.camel@mad-scientist.net>
References: <5eaedde5735d330e0783975625676d9229ab1be3.camel@mad-scientist.net>
 <CAFzjYVqM8pYXGKeYd+_Xuo3QGg=SPVennMOnZG_Uve2wSmBYDg@mail.gmail.com>
 <8984e4ea069426835c2328a85d656537337fc857.camel@mad-scientist.net>
Message-ID: <CAFzjYVpEVXyzu9RKHuwJaRGhAt8wSqrwENEnEQ9-xkoFiRH3nw@mail.gmail.com>

You can file an enhancement request that the $<TARGET_OBJECTS>
generator expression to be relaxed to include STATIC, SHARED, and
MODULE libraries.

My suggestion is that a dummy source file to workaround the Xcode
limitation on targets, is not as hacky
as reverse engineering the object file locations.


On Wed, Feb 27, 2019 at 9:06 AM Paul Smith <paul at mad-scientist.net> wrote:
>
> On Wed, 2019-02-27 at 08:39 -0500, Robert Maynard wrote:
> > CMake only provides an official way to get the location of the object
> > files for OBJECT targets ( $<TARGET_OBJECTS:objLib> ). For other
> > target types the location is an implementation detail.
>
> Yes, but sometimes (as in my case) I need to know it :).  I need to
> examine the object files as part of my link processing.
>
> Exactly _because_ it's an implementation detail, it would be nice if
> there were some way to retrieve it from CMake.  I can file an
> enhancement request if that seems appropriate.
>
> I could use an OBJECT target if it weren't for the Xcode restriction
> that a STATIC or SHARED library must have at least one source file and
> can't consist solely of an OBJECT library.
>
> I'm hopeful we can throw away our MacOS builds entirely but until that
> happens...
>
>
> Thanks for the reply Robert!
>

From marc.herbert at gmail.com  Wed Feb 27 19:03:19 2019
From: marc.herbert at gmail.com (Marc Herbert)
Date: Wed, 27 Feb 2019 16:03:19 -0800
Subject: [CMake] FindPkgConfig and using -m32 on Linux
In-Reply-To: <4226a004-ea8d-6318-e9e8-871b056bf623@swi-prolog.org>
References: <4226a004-ea8d-6318-e9e8-871b056bf623@swi-prolog.org>
Message-ID: <8E521C09-380D-489D-B035-E516066A2A87@gmail.com>



> On 17 Jan 2019, at 04:57, Jan Wielemaker <jan at swi-prolog.org> wrote:
> 
> I got very far using
> 
>    set(CMAKE_C_FLAGS -m32)

Maybe not going to solve your main issue but worth changing anyway to:

set(CMAKE_C_FLAGS              "-m32 ${CMAKE_C_FLAGS}")

With your previous and simpler code, passing any cmake -DCMAKE_C_FLAGS_RELEASE/DEBUG/etc. on the command line will still work except for the ?empty? one! Very confusing and learned the hard way :-)


You also want:
set(CMAKE_ASM_FLAGS            "-m32 ${CMAKE_ASM_FLAGS}")
set(CMAKE_CXX_FLAGS            "-m32 ${CMAKE_CXX_FLAGS}")

other?




From csiga.biga at aol.com  Thu Feb 28 08:13:41 2019
From: csiga.biga at aol.com (=?utf-8?Q?M=C3=A1t=C3=A9_Ferenc_Nagy-Egri?=)
Date: Thu, 28 Feb 2019 14:13:41 +0100
Subject: [CMake] CUDA language support with host compiler flags
In-Reply-To: <CAFzjYVqRUDOcvVZVvoU7JXi1tAwGQUe=gJJkp4UGH7N72k0H5g@mail.gmail.com>
References: <1542223442.2988574.1550762626182.ref@mail.yahoo.com>
 <565fd4e9-fa49-d576-3469-9e9ff9f67d90@numalliance.com>
 <CAFzjYVqRUDOcvVZVvoU7JXi1tAwGQUe=gJJkp4UGH7N72k0H5g@mail.gmail.com>
Message-ID: <mailman.0.1551359627.2630.cmake@cmake.org>

Hi Robert!

Thank you for the help. I don?t know if I could?ve find that solution myself. I guess selecting CUDA as the COMPILE_LANGUAGE I can controll .cu compiler options to select architecture and what not.

Anyhow, if someone needed the minimal template, here it is:

https://gist.github.com/MathiasMagnus/0edacac888a758fe233cb69f3e291d62

Cheers,
M?t?

Felad?: Robert Maynard
Elk?ldve: 2019. febru?r 27., szerda 15:00
C?mzett: Nagy-Egri M??t?? Ferenc
M?solatot kap: CMake MailingList
T?rgy: Re: [CMake] CUDA language support with host compiler flags

You need to guard the flags with `$<COMPILE_LANGUAGE:CXX>` the
evaluation on a given compiler id is done for all sources of a target,
and not on each target source file.

So you will need something like:

set(cxx_flags "$<$<OR:$<CXX_COMPILER_ID:GNU>,$<CXX_COMPILER_ID:Clang>>:-Wall
-Wextra -pedantic>
                                               $<$<CXX_COMPILER_ID:MSVC>:/W4")
target_compile_options(${PROJECT_NAME} PRIVATE
$<$<COMPILE_LANGUAGE:CXX>:${cxx_flags}>)

On Fri, Feb 22, 2019 at 4:11 AM M?t? Ferenc Nagy-Egri via CMake
<cmake at cmake.org> wrote:
>
> Hi All!
>
> I am trying to compile CUDA code with controlling both host and device compiler flags.
>
> Currently my CMakeLists.txt looks like:
>
> ```
> cmake_minimum_required(VERSION 3.8) # CUDA language support
>
> project(CUDA_test LANGUAGES CXX CUDA)
>
> if (MSVC)
>   string(REGEX REPLACE "/W[0-9]" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
> endif (MSVC)
>
> set(Hdrs)
>
> set(Srcs Main.cu)
>
> add_executable(${PROJECT_NAME} ${Hdrs} ${Srcs})
>
> target_include_directories(${PROJECT_NAME} PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})
>
> target_compile_options(${PROJECT_NAME} PRIVATE $<$<OR:$<CXX_COMPILER_ID:GNU>,$<CXX_COMPILER_ID:Clang>>:-Wall -Wextra -pedantic>
>                                                $<$<CXX_COMPILER_ID:MSVC>:/W4>)
>
> set_target_properties(${PROJECT_NAME} PROPERTIES CUDA_SEPARABLE_COMPILATION ON
>                                                  CUDA_STANDARD 14
>                                                  CUDA_STANDARD_REQUIRED ON
>                                                  CUDA_EXTENSIONS OFF
>                                                  CXX_STANDARD 14
>                                                  CXX_STANDARD_REQUIRED ON
>                                                  CXX_EXTENSIONS OFF)
>
> source_group ("Headers" FILES ${Hdrs})
> source_group ("Sources" FILES ${Srcs})
> ```
>
> However, when I compile the code I get the following error:
>
> [1/3] Building CUDA object CMakeFiles/CUDA_test.dir/Main.cu.o
> FAILED: CMakeFiles/CUDA_test.dir/Main.cu.o
> /usr/bin/nvcc   -I/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL -g   -Wall -Wextra -pedantic -std=c++14 -x cu -dc /var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL/Main.cu -o CMakeFiles/CUDA_test.dir/Main.cu.o && /usr/bin/nvcc   -I/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL -g   -Wall -Wextra -pedantic -std=c++14 -x cu -M /var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL/Main.cu -MT CMakeFiles/CUDA_test.dir/Main.cu.o -o CMakeFiles/CUDA_test.dir/Main.cu.o.d
> nvcc fatal   : Unknown option 'Wall'
> ninja: build stopped: subcommand failed.
>
> CMake seems to pass -Wall -Wextra -pedantic to the device compiler as well, even though it is neither GNU nor Clang, but CUDA. How can I specify warning and similar flags separatly for the host and device compilers?
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20190228/69107dfe/attachment.html>

From robert.maynard at kitware.com  Thu Feb 28 08:52:55 2019
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 28 Feb 2019 08:52:55 -0500
Subject: [CMake] CUDA language support with host compiler flags
In-Reply-To: <5c77de87.1c69fb81.c1dec.04fdSMTPIN_ADDED_MISSING@mx.google.com>
References: <1542223442.2988574.1550762626182.ref@mail.yahoo.com>
 <565fd4e9-fa49-d576-3469-9e9ff9f67d90@numalliance.com>
 <CAFzjYVqRUDOcvVZVvoU7JXi1tAwGQUe=gJJkp4UGH7N72k0H5g@mail.gmail.com>
 <5c77de87.1c69fb81.c1dec.04fdSMTPIN_ADDED_MISSING@mx.google.com>
Message-ID: <CAFzjYVo25gpB0y5vc3E8TvT4Ustm6ddUrhEKgcHnptRe5dcubw@mail.gmail.com>

Currently to get proper propagation of architecture flags such as
-arch=sm_50,  -compute=compute_X  you need to place these into the
CMAKE_CUDA_FLAGS. This is a known issue, as flags specified by
`target_compile_options` are not propagate to the device linking step,
which needs the correct architecture flags.


On Thu, Feb 28, 2019 at 8:13 AM M?t? Ferenc Nagy-Egri
<csiga.biga at aol.com> wrote:
>
> Hi Robert!
>
>
>
> Thank you for the help. I don?t know if I could?ve find that solution myself. I guess selecting CUDA as the COMPILE_LANGUAGE I can controll .cu compiler options to select architecture and what not.
>
>
>
> Anyhow, if someone needed the minimal template, here it is:
>
>
>
> https://gist.github.com/MathiasMagnus/0edacac888a758fe233cb69f3e291d62
>
>
>
> Cheers,
>
> M?t?
>
>
>
> Felad?: Robert Maynard
> Elk?ldve: 2019. febru?r 27., szerda 15:00
> C?mzett: Nagy-Egri M??t?? Ferenc
> M?solatot kap: CMake MailingList
> T?rgy: Re: [CMake] CUDA language support with host compiler flags
>
>
>
> You need to guard the flags with `$<COMPILE_LANGUAGE:CXX>` the
>
> evaluation on a given compiler id is done for all sources of a target,
>
> and not on each target source file.
>
>
>
> So you will need something like:
>
>
>
> set(cxx_flags "$<$<OR:$<CXX_COMPILER_ID:GNU>,$<CXX_COMPILER_ID:Clang>>:-Wall
>
> -Wextra -pedantic>
>
>                                                $<$<CXX_COMPILER_ID:MSVC>:/W4")
>
> target_compile_options(${PROJECT_NAME} PRIVATE
>
> $<$<COMPILE_LANGUAGE:CXX>:${cxx_flags}>)
>
>
>
> On Fri, Feb 22, 2019 at 4:11 AM M?t? Ferenc Nagy-Egri via CMake
>
> <cmake at cmake.org> wrote:
>
> >
>
> > Hi All!
>
> >
>
> > I am trying to compile CUDA code with controlling both host and device compiler flags.
>
> >
>
> > Currently my CMakeLists.txt looks like:
>
> >
>
> > ```
>
> > cmake_minimum_required(VERSION 3.8) # CUDA language support
>
> >
>
> > project(CUDA_test LANGUAGES CXX CUDA)
>
> >
>
> > if (MSVC)
>
> >   string(REGEX REPLACE "/W[0-9]" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
>
> > endif (MSVC)
>
> >
>
> > set(Hdrs)
>
> >
>
> > set(Srcs Main.cu)
>
> >
>
> > add_executable(${PROJECT_NAME} ${Hdrs} ${Srcs})
>
> >
>
> > target_include_directories(${PROJECT_NAME} PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})
>
> >
>
> > target_compile_options(${PROJECT_NAME} PRIVATE $<$<OR:$<CXX_COMPILER_ID:GNU>,$<CXX_COMPILER_ID:Clang>>:-Wall -Wextra -pedantic>
>
> >                                                $<$<CXX_COMPILER_ID:MSVC>:/W4>)
>
> >
>
> > set_target_properties(${PROJECT_NAME} PROPERTIES CUDA_SEPARABLE_COMPILATION ON
>
> >                                                  CUDA_STANDARD 14
>
> >                                                  CUDA_STANDARD_REQUIRED ON
>
> >                                                  CUDA_EXTENSIONS OFF
>
> >                                                  CXX_STANDARD 14
>
> >                                                  CXX_STANDARD_REQUIRED ON
>
> >                                                  CXX_EXTENSIONS OFF)
>
> >
>
> > source_group ("Headers" FILES ${Hdrs})
>
> > source_group ("Sources" FILES ${Srcs})
>
> > ```
>
> >
>
> > However, when I compile the code I get the following error:
>
> >
>
> > [1/3] Building CUDA object CMakeFiles/CUDA_test.dir/Main.cu.o
>
> > FAILED: CMakeFiles/CUDA_test.dir/Main.cu.o
>
> > /usr/bin/nvcc   -I/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL -g   -Wall -Wextra -pedantic -std=c++14 -x cu -dc /var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL/Main.cu -o CMakeFiles/CUDA_test.dir/Main.cu.o && /usr/bin/nvcc   -I/var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL -g   -Wall -Wextra -pedantic -std=c++14 -x cu -M /var/tmp/src/e75971a9-7e91-6137-abfa-df34048cc171/GCC-Debug-WSL/Main.cu -MT CMakeFiles/CUDA_test.dir/Main.cu.o -o CMakeFiles/CUDA_test.dir/Main.cu.o.d
>
> > nvcc fatal   : Unknown option 'Wall'
>
> > ninja: build stopped: subcommand failed.
>
> >
>
> > CMake seems to pass -Wall -Wextra -pedantic to the device compiler as well, even though it is neither GNU nor Clang, but CUDA. How can I specify warning and similar flags separatly for the host and device compilers?
>
> > --
>
> >
>
> > 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:
>
> > https://cmake.org/mailman/listinfo/cmake
>
>