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

[Craig Scott]

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 management system or if I should use a
> dedicated package management tool such as Conan.
>
> For more information on Conan see: https://conan.io/
>
> I am trying to understand the main difference between using Conan to
> manage dependencies vs using CMakes "FetchContent" module. Are there any
> compelling reasons to prefer something like Conan?
>

Excellent question, one that I think deserves a more detailed answer than I
can provide here, but I'll try to hit the main points as I see them.

Personally, I think there is no "right answer" or "one size fits all" when
it comes to package management for a CMake project. What works well for one
situation, person or project may not be as convenient or suitable for
another. There are competing needs and views, some of which are personal
preferences, others are hard requirements from things like OS distribution
policies for packaging. Even just the maturity of a project can have a big
influence on how developers may prefer to handle its dependencies and
handle it as a dependency of other projects.

The key thing for me is that the developer should ideally have choices when
it comes to this area. If a project hard-codes that its dependencies must
come from a particular provider (whether that be Conan, Hunter, vcpkg or
some other system), this might not be compatible with what the developer's
situation allows. You would need to weigh up whether it makes sense to lock
the developer into a particular package manager if they want to use your
project or not. An inappropriate choice here can mean lower adoption of the
project as some may reject it for consideration based on this point alone.

If instead a project relies only on find_package() to find its
dependencies, then it is up to the developer to ensure they are all
available. This could be done using whatever package manager the developer
finds convenient, or they could build the dependency projects from source
individually or they might set up a superbuild parent project that builds
the dependencies in the required order and makes dependees available to
dependers. This gives good flexibility at the cost of more responsibility
on the developer than perhaps some would want (again, it will be highly
situation-dependent).

A drawback with find_package() is that it assumes you actually have a
packageable project. For a variety of reasons, this may not be the case.
Consider a large, complex project in its early stages and where multiple
teams are working on different subprojects which all get combined into some
larger whole. Each of the subprojects may need to be able to build on their
own with their own smaller subset of dependencies, but they also need to be
able to be incorporated into a larger build (think of different teams
working on core toolkits, rendering engines, different algorithm
strategies, multiple GUI applications, backend components, etc). No-one may
know yet how it should get packaged up and everyone might be focused on
just getting a minimal viable prototype up and running as a technical
demonstrator. For a case like that, neither find_package() nor a package
manager really fits the workflow. In this situation though, FetchContent is
a perfect fit, since it doesn't require any packaging to already be in
place, it needs no external tools other than CMake and it gives each
project precise control over its dependencies down to the individual commit
to bring in for each one.

With the above in mind, perhaps the following few questions may be helpful
in clarifying what your constraints are and maybe steering you more toward
one way or the other:

   - Will the project be incorporated into a Linux distribution at some
   point (not just be installed on Linux, but be part of the actual Linux
   distribution as provided by its own native package manager)? If so, I would
   expect this would pretty much eliminate using any package manager and
   instead require that you use find_package() to find all dependencies.
   - Are any of the dependencies of the project using a build system other
   than CMake? If so, they tend to take a bit more work to incorporate into a
   build via ExternalProject or FetchContent. If you can assume the developer
   provides those somehow, bringing them in by find_package() shifts
   responsibility for building them from the project to the developer (or
   whatever package manager they choose to use). This might be anywhere from
   entirely appropriate to entirely problematic depending on who your intended
   audience is.
   - How many dependencies does the project have and what is the maturity
   of each one? Will the project need to update any of those dependencies
   often (are they also being actively developed, do you need to follow recent
   work in them)? What will be the impact on developers working on the 

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

[Kai Wolf]

Well, as of right now, it currently isn’t possible to use Conan in a 
non-intrusive way. That is, using it for fetching dependencies without adapting 
the build configuration to it.
I’ve opened up a pull request (as well as a fix) for this issue here [1].

I’ve implemented pure CMake-based package management solutions based on 
ExternalProject_Add() (using a Superbuild approach) in the past as well as 
using Conan for managing dependencies currently for a client of mine.
Based on my experience, I’m confident that really the only reason to use Conan 
is that it solves the persistence of binary artifacts for you. Since Conan uses 
a client/server architecture you typically have something like an Artifactory 
server where Conan is able to store and fetch precompiled packages for you. 
Currently, CMake doesn’t offer something like this, but I think it should be 
trivially to implement (think of CDash but for storing binary artifacts).
One issue I have with Conan is that you are forced to duplicate some of your 
build logic that in my point of view really belongs to the build system and not 
to your package management solution.


[1] https://github.com/conan-io/conan/issues/4467
--
Kai Wolf
Kai Wolf - SW Consulting
www.kai-wolf.me 
XING  · LinkedIn 
 · GitHub 

> Am 19.02.2019 um 11:56 schrieb Craig Scott :
> 
> 
> 
> 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 management system or if I should use a 
> dedicated package management tool such as Conan.
> 
> For more information on Conan see: https://conan.io/ 
> 
> I am trying to understand the main difference between using Conan to manage 
> dependencies vs using CMakes "FetchContent" module. Are there any compelling 
> reasons to prefer something like Conan?
> 
> Excellent question, one that I think deserves a more detailed answer than I 
> can provide here, but I'll try to hit the main points as I see them.
> 
> Personally, I think there is no "right answer" or "one size fits all" when it 
> comes to package management for a CMake project. What works well for one 
> situation, person or project may not be as convenient or suitable for 
> another. There are competing needs and views, some of which are personal 
> preferences, others are hard requirements from things like OS distribution 
> policies for packaging. Even just the maturity of a project can have a big 
> influence on how developers may prefer to handle its dependencies and handle 
> it as a dependency of other projects.
> 
> The key thing for me is that the developer should ideally have choices when 
> it comes to this area. If a project hard-codes that its dependencies must 
> come from a particular provider (whether that be Conan, Hunter, vcpkg or some 
> other system), this might not be compatible with what the developer's 
> situation allows. You would need to weigh up whether it makes sense to lock 
> the developer into a particular package manager if they want to use your 
> project or not. An inappropriate choice here can mean lower adoption of the 
> project as some may reject it for consideration based on this point alone.
> 
> If instead a project relies only on find_package() to find its dependencies, 
> then it is up to the developer to ensure they are all available. This could 
> be done using whatever package manager the developer finds convenient, or 
> they could build the dependency projects from source individually or they 
> might set up a superbuild parent project that builds the dependencies in the 
> required order and makes dependees available to dependers. This gives good 
> flexibility at the cost of more responsibility on the developer than perhaps 
> some would want (again, it will be highly situation-dependent).
> 
> A drawback with find_package() is that it assumes you actually have a 
> packageable project. For a variety of reasons, this may not be the case. 
> Consider a large, complex project in its early stages and where multiple 
> teams are working on different subprojects which all get combined into some 
> larger whole. Each of the subprojects may need to be able to build on their 
> own with their own smaller subset of dependencies, but they also need to be 
> able to be incorporated into a larger build (think of different teams working 
> on core toolkits, rendering engines, different algorithm strategies, multiple 
> GUI applications, backend components, etc). No-one may know yet how it should 
> get packaged up and everyone might be focused on just getting a minimal 
> viable prototype up and running as a technical demonstrator. For a case like 
> that, neither find_package() nor a package manager really fits the workflow. 
> In this situation though, 

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

[Kai Wolf]

Well, as of right now, it currently isn’t possible to use Conan in a 
non-intrusive way. That is, using it for fetching dependencies without adapting 
the build configuration to it.
I’ve opened up a pull request (as well as a fix) for this issue here [1].

I’ve implemented pure CMake-based package management solutions based on 
ExternalProject_Add() (using a Superbuild approach) in the past as well as 
using Conan for managing dependencies currently for a client of mine.
Based on my experience, I’m confident that really the only reason to use Conan 
is that it solves the persistence of binary artifacts for you. Since Conan uses 
a client/server architecture you typically have something like an Artifactory 
server where Conan is able to store and fetch precompiled packages for you. 
Currently, CMake doesn’t offer something like this, but I think it should be 
trivially to implement (think of CDash but for storing binary artifacts).
One issue I have with Conan is that you are forced to duplicate some of your 
build logic that in my point of view really belongs to the build system and not 
to your package management solution.


[1] https://github.com/conan-io/conan/issues/4467 

--
Kai Wolf
Kai Wolf - SW Consulting
www.kai-wolf.me 
XING  · LinkedIn 
 · GitHub 

> Am 19.02.2019 um 11:56 schrieb Craig Scott :
> 
> 
> 
> 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 management system or if I should use a 
> dedicated package management tool such as Conan.
> 
> For more information on Conan see: https://conan.io/ 
> 
> I am trying to understand the main difference between using Conan to manage 
> dependencies vs using CMakes "FetchContent" module. Are there any compelling 
> reasons to prefer something like Conan?
> 
> Excellent question, one that I think deserves a more detailed answer than I 
> can provide here, but I'll try to hit the main points as I see them.
> 
> Personally, I think there is no "right answer" or "one size fits all" when it 
> comes to package management for a CMake project. What works well for one 
> situation, person or project may not be as convenient or suitable for 
> another. There are competing needs and views, some of which are personal 
> preferences, others are hard requirements from things like OS distribution 
> policies for packaging. Even just the maturity of a project can have a big 
> influence on how developers may prefer to handle its dependencies and handle 
> it as a dependency of other projects.
> 
> The key thing for me is that the developer should ideally have choices when 
> it comes to this area. If a project hard-codes that its dependencies must 
> come from a particular provider (whether that be Conan, Hunter, vcpkg or some 
> other system), this might not be compatible with what the developer's 
> situation allows. You would need to weigh up whether it makes sense to lock 
> the developer into a particular package manager if they want to use your 
> project or not. An inappropriate choice here can mean lower adoption of the 
> project as some may reject it for consideration based on this point alone.
> 
> If instead a project relies only on find_package() to find its dependencies, 
> then it is up to the developer to ensure they are all available. This could 
> be done using whatever package manager the developer finds convenient, or 
> they could build the dependency projects from source individually or they 
> might set up a superbuild parent project that builds the dependencies in the 
> required order and makes dependees available to dependers. This gives good 
> flexibility at the cost of more responsibility on the developer than perhaps 
> some would want (again, it will be highly situation-dependent).
> 
> A drawback with find_package() is that it assumes you actually have a 
> packageable project. For a variety of reasons, this may not be the case. 
> Consider a large, complex project in its early stages and where multiple 
> teams are working on different subprojects which all get combined into some 
> larger whole. Each of the subprojects may need to be able to build on their 
> own with their own smaller subset of dependencies, but they also need to be 
> able to be incorporated into a larger build (think of different teams working 
> on core toolkits, rendering engines, different algorithm strategies, multiple 
> GUI applications, backend components, etc). No-one may know yet how it should 
> get packaged up and everyone might be focused on just getting a minimal 
> viable prototype up and running as a technical demonstrator. For a case like 
> that, neither find_package() nor a package manager really fits 

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

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 management system or if I should
>> use a dedicated package management tool such as Conan.
>>
>> For more information 

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

Re: [CMake] CMake Dependence on C: drive?

[J. Caleb Wherry]

Seems strange. Just yesterday I pulled down 3.13.4 and had no issues. I
check cmake into our repo so it gets invoked on an assortment of different
drives. I do the same thing you do and just change our bat config file to
point to the new cmake binary. Never had any issues.

I am running on Win7 but colleagues use Win10 and have not had any issues
either.

All that to say: shouldn’t be an issue.

-Caleb

On Tue, Feb 19, 2019 at 5:05 PM Michael Jackson 
wrote:

> Currently using CMake 3.13.3 on Windows 10. I have “installed” cmake
> through the .zip download and placed it in E:\DREAM3D_SDK\ 
> cmake-3.13.3-win64-x64.
>
>
>
>
> If I now try to use that cmake to configure my source codes I get very
> strange errors (It cannot parse a simple project command) and then
> complains that it cannot find a CMake_MAKE_PROGRAM matching the “-G Ninja”.
>
>
>
> I then went back to using the same version of CMake, but placed on the
> C:/DREAM3D_SDK/cmake-3.13.3-win64-x64 and now everything works as in the
> past, no problems. I have a .bat file that sets up my environment with
> needed paths and such. The ONLY difference between the 2 invocations was
> that I changed the path to reflect the alternate location of CMake. I can
> have 2 difference command prompts open based on this difference and one
> works and one does not.
>
>
> Was/Is there a known limitation where CMake _*must*_ be run from the C:
> drive?
>
>
>
> --
>
> Michael Jackson | Owner, President
>
>   BlueQuartz Software
>
> [e] mike.jack...@bluequartz.net
>
> [w] www.bluequartz.net
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 
Sent from my iPhone SE
-- 

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] Remove folders created by install

[Kuba Ober]

Use something to read the manifest, extract paths from it, remove the 
duplicates, then iterate them, and remove the ones that are empty. It’d be a 
bad idea probably to remove ones that are not empty.

Cheers, Kuba

> 16 feb. 2019 kl. 09:47 skrev Felix Crazzolara :
> 
> Hi everyone
> 
> For my smaller projects I'd like to have 'uninstall' functionality. To remove 
> installed files I can call:
> 
> xargs rm < build/install_manifest.txt
> 
> Unfortunately this won't delete any folders generated by the installation. Is 
> there a different file that keeps track of the created directories, or what 
> is the recommended way to implement such functionality?
> 
> Example:
> Suppose that I install _some_header.hpp in 
> /include// using the command install(TARGETS 
>  EXPORT -targets ARCHIVE DESTINATION lib 
> PUBLIC_HEADER DESTINATION include/) then I want not only to 
> remove /include//_some_header.hpp, but 
> also the directory /include//.
> 
> Cheers,
> 
> Felix Crazzolara
> 
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
-- 

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] CMake Dependence on C: drive?

[Michael Jackson]

Currently using CMake 3.13.3 on Windows 10. I have “installed” cmake through 
the .zip download and placed it in E:\DREAM3D_SDK\ cmake-3.13.3-win64-x64. 

 

If I now try to use that cmake to configure my source codes I get very strange 
errors (It cannot parse a simple project command) and then complains that it 
cannot find a CMake_MAKE_PROGRAM matching the “-G Ninja”.

 

I then went back to using the same version of CMake, but placed on the 
C:/DREAM3D_SDK/cmake-3.13.3-win64-x64 and now everything works as in the past, 
no problems. I have a .bat file that sets up my environment with needed paths 
and such. The ONLY difference between the 2 invocations was that I changed the 
path to reflect the alternate location of CMake. I can have 2 difference 
command prompts open based on this difference and one works and one does not. 


Was/Is there a known limitation where CMake _must_ be run from the C: drive?

 

--

Michael Jackson | Owner, President

  BlueQuartz Software

[e] mike.jack...@bluequartz.net

[w] www.bluequartz.net

-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Craig Scott]

(dropping the cmake-developers list since this is really a user issue)


On Wed, Feb 20, 2019 at 2:34 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* - Put
>my sub-projects (my own custom libraries) into their own independent git
>repos and pull them into my main project using "FetchContent". Then when I
>run "FetchContent" it will checkout the sub-projects and I will have all of
>the source code available. I am hoping if I do this any changes I make to
>the sub-projects can easily be committed and pushed back to their own
>independent repositories.
>- The alternative to this would be to put my own sub-projects into
>   their own Conan packages and use Conan to get them from the main 
> project.
>   But I am thinking since they will change frequently, "FetchContent" may 
> be
>   a better fit for this scenario.
>   - Maybe when the sub-project libraries reach a mature and stable
>   release they should be packaged into Conan and fetched in the main 
> project
>   from Conan at that point?
>
> Let me know what you think! :)
>

Sounds like you are making progress exploring things 

Re: [CMake] Problems with EnternalProjectAdd

[Thiago Crepaldi]

try using
SOURCE_DIR = ${CMAKE_BINARY_DIR}/freetype/src/freetype
CONFIGURE_COMMAND = ./autgen.sh && ./configure
BUILD_COMMAND = make

It should git clone into SOURCE_DIR, configure the source by running
CONFIGURE_COMMAND and build it using BUILD_COMMAND, You may need
INSTALL_COMMAND = "" if you dont want to make install it


On Mon, Feb 18, 2019 at 9:51 PM workbe...@gmx.at  wrote:

> I played around a bit a now have the following:
>
> set(BUILD_ENV "${CMAKE_BINARY_DIR}/build_env" CACHE STRING INTERNAL)
> set(LIBRARY_DIR "${CMAKE_BINARY_DIR}/lib" CACHE STRING INTERNAL)
>
>  ExternalProject_Add(
>  freetype
>  PREFIX "${BUILD_ENV}/freetype"
>  GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git;
>  GIT_TAG 64bit
>  BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype &&
> ./autgen.sh && ./configure && make"
>  LOG_DOWNLOAD ON
>  LOG_INSTALL ON
>  LOG_CONFIGURE ON
>  LOG_BUILD ON
>  LOG_TEST ON
>  LOG_INSTALL ON
>  )
>
> The logs are telling me: CMake Error: The source directory
> "/home/stuv/data/projects/programming/bsUltimate/build/build_env/freetype/src/freetype"
>
> does not appear to contain CMakeLists.txt.
>
> Isn't the BUILD_COMMAND there if there is no CMakeLists.txt file
> available for building ? not many project provide cmake build files
>
>
> best regards!
>
>
>
>
>
>
> On 19.02.19 06:43, Michael Ellery wrote:
> > CMAKE_BUILD_DIR is not a standard variable (did you mean
> CMAKE_BINARY_DIR ?) - and the error seems to indicate that the variable is
> indeed empty so it tries to create the project directory at the root level.
> >
> > -Mike
> >
> >> On Feb 18, 2019, at 8:58 PM, workbe...@gmx.at  wrote:
> >>
> >> Hi again,
> >>
> >> i try to install my dependencies with ExternalProjectAdd but it gives
> me troubles... what's wrong with
> >>
> >>
> >>  ExternalProject_Add(
> >>  freetype
> >>  PREFIX "${CMAKE_BUILD_DIR}/freetype"
> >>  GIT_REPOSITORY "
> https://github.com/brooklynpacket/freetype2.git;
> >>  GIT_TAG 64bit
> >>  BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype &&
> ./autgen.sh && ./configure && make"
> >>  LOG_DOWNLOAD ON
> >>  LOG_INSTALL ON
> >>  LOG_CONFIGURE ON
> >>  LOG_BUILD ON
> >>  LOG_TEST ON
> >>  LOG_INSTALL ON
> >>  )
> >>
> >> best regards!
> >>
> >> --
> >>
> >> Powered by www.kitware.com
> >>
> >> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >>
> >> Kitware offers various services to support the CMake community. For
> more information on each offering, please visit:
> >>
> >> CMake Support: http://cmake.org/cmake/help/support.html
> >> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> >> CMake Training Courses: http://cmake.org/cmake/help/training.html
> >>
> >> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> https://cmake.org/mailman/listinfo/cmake
> >
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>


-- 
Thiago
-- 

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] Problems with EnternalProjectAdd

[Michael Ellery]

Here’s a complete example that works on my system - maybe you can tweak it to 
your liking:


cmake_minimum_required (VERSION 3.9.0)
include (ExternalProject)
project (simple_ep)
set(BUILD_ENV "${CMAKE_BINARY_DIR}/build_env" CACHE STRING INTERNAL)
ExternalProject_Add(
  freetype
  PREFIX "${BUILD_ENV}/freetype"
  GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git;
  GIT_TAG 64bit
  BUILD_IN_SOURCE true
  CONFIGURE_COMMAND
./autogen.sh
COMMAND
./configure
  BUILD_COMMAND
make
  TEST_COMMAND ""
  INSTALL_COMMAND ""
  LOG_DOWNLOAD ON
  LOG_INSTALL ON
  LOG_CONFIGURE ON
  LOG_BUILD ON
  LOG_TEST ON
  LOG_INSTALL ON
)

add_library (ft_lib STATIC IMPORTED GLOBAL)
ExternalProject_Get_Property (freetype SOURCE_DIR)
set_target_properties (ft_lib PROPERTIES
  IMPORTED_LOCATION
${SOURCE_DIR}/objs/.libs/libfreetype.a)
add_dependencies (ft_lib freetype)
add_executable (app main.cpp)
target_link_libraries(app ft_lib)


-Mike

> On Feb 18, 2019, at 10:25 PM, workbe...@gmx.at  wrote:
> 
> Can't i somehow output the pwd ??
> 
> best regards!
> 
> On 19.02.19 07:04, workbe...@gmx.at wrote:
>> Now i'm getting:
>> 
>>  Command failed: No such file or directory
>> 
>>'cd 
>> /home/stuv/data/projects/programming/bsUltimate/build/build_env/freetype/src/freetype
>>  && ./autogen.sh && ./configure && make'
>> 
>> but when i go to my bsUltimate path and type that command it works...
>> 
>> 
>> 
>> best regards!
>> 
>> On 19.02.19 06:57, Romain LEGUAY wrote:
>>> Hi,
>>> 
>>> I think you need to set the variable CONFIGURE_COMMAND to empty like this:
>>> 
 ExternalProject_Add(
 freetype
 PREFIX "${BUILD_ENV}/freetype"
 GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git;
 GIT_TAG 64bit
>>>  CONFIGURE_COMMAND ""
 BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype && 
 ./autgen.sh && ./configure && make"
 LOG_DOWNLOAD ON
 LOG_INSTALL ON
 LOG_CONFIGURE ON
 LOG_BUILD ON
 LOG_TEST ON
 LOG_INSTALL ON
 )
>>> 
>>> Envoyé de mon iPad
>>> 
>>> Le 19 févr. 2019 à 06:51, workbe...@gmx.at  a écrit :
>>> 
 I played around a bit a now have the following:
 
 set(BUILD_ENV "${CMAKE_BINARY_DIR}/build_env" CACHE STRING INTERNAL)
 set(LIBRARY_DIR "${CMAKE_BINARY_DIR}/lib" CACHE STRING INTERNAL)
 
 ExternalProject_Add(
 freetype
 PREFIX "${BUILD_ENV}/freetype"
 GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git;
 GIT_TAG 64bit
 BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype && 
 ./autgen.sh && ./configure && make"
 LOG_DOWNLOAD ON
 LOG_INSTALL ON
 LOG_CONFIGURE ON
 LOG_BUILD ON
 LOG_TEST ON
 LOG_INSTALL ON
 )
 
 The logs are telling me: CMake Error: The source directory 
 "/home/stuv/data/projects/programming/bsUltimate/build/build_env/freetype/src/freetype"
  does not appear to contain CMakeLists.txt.
 
 Isn't the BUILD_COMMAND there if there is no CMakeLists.txt file available 
 for building ? not many project provide cmake build files
 
 
 best regards!
 
 
 
 
 
 
 On 19.02.19 06:43, Michael Ellery wrote:
> CMAKE_BUILD_DIR is not a standard variable (did you mean CMAKE_BINARY_DIR 
> ?) - and the error seems to indicate that the variable is indeed empty so 
> it tries to create the project directory at the root level.
> 
> -Mike
> 
>> On Feb 18, 2019, at 8:58 PM, workbe...@gmx.at  wrote:
>> 
>> Hi again,
>> 
>> i try to install my dependencies with ExternalProjectAdd but it gives me 
>> troubles... what's wrong with
>> 
>> 
>> ExternalProject_Add(
>> freetype
>> PREFIX "${CMAKE_BUILD_DIR}/freetype"
>> GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git;
>> GIT_TAG 64bit
>> BUILD_COMMAND "cd ${CMAKE_BUILD_DIR}/freetype/src/freetype && 
>> ./autgen.sh && ./configure && make"
>> LOG_DOWNLOAD ON
>> LOG_INSTALL ON
>> LOG_CONFIGURE ON
>> LOG_BUILD ON
>> LOG_TEST ON
>> LOG_INSTALL ON
>> )
>> 
>> best regards!
>> 
>> -- 
>> 
>> Powered by www.kitware.com
>> 
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ
>> 
>> Kitware offers various services to support the CMake community. For more 
>> information on each offering, please visit:
>> 
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>> 
>> Visit 

[cmake-developers] Error in ExternalProject_Add ??

[workbe...@gmx.at]

Hi everyone,

i'm trying to get ExternalProject_Add to work for a day now and i come 
to a strange error, first the code:


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


    include(ExternalProject)
    ExternalProject_Add(
        freetype
        TMP_DIR ${BULD_DIR}
        LIST_SEPARATOR ;
        PREFIX ${BUILD_ENV}/freetype
        GIT_REPOSITORY "https://github.com/brooklynpacket/freetype2.git;
        GIT_TAG 64bit
        #CMAKE_ARGS -DCMAKE_INSTALL_PREFIX={LIBRARY_DIR}/freetype
        CONFIGURE_COMMAND ""
        BINARY_DIR "${BULD_ENV}"
        BUILD_COMMAND "cd ${BUILD_ENV}/freetype/src/freetype && 
./autogen.sh && ./configure && make"

        LOG_DOWNLOAD ON
        LOG_INSTALL ON
        LOG_CONFIGURE ON
        LOG_BUILD ON
        LOG_TEST ON
        LOG_INSTALL ON
        )


now the error i get is:

CMake Error at 
/home/stuv/data/projects/programming/bsUltimate/build/build_env/freetype/src/freetype-stamp/freetype-build-.cmake:16 
(message):

  Command failed: No such file or directory

   'cd 
/home/stuv/data/projects/programming/bsUltimate/build/build_env/freetype/src/freetype 
&& ./autogen.sh && ./configure && make'


  See also

/home/stuv/data/projects/programming/bsUltimate/build/build_env/freetype/src/freetype-stamp/freetype-build-*.log

The log files are empty and when i run the command from the command line 
it's working... is this a bug or am i doing something really wrong ?



best regards!





--

Powered by www.kitware.com

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

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

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

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

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

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

[Craig Scott]

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 management system or if I should use a
> dedicated package management tool such as Conan.
>
> For more information on Conan see: https://conan.io/
>
> I am trying to understand the main difference between using Conan to
> manage dependencies vs using CMakes "FetchContent" module. Are there any
> compelling reasons to prefer something like Conan?
>

Excellent question, one that I think deserves a more detailed answer than I
can provide here, but I'll try to hit the main points as I see them.

Personally, I think there is no "right answer" or "one size fits all" when
it comes to package management for a CMake project. What works well for one
situation, person or project may not be as convenient or suitable for
another. There are competing needs and views, some of which are personal
preferences, others are hard requirements from things like OS distribution
policies for packaging. Even just the maturity of a project can have a big
influence on how developers may prefer to handle its dependencies and
handle it as a dependency of other projects.

The key thing for me is that the developer should ideally have choices when
it comes to this area. If a project hard-codes that its dependencies must
come from a particular provider (whether that be Conan, Hunter, vcpkg or
some other system), this might not be compatible with what the developer's
situation allows. You would need to weigh up whether it makes sense to lock
the developer into a particular package manager if they want to use your
project or not. An inappropriate choice here can mean lower adoption of the
project as some may reject it for consideration based on this point alone.

If instead a project relies only on find_package() to find its
dependencies, then it is up to the developer to ensure they are all
available. This could be done using whatever package manager the developer
finds convenient, or they could build the dependency projects from source
individually or they might set up a superbuild parent project that builds
the dependencies in the required order and makes dependees available to
dependers. This gives good flexibility at the cost of more responsibility
on the developer than perhaps some would want (again, it will be highly
situation-dependent).

A drawback with find_package() is that it assumes you actually have a
packageable project. For a variety of reasons, this may not be the case.
Consider a large, complex project in its early stages and where multiple
teams are working on different subprojects which all get combined into some
larger whole. Each of the subprojects may need to be able to build on their
own with their own smaller subset of dependencies, but they also need to be
able to be incorporated into a larger build (think of different teams
working on core toolkits, rendering engines, different algorithm
strategies, multiple GUI applications, backend components, etc). No-one may
know yet how it should get packaged up and everyone might be focused on
just getting a minimal viable prototype up and running as a technical
demonstrator. For a case like that, neither find_package() nor a package
manager really fits the workflow. In this situation though, FetchContent is
a perfect fit, since it doesn't require any packaging to already be in
place, it needs no external tools other than CMake and it gives each
project precise control over its dependencies down to the individual commit
to bring in for each one.

With the above in mind, perhaps the following few questions may be helpful
in clarifying what your constraints are and maybe steering you more toward
one way or the other:

   - Will the project be incorporated into a Linux distribution at some
   point (not just be installed on Linux, but be part of the actual Linux
   distribution as provided by its own native package manager)? If so, I would
   expect this would pretty much eliminate using any package manager and
   instead require that you use find_package() to find all dependencies.
   - Are any of the dependencies of the project using a build system other
   than CMake? If so, they tend to take a bit more work to incorporate into a
   build via ExternalProject or FetchContent. If you can assume the developer
   provides those somehow, bringing them in by find_package() shifts
   responsibility for building them from the project to the developer (or
   whatever package manager they choose to use). This might be anywhere from
   entirely appropriate to entirely problematic depending on who your intended
   audience is.
   - How many dependencies does the project have and what is the maturity
   of each one? Will the project need to update any of those dependencies
   often (are they also being actively developed, do you need to follow recent
   work in them)? What will be the impact on developers working on the 

[Cmake-commits] CMake branch, release, updated. v3.14.0-rc2-13-g13f0201

[Kitware Robot via Cmake-commits]

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

The branch, release has been updated
   via  13f020198fe858437f24a3fe0c349a1618e70d7b (commit)
   via  7814796e0777e5fc767cca453200b9f8107848fe (commit)
   via  890bae524c6b97d29ffcc3fe5a6a30235d800348 (commit)
   via  5c171ca898f92e07cb68dd7fa77d0a993b08cc9c (commit)
   via  9502276f8272cf8ed10ceafe4413b0e24cc6535f (commit)
   via  bee6597ac548e7ddd42cfa972e2a4cefa1ec3e59 (commit)
  from  926a97e97520bcdf509126e03a3d2f40ee20d479 (commit)

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

- Log -
---

Summary of changes:
 Modules/CMakeDetermineCompilerABI.cmake |  6 
 Modules/FindBoost.cmake |  8 +
 Modules/Platform/UnixPaths.cmake| 14 ++--
 Source/cmLocalGenerator.cxx | 61 +++--
 4 files changed, 52 insertions(+), 37 deletions(-)


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

[Cmake-commits] CMake branch, master, updated. v3.14.0-rc2-132-g7574e16

[Kitware Robot via Cmake-commits]

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

The branch, master has been updated
   via  7574e16096abe57d44cde4e6380a22d940cde98c (commit)
   via  2bff8513f22ae02d1559851d0eb814083d015a2e (commit)
   via  9cab31cc79b9c19f2a5121a392a3498d06e25723 (commit)
   via  2dd2079152ceda32a7e5f330f7182fd658716c41 (commit)
   via  bc34282da63c3f25c17fee73c97fcc46a0a164ca (commit)
   via  13f020198fe858437f24a3fe0c349a1618e70d7b (commit)
   via  7814796e0777e5fc767cca453200b9f8107848fe (commit)
   via  55ad9304ed87f365e69b5dc01d5b07d25aecc9e2 (commit)
   via  890bae524c6b97d29ffcc3fe5a6a30235d800348 (commit)
   via  5c171ca898f92e07cb68dd7fa77d0a993b08cc9c (commit)
   via  9502276f8272cf8ed10ceafe4413b0e24cc6535f (commit)
   via  bee6597ac548e7ddd42cfa972e2a4cefa1ec3e59 (commit)
   via  706b93fa558c5a2e0e45a7068b5039d1f40fbc90 (commit)
  from  2a1f6617911da55e6563a775c807270a7f566b18 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7574e16096abe57d44cde4e6380a22d940cde98c
commit 7574e16096abe57d44cde4e6380a22d940cde98c
Merge: 2bff851 13f0201
Author: Brad King 
AuthorDate: Tue Feb 19 07:57:42 2019 -0500
Commit: Brad King 
CommitDate: Tue Feb 19 07:57:42 2019 -0500

Merge branch 'release-3.14'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2bff8513f22ae02d1559851d0eb814083d015a2e
commit 2bff8513f22ae02d1559851d0eb814083d015a2e
Merge: 9cab31c 706b93f
Author: Brad King 
AuthorDate: Tue Feb 19 12:56:20 2019 +
Commit: Kitware Robot 
CommitDate: Tue Feb 19 07:56:41 2019 -0500

Merge topic 'modernize-for-loops-c-arrays'

706b93fa55 Modernize: C-arrays and loops over them

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9cab31cc79b9c19f2a5121a392a3498d06e25723
commit 9cab31cc79b9c19f2a5121a392a3498d06e25723
Merge: 2dd2079 55ad930
Author: Craig Scott 
AuthorDate: Tue Feb 19 12:55:59 2019 +
Commit: Kitware Robot 
CommitDate: Tue Feb 19 07:56:06 2019 -0500

Merge topic 'readme-msys2'

55ad9304ed README: Explain how to bootstrap via MSYS2 on Windows

Acked-by: Kitware Robot 
Acked-by: Bartosz 
Merge-request: !2983


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2dd2079152ceda32a7e5f330f7182fd658716c41
commit 2dd2079152ceda32a7e5f330f7182fd658716c41
Merge: bc34282 890bae5
Author: Brad King 
AuthorDate: Tue Feb 19 12:53:50 2019 +
Commit: Kitware Robot 
CommitDate: Tue Feb 19 07:54:57 2019 -0500

Merge topic 'fix-legacy-implicit-includes'

890bae524c Do not explicitly report "standard" include directories as 
implicit
5c171ca898 Restore unconditional use of "standard" include directories
9502276f82 Prefix implicit include directories with sysroot on construction

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bc34282da63c3f25c17fee73c97fcc46a0a164ca
commit bc34282da63c3f25c17fee73c97fcc46a0a164ca
Merge: 2a1f661 bee6597
Author: Brad King 
AuthorDate: Tue Feb 19 12:53:39 2019 +
Commit: Kitware Robot 
CommitDate: Tue Feb 19 07:53:47 2019 -0500

Merge topic 'FindBoost-layout-tagged'

bee6597ac5 FindBoost: Find boost libraries built with --layout=tagged

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=55ad9304ed87f365e69b5dc01d5b07d25aecc9e2
commit 55ad9304ed87f365e69b5dc01d5b07d25aecc9e2
Author: Brad King 
AuthorDate: Mon Feb 18 10:43:30 2019 -0500
Commit: Brad King 
CommitDate: Tue Feb 19 07:10:59 2019 -0500

README: Explain how to bootstrap via MSYS2 on Windows

Inspired-by: Bartosz Kosiorek 

diff --git a/README.rst b/README.rst
index 775463e..11bafca 100644
--- a/README.rst
+++ b/README.rst
@@ -67,11 +67,24 @@ choice. Once this has finished successfully, run ``make`` 
and
 Windows
 ^^^
 
-You need to download and install a binary release of CMake in order to build
-CMake.  You can get these releases from the `CMake Download Page`_.  Then
-proceed with the instructions below.
+There are two ways for building CMake under Windows:
+
+1. Compile with MSVC from VS 2015 or later.
+   You need to download and install a binary release of CMake.  You can get
+   these releases from the `CMake Download Page`_.  Then proceed with the
+   instructions below for `Building CMake with CMake`_.
+
+2. Bootstrap with MinGW under MSYS2.
+   Download and install `MSYS2`_.  Then install the required build tools::
+
+ $ pacman -S --needed git base-devel mingw-w64-x86_64-gcc
+
+   and 

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

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 management system or if I should
>> use a dedicated package management tool such as Conan.
>>
>> For more information 

[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-commits] CMake branch, master, updated. v3.14.0-rc2-133-g18ff514

[Kitware Robot via Cmake-commits]

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

The branch, master has been updated
   via  18ff514b52600a6fb37ca6fd7d38e7e3aac7129b (commit)
  from  7574e16096abe57d44cde4e6380a22d940cde98c (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=18ff514b52600a6fb37ca6fd7d38e7e3aac7129b
commit 18ff514b52600a6fb37ca6fd7d38e7e3aac7129b
Author: Kitware Robot 
AuthorDate: Wed Feb 20 00:01:08 2019 -0500
Commit: Kitware Robot 
CommitDate: Wed Feb 20 00:01:08 2019 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 9c45022..b324571 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 14)
-set(CMake_VERSION_PATCH 20190219)
+set(CMake_VERSION_PATCH 20190220)
 #set(CMake_VERSION_RC 1)

---

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


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