[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

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

[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

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

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 

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