[Cmake-commits] CMake branch, master, updated. v3.15.0-rc3-165-g2b1d9e5

[Kitware Robot]

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

The branch, master has been updated
   via  2b1d9e51c2e47a3b8c193770eb222c0713f8a5e6 (commit)
  from  3b9009683884593e879191fde5448b12e970d56e (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2b1d9e51c2e47a3b8c193770eb222c0713f8a5e6
commit 2b1d9e51c2e47a3b8c193770eb222c0713f8a5e6
Author: Kitware Robot 
AuthorDate: Sat Jun 29 00:01:05 2019 -0400
Commit: Kitware Robot 
CommitDate: Sat Jun 29 00:01:05 2019 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 0672638..48026fb 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 15)
-set(CMake_VERSION_PATCH 20190628)
+set(CMake_VERSION_PATCH 20190629)
 #set(CMake_VERSION_RC 1)

---

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


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[CMake] HP-UX ia64 (32bit) port

[Earle Lowe]

I have made an HP-UX port for CMAKE 3.15

It's not entirely optimal, because I took a small shortcut on fsevents
in libuv by using the "no events" source also used by cygwin. HP-UX
does have /dev/poll, so I think the AIX code could be used as a
template for a proper implementation.

It runs --version, but I haven't tried to use it to make itself again,
or any other tests.

HP-UX  B.11.31 ia64 using GCC 9.4.3

The binaries are 32-bit

I didn't do this quite correctly because I didn't fork master and I
don't have a PR prepared.

If the community wants though, I can make a proper merge request

I'll note, getting GCC 9.4.3 working on HP-UX is actually harder than
porting cmake. This version of GCC has a fairly robust implementation
of C++11

-Earle
-- 

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

Re: [CMake] Header only libraries with code generated files...

[Malfettone, Kris]

I agree that is sounds like the right way and it is what I would like to use.  
However, before going through the work I just wanted to make sure it didn't 
suffer from the same quirks that add_custom_target does when dealing with code 
generation in different directory.  As outlined in this blog post:

https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/

-Kris

-Original Message-
From: Kyle Edwards [mailto:kyle.edwa...@kitware.com]
Sent: Friday, June 28, 2019 11:31 AM
To: Malfettone, Kris 
Cc: cmake@cmake.org
Subject: Re: [CMake] Header only libraries with code generated files...

It sounds like you want to use the INTERFACE version of
target_include_directories():
https://cmake.org/cmake/help/latest/command/target_include_directories.html

What this means is "anything that links against interface library foo
will also need to add these paths to its include directories."

You will also want to use add_dependencies() to make the interface
library dependent on the generation steps:

https://cmake.org/cmake/help/latest/command/add_dependencies.html

Kyle

On Fri, Jun 28, 2019 at 11:17 AM Malfettone, Kris
 wrote:
>
> Hi all,
>
> I had a question about managing code generated header only libraries is a 
> very large project.  Currently, we have a very large project with many static 
> and many generated files.  The problem I have is that due to the size of the 
> project many usages (exe’s and libraries) of those code generated files 
> (header files) are done in separate folders from the generation targets.  
> That leads me to have to be very careful and explicit with using 
> add_custom_command(…), add_custom_target(…), add_depenendcies(…), and 
> set_source_files_properties( … PROPERTIES GENERATED TRUE ).  Most of that 
> knowledge / setup modeled after reading 
> https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/
>
>
>
> I was wondering if I was able to simplify that by using Interface Libraries 
> and doing target_link_libraries( exe_name 
> MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES ).  I guess my 
> concerns were when adding the interface library to a target in another folder 
> would I still have to:
>
> · Manually add the transitive dependencies
>
> · Manually indicate that the generated files are code generated.
>
>
>
>
>
> I am also assuming my setup would be something like this when using Interface 
> Libraries….
>
> 1.   Still use add_custom_command/add_custom_target to do the generation 
> steps.
>
> 2.   Add the interface library in the same folder as the generation 
> steps, managing its relationship with the code generation target via 
> add_dependencies() meaning most of the code generation quirks are avoided.
>
> 3.   When adding executables or libraries in other folders just use 
> target_link_libraries( exe_name 
> MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES )
>
> a.   Hoping that any transitive dependencies to the code generation steps 
> would be handled by exe_name being dependent on 
> MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES
>
> b.  Also hoping that I wouldn’t have to specify which files are code 
> generated at that step
>
>
>
> I hope this makes sense.
>
>
>
> -Kris
>
>
> 
>
> IMPORTANT: The information contained in this email and/or its attachments is 
> confidential. If you are not the intended recipient, please notify the sender 
> immediately by reply and immediately delete this message and all its 
> attachments. Any review, use, reproduction, disclosure or dissemination of 
> this message or any attachment by an unintended recipient is strictly 
> prohibited. Neither this message nor any attachment is intended as or should 
> be construed as an offer, solicitation or recommendation to buy or sell any 
> security or other financial instrument. Neither the sender, his or her 
> employer nor any of their respective affiliates makes any warranties as to 
> the completeness or accuracy of any of the information contained herein or 
> that this message or any of its attachments is free of viruses.
> --
>
> 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



IMPORTANT: The information contained in this email and/or its attachments is 

Re: [CMake] CMake with FetchContent instead of Git Submodules

[Dustyn Blasig]

Wow, how did I miss that when I was looking through the page yesterday?
That's exactly what I need ; )

I may try going one step further and adding a flag _USE_CLONE=ON
that will do the full checkout to a repos directory, initialize the repo to
the target tag, and then set FETCHCONTENT_SOURCE_DIR_ for the
user. The former would only be done iff the repo doesn't already exist.

On Fri, Jun 28, 2019 at 5:25 AM Craig Scott  wrote:

>
>
> On Fri, Jun 28, 2019 at 12:18 PM Dustyn Blasig  wrote:
>
>> Hi All,
>>
>> I'm attempting to replace our use of git submodules with FetchContent
>> flows instead so we can pull pre-built packages if they already exist
>> instead of buildings locally.
>>
>> However, I need to support a flow similar to Git submodules where
>> developers can edit a submodule and then rebuild the enclosing project
>> incrementally. Things seem to work OK if I jump into the fetched source
>> directories and check out branches, etc. However, even if I move the
>> download and source/unpacked folders outside the build (binary) directory
>> and then delete the build directory, rerunning CMake will blast away the
>> unpacked source even if the last extraction was with the same checksummed
>> download. I need to ensure a "clean" won't delete someones work in a
>> submodule, which is one reason why Git makes it hard to uninit and remove
>> submodules.
>>
>> Is there a best practice for a flow like this that I can replicate?
>>
>
> (Background info: I'm the creator of the FetchContent module)
>
> If you want to be making changes to the sources, you should clone that
> repo manually and point the build at it rather than try to modify the one
> that the project downloads for you. You do this by setting the
> FETCHCONTENT_SOURCE_DIR_ cache variable to override where the
> build should find the sources. Here's the relevant part from the
> FetchContent documentation:
>
> FETCHCONTENT_SOURCE_DIR_If this is set, no download or update
> steps are performed for the specified content and the _SOURCE_DIR 
> variable
> returned to the caller is pointed at this location. This gives developers a
> way to have a separate checkout of the content that they can modify freely
> without interference from the build. The build simply uses that existing
> source, but it still defines _BINARY_DIR to point inside its own
> build area. Developers are strongly encouraged to use this mechanism rather
> than editing the sources populated in the default location, as changes to
> sources in the default location can be lost when content population details
> are changed by the project.
>
> The thinking behind this is that the project will assume it is in control
> of the sources unless told otherwise. By setting the above cache variable,
> you are telling FetchContent that "I want to use my own sources instead of
> whatever you would normally use". Either FetchContent is in control or you
> are.
>
> I use this feature a LOT. Let's say you're working on a project where you
> need to do some refactoring that requires changes in the top level project
> and in some of its dependencies. I will have the top level project cloned.
> I will also have separate manually cloned repos for those dependencies that
> I need to modify. When I run CMake on my top level project, I use
> FETCHCONTENT_SOURCE_DIR_ to point the build at my local cloned
> repos. That makes the build use my local clones so I can modify the
> sources, change branches, etc. without fear of things being changed under
> my feet. When I'm done, I'll commit and push my changes in each of the
> local cloned repos, then I'll update the GIT_HASH details of those
> dependencies in my top level project. I delete the
> FETCHCONTENT_SOURCE_DIR_<...> variables from my CMake cache and re-run
> CMake (and build) to confirm that I've updated my dependency hashes
> correctly, then I commit and push my changes to the top level project.
>
> I use this strategy with project hierarchies with 40+ dependencies that
> can be up to maybe 10 levels deep. I can pull out any dependency used
> anywhere in the hierarchy and work with my own local cloned repo without
> having to care about where in the project hierarchy that dependency is
> usually populated. Being able to easily and selectively switch between the
> project-controlled FetchContent-provided source or my own local cloned
> repo(s) is critical to being able to do this efficiently. If you look at
> the CMake cache variables in ccmake or cmake-gui, you will also see all the
> source directory overrides grouped together because the variable names all
> start with FETCHCONTENT_SOURCE_DIR (this is why I named the cache variables
> FetchContent creates this way instead of putting the dependency name at the
> front of the cache variable name). So you can quickly see for which
> dependencies you are currently using a local cloned repo instead of what
> the project normally uses.
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>
> Get 

Re: [CMake] Header only libraries with code generated files...

[Kyle Edwards]

It sounds like you want to use the INTERFACE version of
target_include_directories():
https://cmake.org/cmake/help/latest/command/target_include_directories.html

What this means is "anything that links against interface library foo
will also need to add these paths to its include directories."

You will also want to use add_dependencies() to make the interface
library dependent on the generation steps:

https://cmake.org/cmake/help/latest/command/add_dependencies.html

Kyle

On Fri, Jun 28, 2019 at 11:17 AM Malfettone, Kris
 wrote:
>
> Hi all,
>
> I had a question about managing code generated header only libraries is a 
> very large project.  Currently, we have a very large project with many static 
> and many generated files.  The problem I have is that due to the size of the 
> project many usages (exe’s and libraries) of those code generated files 
> (header files) are done in separate folders from the generation targets.  
> That leads me to have to be very careful and explicit with using 
> add_custom_command(…), add_custom_target(…), add_depenendcies(…), and 
> set_source_files_properties( … PROPERTIES GENERATED TRUE ).  Most of that 
> knowledge / setup modeled after reading 
> https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/
>
>
>
> I was wondering if I was able to simplify that by using Interface Libraries 
> and doing target_link_libraries( exe_name 
> MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES ).  I guess my 
> concerns were when adding the interface library to a target in another folder 
> would I still have to:
>
> · Manually add the transitive dependencies
>
> · Manually indicate that the generated files are code generated.
>
>
>
>
>
> I am also assuming my setup would be something like this when using Interface 
> Libraries….
>
> 1.   Still use add_custom_command/add_custom_target to do the generation 
> steps.
>
> 2.   Add the interface library in the same folder as the generation 
> steps, managing its relationship with the code generation target via 
> add_dependencies() meaning most of the code generation quirks are avoided.
>
> 3.   When adding executables or libraries in other folders just use 
> target_link_libraries( exe_name 
> MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES )
>
> a.   Hoping that any transitive dependencies to the code generation steps 
> would be handled by exe_name being dependent on 
> MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES
>
> b.  Also hoping that I wouldn’t have to specify which files are code 
> generated at that step
>
>
>
> I hope this makes sense.
>
>
>
> -Kris
>
>
> 
>
> IMPORTANT: The information contained in this email and/or its attachments is 
> confidential. If you are not the intended recipient, please notify the sender 
> immediately by reply and immediately delete this message and all its 
> attachments. Any review, use, reproduction, disclosure or dissemination of 
> this message or any attachment by an unintended recipient is strictly 
> prohibited. Neither this message nor any attachment is intended as or should 
> be construed as an offer, solicitation or recommendation to buy or sell any 
> security or other financial instrument. Neither the sender, his or her 
> employer nor any of their respective affiliates makes any warranties as to 
> the completeness or accuracy of any of the information contained herein or 
> that this message or any of its attachments is free of viruses.
> --
>
> 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

[CMake] Header only libraries with code generated files...

[Malfettone, Kris]

Hi all,
I had a question about managing code generated header only libraries is a very 
large project.  Currently, we have a very large project with many static and 
many generated files.  The problem I have is that due to the size of the 
project many usages (exe's and libraries) of those code generated files (header 
files) are done in separate folders from the generation targets.  That leads me 
to have to be very careful and explicit with using add_custom_command(...), 
add_custom_target(...), add_depenendcies(...), and set_source_files_properties( 
... PROPERTIES GENERATED TRUE ).  Most of that knowledge / setup modeled after 
reading 
https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/

I was wondering if I was able to simplify that by using Interface Libraries and 
doing target_link_libraries( exe_name 
MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES ).  I guess my concerns 
were when adding the interface library to a target in another folder would I 
still have to:

* Manually add the transitive dependencies

* Manually indicate that the generated files are code generated.


I am also assuming my setup would be something like this when using Interface 
Libraries

1.   Still use add_custom_command/add_custom_target to do the generation 
steps.

2.   Add the interface library in the same folder as the generation steps, 
managing its relationship with the code generation target via 
add_dependencies() meaning most of the code generation quirks are avoided.

3.   When adding executables or libraries in other folders just use 
target_link_libraries( exe_name 
MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES )

a.   Hoping that any transitive dependencies to the code generation steps 
would be handled by exe_name being dependent on 
MY_HEADER_ONLY_LIB_WITH_BOTH_STATIC_AND_GENERATED_FILES

b.  Also hoping that I wouldn't have to specify which files are code 
generated at that step

I hope this makes sense.

-Kris



IMPORTANT: The information contained in this email and/or its attachments is 
confidential. If you are not the intended recipient, please notify the sender 
immediately by reply and immediately delete this message and all its 
attachments. Any review, use, reproduction, disclosure or dissemination of this 
message or any attachment by an unintended recipient is strictly prohibited. 
Neither this message nor any attachment is intended as or should be construed 
as an offer, solicitation or recommendation to buy or sell any security or 
other financial instrument. Neither the sender, his or her employer nor any of 
their respective affiliates makes any warranties as to the completeness or 
accuracy of any of the information contained herein or that this message or any 
of its attachments is free of viruses.
-- 

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

Re: [CMake] Is this the rigth way to build a shared library?

[Kyle Edwards]

On Thu, 2019-06-27 at 22:24 -0700, dexter810 wrote:
> This is my CMakeLists.txt which is successfully building a shared
> library, I
> just wanted to confirm if it's the right way and it: 
> 
> cmake_minimum_required(VERSION 3.6)
> project(main)
> 
> 
> 
> include_directories(
> ${CMAKE_CURRENT_SOURCE_DIR}/include
>    
> ${CMAKE_CURRENT_SOURCE_DIR}/build/deps/yara/src/yara/libyara/include)
> 
> add_library(main SHARED main.cpp)
> 
> 
> link_libraries (
> -L${CMAKE_CURRENT_SOURCE_DIR}/build/src/
> -
> L${CMAKE_CURRENT_SOURCE_DIR}/build/deps/yara/src/yara/libyara/.libs
> yaracpp yara pthread ssl crypto)

Rather than specifying -L flags and specifying library names, there are
two other approaches you can take that would be better:

1) Use target_link_directories() in conjunction with
target_link_libraries().
2) Use find_package(Threads) to find pthread, and use find_library()
for everything else.

https://cmake.org/cmake/help/latest/command/find_package.html
https://cmake.org/cmake/help/latest/command/find_library.html

Kyle
-- 

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

Re: [CMake] String CONCAT issue

[Rolf Eike Beer]

Am 2019-06-28 08:52, schrieb vinay kumar Kotegowder:

Hello,

The snippet:
set(SUITE_DIR /home/../abc)

list(APPEND TEST_LSIT
 test_a001)


Since there is a type here I bet this is not the original code that you 
have run.



foreach(test ${TEST_LIST})
message(${test})


Please prefix the calls to message() with something so it is obvious 
which call is producing which output.



string(CONCAT TEST_CMAKE "${SUITE_DIR}/" "${test}/test.cmake")
message(${TEST_CMAKE})
endforeach()

Output:
test_a001

/home/.../abc/test_a001
/test.cmake


Which CMake version is this about?
--
--

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

Re: [CMake] CMake with FetchContent instead of Git Submodules

[Craig Scott]

On Fri, Jun 28, 2019 at 12:18 PM Dustyn Blasig  wrote:

> Hi All,
>
> I'm attempting to replace our use of git submodules with FetchContent
> flows instead so we can pull pre-built packages if they already exist
> instead of buildings locally.
>
> However, I need to support a flow similar to Git submodules where
> developers can edit a submodule and then rebuild the enclosing project
> incrementally. Things seem to work OK if I jump into the fetched source
> directories and check out branches, etc. However, even if I move the
> download and source/unpacked folders outside the build (binary) directory
> and then delete the build directory, rerunning CMake will blast away the
> unpacked source even if the last extraction was with the same checksummed
> download. I need to ensure a "clean" won't delete someones work in a
> submodule, which is one reason why Git makes it hard to uninit and remove
> submodules.
>
> Is there a best practice for a flow like this that I can replicate?
>

(Background info: I'm the creator of the FetchContent module)

If you want to be making changes to the sources, you should clone that repo
manually and point the build at it rather than try to modify the one that
the project downloads for you. You do this by setting the
FETCHCONTENT_SOURCE_DIR_ cache variable to override where the
build should find the sources. Here's the relevant part from the
FetchContent documentation:

FETCHCONTENT_SOURCE_DIR_If this is set, no download or update steps
are performed for the specified content and the _SOURCE_DIR variable
returned to the caller is pointed at this location. This gives developers a
way to have a separate checkout of the content that they can modify freely
without interference from the build. The build simply uses that existing
source, but it still defines _BINARY_DIR to point inside its own
build area. Developers are strongly encouraged to use this mechanism rather
than editing the sources populated in the default location, as changes to
sources in the default location can be lost when content population details
are changed by the project.

The thinking behind this is that the project will assume it is in control
of the sources unless told otherwise. By setting the above cache variable,
you are telling FetchContent that "I want to use my own sources instead of
whatever you would normally use". Either FetchContent is in control or you
are.

I use this feature a LOT. Let's say you're working on a project where you
need to do some refactoring that requires changes in the top level project
and in some of its dependencies. I will have the top level project cloned.
I will also have separate manually cloned repos for those dependencies that
I need to modify. When I run CMake on my top level project, I use
FETCHCONTENT_SOURCE_DIR_ to point the build at my local cloned
repos. That makes the build use my local clones so I can modify the
sources, change branches, etc. without fear of things being changed under
my feet. When I'm done, I'll commit and push my changes in each of the
local cloned repos, then I'll update the GIT_HASH details of those
dependencies in my top level project. I delete the
FETCHCONTENT_SOURCE_DIR_<...> variables from my CMake cache and re-run
CMake (and build) to confirm that I've updated my dependency hashes
correctly, then I commit and push my changes to the top level project.

I use this strategy with project hierarchies with 40+ dependencies that can
be up to maybe 10 levels deep. I can pull out any dependency used anywhere
in the hierarchy and work with my own local cloned repo without having to
care about where in the project hierarchy that dependency is usually
populated. Being able to easily and selectively switch between the
project-controlled FetchContent-provided source or my own local cloned
repo(s) is critical to being able to do this efficiently. If you look at
the CMake cache variables in ccmake or cmake-gui, you will also see all the
source directory overrides grouped together because the variable names all
start with FETCHCONTENT_SOURCE_DIR (this is why I named the cache variables
FetchContent creates this way instead of putting the dependency name at the
front of the cache variable name). So you can quickly see for which
dependencies you are currently using a local cloned repo instead of what
the project normally uses.


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

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide 
-- 

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 

[CMake] CPack`ing a bunch of command line tools on OS/X

[Torsten Robitzki]

Hello,
I try to pack a bunch of command line tools (and some additional data files) 
into an OS/X installer. When the installer is running, it should install / copy 
the command line tools and adjust the PATH variable (or what ever mean that 
comes close, to make the tools available). I use a super build structure and 
after build and is done, I end up with a very simple structure:

  install
|
|\-bin
|   |\-bjpaprog
|   |\-bjpaserver
|   |\-bootloader_client
|   \-—create_package
|
\--firmware
|\-bootloader.tfp
|\-firmware.tfp
\-—softdevice.tfp

I use TGZ and productbuild as CPack generators. The generated zip file contains 
all the files above. The generated pkg files, just starts the installer, but 
does nothing.

The CMakeLists.txt for the packing looks basically like this:

cmake_minimum_required(VERSION 3.14)

set(CPACK_PACKAGE_VENDOR "Torrox GmbH & Co KG")

install(DIRECTORY ${INSTALL_DIR}/bin DESTINATION .)
install(DIRECTORY ${INSTALL_DIR}/firmware DESTINATION .)

set(CPACK_GENERATOR TGZ productbuild)

include(CPack)


I have no clue, to as where to start. Any ideas, pointers, comments?

best regards,

Torsten




signature.asc
Description: Message signed with OpenPGP
-- 

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

[CMake] String CONCAT issue

[vinay kumar Kotegowder]

Hello,

The snippet:
set(SUITE_DIR /home/../abc)

list(APPEND TEST_LSIT
 test_a001)

foreach(test ${TEST_LIST})
message(${test})
string(CONCAT TEST_CMAKE "${SUITE_DIR}/" "${test}/test.cmake")
message(${TEST_CMAKE})
endforeach()

Output:
test_a001

/home/.../abc/test_a001
/test.cmake

Not able to get the path of test.cmake properly.

Please let me know what is wrong in code.

Appreciate early response.

Regards,
Vinay
-- 

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