[CMake] What is the difference between STATIC and INTERNAL cache variables?

[Timothy Wrona]

According to the documentation:

https://cmake.org/cmake/help/v3.17/prop_cache/TYPE.html

It looks like STATIC cache variables are supposed to be visible from the
CMake GUI, but not modifiable. But when I open a project that has some
STATIC variables in the CMake GUI it looks like you can't even see them at
all (similar to INTERNAL cache variables).

In fact, other than being declared "STATIC" in the "CMakeCache.txt" file I
can't see any real difference between these variables and INTERNAL
variables.

Is there any difference between STATIC and INTERNAL cache variables in
practice?

Thanks,
Tim
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] Scoping of CMake functions included from modules

[Timothy Wrona]

I've been working on a relatively complicated project that uses multiple
CMake modules. Some of these modules internally include other modules. The
issue is, when one of my modules internally includes another module, all of
the functions from the internal module become visible globally throughout
my whole project!

I have written a Stack Overflow problem with a basic example demonstrating
my problem:
https://stackoverflow.com/questions/60626239/how-can-i-scope-a-cmake-function-so-it-cant-be-accessed-from-outside-a-file


Unfortunately CMake doesn't get much response on Stack Overflow so I
figured I should probably send a message to the mailing list as well.

Does anyone know how to resolve this problem?

Thanks,
Tim
-- 

Powered by kitware.com/cmake

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit https://cmake.org/services

Visit other Kitware open-source projects at https://www.kitware.com/platforms

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

This mailing list is deprecated in favor of https://discourse.cmake.org

[CMake] Capturing command line arguments passed to CMake

[Timothy Wrona]

I am working on a CMake project that uses ExternalProject_Add to add an
external dependency. The issue is, I need all of my command line arguments
from my project to be propagated to the external project so it will build
using the same build configuration and with the correct compiler settings.

Is there a simple way to extract all of the command line arguments into a
variable so I can simply pass them to ExternalProject_Add with the
"CMAKE_ARGS" parameter?

The only solution I have found so far is a function that parses the CMake
Cache and extracts all of the variables with a help message that says "No
help, variable specified on the command line." While this does work, it
feels like a hacky workaround at best and seems like it may break in a
future update of CMake if they decide to change the default cache help
messages.

Here is the code to make this hack work:

get_cmake_property(CACHE_VARS CACHE_VARIABLES)

foreach(CACHE_VAR ${CACHE_VARS})

  get_property(CACHE_VAR_HELPSTRING CACHE ${CACHE_VAR} PROPERTY HELPSTRING)

  if(CACHE_VAR_HELPSTRING STREQUAL "No help, variable specified on
the command line.")

get_property(CACHE_VAR_TYPE CACHE ${CACHE_VAR} PROPERTY TYPE)

if(CACHE_VAR_TYPE STREQUAL "UNINITIALIZED")

  set(CACHE_VAR_TYPE)

else()

  set(CACHE_VAR_TYPE :${CACHE_VAR_TYPE})

endif()

list(APPEND CMAKE_ARGS
"-D${CACHE_VAR}${CACHE_VAR_TYPE}=${${CACHE_VAR}}")

  endif()

endforeach()


Is there any easy way to just get a list of all of the command line
arguments without parsing the cache and filtering by help messages? This
solution just really feels wrong... there must be a better way.

Thanks,
Tim
-- 

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] Using find_package fails to find related subprojects that are exported to the package registry

[Timothy Wrona]

Hi fellow CMake programmers! I've got a bit of a tricky situation and I
wonder if anyone has ever dealt with this before.

I am trying to configure a project that has a structure as follows

myproject/
executable1/  <-- depends on common_lib1
my_common_libs/
common_lib1/
common_lib2/

Note: Before I begin - this is a legacy system and is MUCH larger than what
I am showing here so restructuring the whole project is not really an
option. Let me begin by describing the CMakeLists.txt structure.

In myproject/CMakeLists.txt subdirectories are added as follows:

file(GLOB entries *)
foreach(entry ${entries})
  if (IS_DIRECTORY ${entry} AND EXISTS ${entry}/CMakeLists.txt)
add_subdirectory(${entry})
  endif()
endforeach()

my_common_libs/CMakeLists.txt does the same...

Then my_common_libs/common_lib1/CMakeLists.txt does what is necessary to
define the library and export the target to the local package registry:

add_library(common_lib1 ...)

export(TARGETS common_lib1 NAMESPACE common_lib1:: FILE
common_lib1-targets.cmake)
file(COPY common_lib1-config.cmake DESTINATION ${CMAKE_CURRENT_BINARY_DIR})
export(PACKAGE common_lib1)

my_common_libs/common_lib2/CMakeLists.txt does the same and both have
"common_libx-config.cmake" files that properly load the corresponding
"-targets.cmake" files.

In executable1/CMakeLists.text I do what is necessary to find the package
and use it:

add_executable(executable1 ...)

find_package(common_lib1 REQUIRED) <-- this is where I am having the problem
target_link_libraries(executable1
common_lib1::common_lib1
)

Now this is where things get hairy...

If I go into common_lib1 and manually build that first, it puts it in the
package registry and then I can go to "executable1" and build that and it
finds the package, and builds, and links fine.
BUT... if I clean the project and then try to build it from the top level
it immediately fails and says it can't locate the package "common_lib1".

I understand I could probably replace the GLOB commands with explicit
"add_subdirectory" calls and then carefully reorder all of the
"add_subdirectory" commands to add things in dependency order, but that
would be really tedious with how large the project is and is really not the
way the whole rest of the system is done... It feels somewhat brittle
because then I am essentially declaring the dependencies from outside of
the modules themselves.

Is there any way to force CMake to do all of the "export" commands up front
to essentially initialize the package registry so it will be aware of
common_lib1 when I compile from the "myproject" level? Or is there another
solution I haven't even considered that could solve this same problem?

Thanks,
Tim
-- 

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] Specifying code in one subdirectory depends on a library from another subdirectory

[Timothy Wrona]

Never mind... I spoke too soon. add_dependencies isn't working. It is
correctly making the other project build first, but the header file is for
some reason not generated until after it is needed.

On Tue, Mar 19, 2019 at 1:41 PM Timothy Wrona  wrote:

> Seems I might be able to answer my own question.
>
> It looks like "add_dependencies(subproject1_exe subproject2_lib)" worked.
>
> I had to do a clean first though because it didn't work the first time
> since some old files were left around.
>
> Hope this helps anyone else with a similar issue!
>
> On Tue, Mar 19, 2019 at 1:13 PM Timothy Wrona 
> wrote:
>
>> I am working on a complex CMake project that is part of a large legacy
>> system that uses a top level project and "add_subdirectory" to create
>> subprojects.
>>
>> I have run into an issue because now one of the subprojects is dependant
>> on another subproject, but I can't seem to find a clear way to tell CMake
>> about this dependency.
>>
>> Consider this example:
>>
>> my_project/
>> CMakeLists.txt:
>>   add_subdirectory('subproject1')
>>   add_subdirectory('subproject2')
>>
>> my_project/subproject1/
>> CMakeLists.txt:
>> add_executable(subproject1_exe )
>> target_link_libraries(subproject1_exe subproject2_lib) # <--
>> THIS is the problem
>>
>> my_project/subproject2/
>> CMakeLists.txt:
>> add_library(subproject2_lib )
>>
>> The actual code is much more complex than this, but this simple example
>> illustrates the problem. The actual compilation error I am getting is
>> caused by subproject1 including a header file that gets generated when
>> subproject2 is built.
>>
>> Does anyone know how to properly tell CMake about the dependency so it
>> will build correctly?
>>
>
-- 

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] Specifying code in one subdirectory depends on a library from another subdirectory

[Timothy Wrona]

Seems I might be able to answer my own question.

It looks like "add_dependencies(subproject1_exe subproject2_lib)" worked.

I had to do a clean first though because it didn't work the first time
since some old files were left around.

Hope this helps anyone else with a similar issue!

On Tue, Mar 19, 2019 at 1:13 PM Timothy Wrona  wrote:

> I am working on a complex CMake project that is part of a large legacy
> system that uses a top level project and "add_subdirectory" to create
> subprojects.
>
> I have run into an issue because now one of the subprojects is dependant
> on another subproject, but I can't seem to find a clear way to tell CMake
> about this dependency.
>
> Consider this example:
>
> my_project/
> CMakeLists.txt:
>   add_subdirectory('subproject1')
>   add_subdirectory('subproject2')
>
> my_project/subproject1/
> CMakeLists.txt:
> add_executable(subproject1_exe )
> target_link_libraries(subproject1_exe subproject2_lib) # <--
> THIS is the problem
>
> my_project/subproject2/
> CMakeLists.txt:
> add_library(subproject2_lib )
>
> The actual code is much more complex than this, but this simple example
> illustrates the problem. The actual compilation error I am getting is
> caused by subproject1 including a header file that gets generated when
> subproject2 is built.
>
> Does anyone know how to properly tell CMake about the dependency so it
> will build correctly?
>
-- 

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] Specifying code in one subdirectory depends on a library from another subdirectory

[Timothy Wrona]

I am working on a complex CMake project that is part of a large legacy
system that uses a top level project and "add_subdirectory" to create
subprojects.

I have run into an issue because now one of the subprojects is dependant on
another subproject, but I can't seem to find a clear way to tell CMake
about this dependency.

Consider this example:

my_project/
CMakeLists.txt:
  add_subdirectory('subproject1')
  add_subdirectory('subproject2')

my_project/subproject1/
CMakeLists.txt:
add_executable(subproject1_exe )
target_link_libraries(subproject1_exe subproject2_lib) # <--
THIS is the problem

my_project/subproject2/
CMakeLists.txt:
add_library(subproject2_lib )

The actual code is much more complex than this, but this simple example
illustrates the problem. The actual compilation error I am getting is
caused by subproject1 including a header file that gets generated when
subproject2 is built.

Does anyone know how to properly tell CMake about the dependency so it will
build correctly?
-- 

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-developers] [CMake] Ensuring an external project is built and installed before trying to call "find_package" on it

[Timothy Wrona]

I've tried a couple different approaches with ExternalProject_Add and
FetchContent, but none of them seem quite right... CMake just doesn't seem
to conpletely fulfill the role of a full blown package manager. I mean it
works, but it just feels like it could be better. I've decided I'm going to
take a few days and really try to learn how to use the Conan package
manager in depth. If it works out well I will try to summarize and report
some of my findings. :)

Thanks,
Tim

On Sat, Feb 23, 2019 at 2:32 AM Craig Scott  wrote:

>
>
> On Sat, Feb 23, 2019 at 4:14 PM Timothy Wrona 
> 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 
>> )
>> ExternalProject_Add(Dependency2
>> GIT_REPOSITORY 
>> )
>>
>> 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 
> INSTALL_DIR${installDir}
> CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=
> )
> ExternalProject_Add(Dependency2
> GIT_REPOSITORY 
> INSTALL_DIR${installDir}
> CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=
> )
> ExternalProject_Add(mainBuild
> SOURCE_DIR  
> INSTALL_DIR ${installDir}
> DEPENDS Dependency1 Dependency2
> CMAKE_ARGS  -DCMAKE_INSTALL_PREFIX:PATH=
> -DCMAKE_PREFIX_PATH:PATH=
> )
>
> 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/>
>
-- 

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

[CMake] Ensuring an external project is built and installed before trying to call "find_package" on it

[Timothy Wrona]

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 
)
ExternalProject_Add(Dependency2
GIT_REPOSITORY 
)

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

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] Automatically updating Doxygen documentation and making it readily available to users with CMake

[Timothy Wrona]

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

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] Automatically updating Doxygen documentation and making it readily available to users with CMake

[Timothy Wrona]

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

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-developers] Using FetchContent fails when two subprojects have a target with the same name

[Timothy Wrona]

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

>
>
> On Wed, Feb 20, 2019 at 3:36 PM Timothy Wrona 
> 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 
>> 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/>
>
-- 

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-developers] Using FetchContent fails when two subprojects have a target with the same name

[Timothy Wrona]

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

>
>
> On Wed, Feb 20, 2019 at 3:36 PM Timothy Wrona 
> 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 
>> 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/>
>
-- 

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

Re: [CMake] Using FetchContent fails when two subprojects have a target with the same name

[Timothy Wrona]

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

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-developers] Using FetchContent fails when two subprojects have a target with the same name

[Timothy Wrona]

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

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

[CMake] Using FetchContent fails when two subprojects have a target with the same name

[Timothy Wrona]

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

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-developers] Using CMake as a package manager vs using a dedicated package management tool (like Conan)

[Timothy Wrona]

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

Re: [cmake-developers] Using CMake as a package manager vs using a dedicated package management tool (like Conan)

[Timothy Wrona]

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

Re: [CMake] [cmake-developers] Using CMake as a package manager vs using a dedicated package management tool (like Conan)

[Timothy Wrona]

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

>
>
> On Tue, Feb 19, 2019 at 12:46 PM Timothy Wrona 
> wrote:
>
>> I have been working on a new C++ project and I am trying to decide
>> whether I should use CMake as my package 

Re: [cmake-developers] Using CMake as a package manager vs using a dedicated package management tool (like Conan)

[Timothy Wrona]

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

>
>
> On Tue, Feb 19, 2019 at 12:46 PM Timothy Wrona 
> wrote:
>
>> I have been working on a new C++ project and I am trying to decide
>> whether I should use CMake as my package 

[cmake-developers] Using CMake as a package manager vs using a dedicated package management tool (like Conan)

[Timothy Wrona]

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

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

[CMake] Using CMake as a package manager vs using a dedicated package management tool (like Conan)

[Timothy Wrona]

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

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 there a way to delay "find_package" until link-time when the package is actually needed?

[Timothy Wrona]

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

>
>
> Le jeu. 14 févr. 2019 à 18:57, Timothy Wrona  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 
>> wrote:
>>
>>>
>>>
>>> Le jeu. 14 févr. 2019 à 18:22, Timothy Wrona  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
>
-- 

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 there a way to delay "find_package" until link-time when the package is actually needed?

[Timothy Wrona]

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

>
>
> Le jeu. 14 févr. 2019 à 18:22, Timothy Wrona  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
>
-- 

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] Is there a way to delay "find_package" until link-time when the package is actually needed?

[Timothy Wrona]

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

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-developers] Properly Documenting a CMake Module

[Timothy Wrona]

That's what I was looking for! Thanks!!!

On Thu, Feb 14, 2019 at 9:04 AM  wrote:

>
>
> > Am 14.02.2019 um 14:53 schrieb Timothy Wrona :
> >
> > How does Sphinx know to go parse that ".cmake" file? Does Sphinx
> recognize the „cmake-module" keyword in a special way and know what to do
> with it?
>
> it’s from a Sphinx module that you can find the in the CMake sources
> Utilities/Sphinx/cmake.py. Or you can install this file using pip:
>
> > pip install sphinxcontrib-moderncmakedomain
>
> When configuring Sphinx, you have to name the extensions to use in
> Sphinx's configuration file (conf.py) and add the name of the extension
> (sphinxcontrib.moderncmakedomain) to the extensions array.
>
> best regards,
>
> 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-developers

Re: [cmake-developers] Properly Documenting a CMake Module

[Timothy Wrona]

Hi Gregor,

It looks like there's still a little bit of magic here. All those
"Help/.rst" files just have a single line in them that says:

.. cmake-module:: ../../Modules/.cmake

How does Sphinx know to go parse that ".cmake" file? Does Sphinx recognize
the "cmake-module" keyword in a special way and know what to do with it?

Thanks,
Tim
-- 

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

Re: [cmake-developers] Properly Documenting a CMake Module

[Timothy Wrona]

Okay so I dug a little deeper into this and it definitely looks like sphinx
is the correct tool to use, but I still have one problem.

I would like sphinx to be able to extract ".rst" formatted comments
directly out of my cmake source files to produce the documentation but I
can't seem to figure out how.

The standard modules that ship with cmake all have this ".rst" section at
the top that seems to magically get extracted and turned into online
documentation with sphinx, but I just can't figure out how they do it.

Is there a simple way to use sphinx to extract these comments without
writing my own tool to do it? I mean it wouldn't be hard to script, but if
there is a standard way I would prefer to use what everyone else uses
rather than reinvent the wheel.

Thanks,
Tim

On Wed, Feb 13, 2019, 8:59 AM Timothy Wrona  I am going to quote your response in an answer on my stack overflow
> question so others may find this information too.
>
> On Wed, Feb 13, 2019 at 8:57 AM Timothy Wrona 
> wrote:
>
>> Thanks for the info and the links! I will start looking into it. :)
>>
>> On Wed, Feb 13, 2019 at 7:50 AM Torsten Robitzki 
>> wrote:
>>
>>>
>>>
>>> > Am 13.02.2019 um 13:42 schrieb Brad King via cmake-developers <
>>> cmake-developers@cmake.org>:
>>> >
>>> > The online docs, like those at https://cmake.org/cmake/help/v3.14
>>> > do publish a `/objects.inv` to support intersphinx:
>>> >
>>> >  http://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html
>>> >
>>> > This was done on request of some users so I haven't looked into how
>>> > that works, but one should be able to use sphinx to generate one's
>>> > own documentation and still cross-reference CMake’s online docs.
>>>
>>> I can confirm that this works as expected. Used it by myself.
>>>
>>
-- 

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

Re: [cmake-developers] Properly Documenting a CMake Module

[Timothy Wrona]

I am going to quote your response in an answer on my stack overflow
question so others may find this information too.

On Wed, Feb 13, 2019 at 8:57 AM Timothy Wrona  wrote:

> Thanks for the info and the links! I will start looking into it. :)
>
> On Wed, Feb 13, 2019 at 7:50 AM Torsten Robitzki 
> wrote:
>
>>
>>
>> > Am 13.02.2019 um 13:42 schrieb Brad King via cmake-developers <
>> cmake-developers@cmake.org>:
>> >
>> > The online docs, like those at https://cmake.org/cmake/help/v3.14
>> > do publish a `/objects.inv` to support intersphinx:
>> >
>> >  http://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html
>> >
>> > This was done on request of some users so I haven't looked into how
>> > that works, but one should be able to use sphinx to generate one's
>> > own documentation and still cross-reference CMake’s online docs.
>>
>> I can confirm that this works as expected. Used it by myself.
>>
>
-- 

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

Re: [cmake-developers] Properly Documenting a CMake Module

[Timothy Wrona]

Thanks for the info and the links! I will start looking into it. :)

On Wed, Feb 13, 2019 at 7:50 AM Torsten Robitzki 
wrote:

>
>
> > Am 13.02.2019 um 13:42 schrieb Brad King via cmake-developers <
> cmake-developers@cmake.org>:
> >
> > The online docs, like those at https://cmake.org/cmake/help/v3.14
> > do publish a `/objects.inv` to support intersphinx:
> >
> >  http://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html
> >
> > This was done on request of some users so I haven't looked into how
> > that works, but one should be able to use sphinx to generate one's
> > own documentation and still cross-reference CMake’s online docs.
>
> I can confirm that this works as expected. Used it by myself.
>
-- 

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

Re: [cmake-developers] Properly Documenting a CMake Module

[Timothy Wrona]

Note: I have additionally posted this question to stack overflow so if you
would like to answer there rather than email it may help a larger audience:
https://stackoverflow.com/questions/54660549/what-is-the-proper-way-to-document-a-cmake-module

On Tue, Feb 12, 2019 at 6:37 PM Timothy Wrona  wrote:

> A quick Google search (...actually many rather extensive Google searches)
> have not been able to explain how to properly document a CMake module.
>
> What I'm looking for is a way to document custom CMake modules so that
> they work with the "cmake --help-module " command. Is there
> any standard way of doing this? Can anyone point me to some good examples?
> The documentation process seems oddly not well documented. Haha.
>
> How are modules that work with "cmake --help-module" documented?
>
> Any help is appreciated.
>
> Thanks,
> Tim
>
-- 

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

[cmake-developers] Properly Documenting a CMake Module

[Timothy Wrona]

A quick Google search (...actually many rather extensive Google searches)
have not been able to explain how to properly document a CMake module.

What I'm looking for is a way to document custom CMake modules so that they
work with the "cmake --help-module " command. Is there any
standard way of doing this? Can anyone point me to some good examples? The
documentation process seems oddly not well documented. Haha.

How are modules that work with "cmake --help-module" documented?

Any help is appreciated.

Thanks,
Tim
-- 

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

[cmake-developers] Fwd: [CMake] link only with targets feature

[Timothy Wrona]

I saw this email come through the cmake users mailing list but feel it is
more fitting for it to go to cmake-developers so I'm forwarding it here.

It is a pretty long rant, but I think his idea to add a keyword to the
"target_link_libraries()" command that would only look for cmake targets is
a pretty great idea. I dont think it would break backwards compatibility
either.

For example:

target_link_libraries(mytarget
  LINK_TARGETS
target1
target1
)

This would only search for CMake targets to link to and would not search
for libraries with the same name. It would make adding alias namespace to
targets not necessary anymore and would potentially make a lot of code look
cleaner.


-- Forwarded message -
From: Starka Tomáš 
Date: Tue, Feb 12, 2019, 2:17 AM
Subject: [CMake] link only with targets feature
To: 


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
(WH?, 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

-- 

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 

[CMake] What is the best practice for installing custom CMake modules?

[Timothy Wrona]

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

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-developers] Possible Bug With "add_custom_command()" and the Visual Studio Generator for CMake

[Timothy Wrona]

Ha that actually seems like a totally separate bug.

>From what I understand - if "add_custom_command()" is not associated with
any target and is just given a command it is supposed to run at build time
every time the build is initiated, but with the Visual Studio generator it
seems to just skip over it unless CMake has something else it needs to do.

On Fri, Feb 8, 2019 at 8:44 PM frodak17  wrote:

> I haven't tried it out but I'm not exactly surprised it wouldn't work with
> Visual Studio 2017.
>
> It seems to be similar to the issue mentioned here:
> https://stackoverflow.com/q/54557801/1028434
>
> The problem I noticed in the case of the StackOverflow question,
> "add_custom_target(testcmake2 ALL)" doesn't have a "command" so it doesn't
> generate an output.
>
> When performing a build Visual Studio prints a message like "all outputs
> up to date" and skips over it.  So any associated custom commands with the
> target are never run.
> Adding a "command" that is even an echo, like add_custom_target(testcmake1
> COMMAND ${CMAKE_COMMAND} -E echo "Running testcmake1 step 1"), and the
> problem goes away.
>
>
>
> On Fri, Feb 8, 2019 at 6:08 PM Timothy Wrona 
> wrote:
>
>> I have been following the examples in the "CMake Cookbook" by Radovan
>> Bast and Roberto Di Remigio and came across one example that doesn't appear
>> to work right on Windows.
>>
>> The source code for these example can be found here:
>> https://github.com/dev-cafe/cmake-cookbook
>>
>> Chapter-06/Recipe-07 is supposed to update the Git commit hash referenced
>> by the version header file every time the project is built. According to
>> the book, "add_custom_command()" is supposed to execute on every build
>> regardless of whether any files are changed. This example seems to work
>> correctly in a Linux environment, but not in Windows with the Visual Studio
>> Generator. When a new commit is created (an empty commit created with "git
>> commit --allow-empty") the custom command is never called and the commit
>> hash is not updated correctly.
>>
>> For specific instructions to reproduce the issue, see this bug report I
>> opened for the example in the book:
>> https://github.com/dev-cafe/cmake-cookbook/issues/506
>>
>> I assumed this was an issue with the example, but it looks like the
>> Visual Studio Generator may not be handling "add_custom_command()"
>> correctly and may be the source of the problem.
>>
>> System info:
>> CMake version 3.13.3
>> Windows 10
>> Visual Studio 2017
>> --
>>
>> 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
>>
>
-- 

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

[cmake-developers] Possible Bug With "add_custom_command()" and the Visual Studio Generator for CMake

[Timothy Wrona]

I have been following the examples in the "CMake Cookbook" by Radovan Bast
and Roberto Di Remigio and came across one example that doesn't appear to
work right on Windows.

The source code for these example can be found here:
https://github.com/dev-cafe/cmake-cookbook

Chapter-06/Recipe-07 is supposed to update the Git commit hash referenced
by the version header file every time the project is built. According to
the book, "add_custom_command()" is supposed to execute on every build
regardless of whether any files are changed. This example seems to work
correctly in a Linux environment, but not in Windows with the Visual Studio
Generator. When a new commit is created (an empty commit created with "git
commit --allow-empty") the custom command is never called and the commit
hash is not updated correctly.

For specific instructions to reproduce the issue, see this bug report I
opened for the example in the book:
https://github.com/dev-cafe/cmake-cookbook/issues/506

I assumed this was an issue with the example, but it looks like the Visual
Studio Generator may not be handling "add_custom_command()" correctly and
may be the source of the problem.

System info:
CMake version 3.13.3
Windows 10
Visual Studio 2017
-- 

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

Re: [cmake-developers] CMake "find_package" command on a package that is not installed is unexpectedly successful

[Timothy Wrona]

Is there an easy way to clean the user package registry (with a CMake
command or something similar) instead of manually making edits to the
Windows registry?

After moving this package around a few times I've realized I have a bunch
of junk entries in the user package registry.

On Tue, Feb 5, 2019 at 3:15 PM Timothy Wrona  wrote:

> Thank you! I didn't know it would make a registry entry, that was the
> missing link!
>
> On Tue, Feb 5, 2019 at 2:46 PM Brad King  wrote:
>
>> On 2/5/19 2:37 PM, Timothy Wrona wrote:
>> > Can anyone explain to me how "find_package" is able to find the Eigen
>> libraries
>> > even though they are just pasted into some arbitrary location that I
>> never told
>> > the example project about?
>>
>> Eigen uses the CMake package registry feature:
>>
>>
>> https://bitbucket.org/eigen/eigen/src/a3be57987f/CMakeLists.txt?at=default=file-view-default#CMakeLists.txt-602:604
>>
>> See docs here:
>>
>>
>> https://cmake.org/cmake/help/v3.13/manual/cmake-packages.7.html#package-registry
>>
>> and step 6 of the find_package search procedure:
>>
>>
>> https://cmake.org/cmake/help/v3.13/command/find_package.html#search-procedure
>>
>> -Brad
>>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake "find_package" command on a package that is not installed is unexpectedly successful

[Timothy Wrona]

Thank you! I didn't know it would make a registry entry, that was the
missing link!

On Tue, Feb 5, 2019 at 2:46 PM Brad King  wrote:

> On 2/5/19 2:37 PM, Timothy Wrona wrote:
> > Can anyone explain to me how "find_package" is able to find the Eigen
> libraries
> > even though they are just pasted into some arbitrary location that I
> never told
> > the example project about?
>
> Eigen uses the CMake package registry feature:
>
>
> https://bitbucket.org/eigen/eigen/src/a3be57987f/CMakeLists.txt?at=default=file-view-default#CMakeLists.txt-602:604
>
> See docs here:
>
>
> https://cmake.org/cmake/help/v3.13/manual/cmake-packages.7.html#package-registry
>
> and step 6 of the find_package search procedure:
>
>
> https://cmake.org/cmake/help/v3.13/command/find_package.html#search-procedure
>
> -Brad
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

[cmake-developers] CMake "find_package" command on a package that is not installed is unexpectedly successful

[Timothy Wrona]

I am working my way through the "CMake Cookbook" by Radovan Bast and
Roberto Di Remigio and got to an example that required the Eigen C++
libraries. (chapter-02/recipe-06)

I downloaded the ".zip" for the Eigen libraries and unzipped it to an
arbitrary location. Then I ran CMake on it (but I did not build or install
it). After doing this, magically the example code was able to find it and
the example built successfully even though I never told it where to look
for the Eigen libraries.

A detailed description of my experience is in this stack overflow post:
https://stackoverflow.com/questions/54541261/cmake-find-package-command-on-a-package-that-was-not-installed-is-unexpectedly?noredirect=1#comment95884208_54541261

Can anyone explain to me how "find_package" is able to find the Eigen
libraries even though they are just pasted into some arbitrary location
that I never told the example project about?

As far as I can tell from the documentation on "find_package" it should not
work.

Thanks,
Tim
-- 

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

[cmake-developers] Conan Integration for CMake

[Timothy Wrona]

I recently started using a new package manager for C++ called "Conan" and
I'm finding it is solves many of the dependency issues that plague all of
my previous C++/CMake projects.

Conan is an up-and-coming tool, but it seems to be gaining quite a bit of
traction. It is designed with CMake in mind and works very well with CMake
projects. There is just some functionality that feels like it could be a
little more streamlined and the only way to make that happen would be to
add built-in support in CMake for Conan.

An effort has been made to add some CMake tools around Conan at "
https://github.com/conan-io/cmake-conan; and they really help streamline
the process. Integrating Conan support into CMake itself would make it so
you don't have to grab this library from GitHub everytime you want to use
Conan with a CMake project and would simplify the process.

Is this something that could possibly be integrated into CMake in a future
version? If others think that it would be well received I wouldn't mind
offering some of my time to be part of the integration effort.

*For anyone using CMake and programming in C or C++, if you are unfamiliar
with Conan I strongly suggest you check it out. It solves many difficult
dependency management issues in ways that CMake alone cannot. For more
information on Conan see "https://conan.io/ "*
-- 

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