Hi,
On 30-Jun-16 16:01, Sven Baars wrote:
I don't think this is a solution to the problem, since then it seems
like the build will still fail for all our users unless they also build
all their packages from inside hunter.
What do you mean by "from inside hunter"? Users have to add
'hunter_add_package(YourProject)' + 'find_package(YourProject CONFIG
REQUIRED)' this is true. You want to avoid that?
If I wanted it to work just for
myself I could just use hardcoded paths. The problem is that I want a
portable way such that users can build my projects without losing
dependency information.
Hunter will download all dependencies automatically.
YourProjectConfig.cmake should contain all dependencies too so
'find_package(YourProject CONFIG REQUIRED)' is enough.
In the current situation they are forced to
copy-paste all of my CMakeLists.txt files and add their own stuff to
that. At least if I follow the guides on the wiki/the advice that I got
so far. That is, unless I misunderstand something, which I hope I do,
but no one pointed that out yet.
Sven
Ruslo
On 06/30/2016 02:41 PM, Nicholas Braden wrote:
If find_project is not enough, and ExternalProject's only problem is
build duplication, then I think it makes sense to consider a
CMake-based dependency manager such as hunter:
https://github.com/ruslo/hunter
On Thu, Jun 30, 2016 at 3:59 AM, Sven Baars <s.ba...@rug.nl> wrote:
This is a reply to the options that Ray gave. Here I will use the
package dependencies C -> B -> A{1,2}:
1) The "ad-hoc" method I first mentioned by setting
CMAKE_LIBRARY_OUTPUT_DIRECTORY.
As far as I understand, this would mean that every user of all of the
different projects would have to be forced to use this, and would not be
allowed to "install" anything anywhere else, which doesn't seem nice.
2) ExternalProject which will grab a repository and build it.
This will not work. One of the projects I use is Trilinos, which has
build of around 1GB. I don't want to pull and build that for every
project I have. Also the build flags that are used sometimes differ per
machine, not per project, so it would be nice if I could build it only
once per machine.
Also, in a more generalized sense, this would also mean that every
project I pull with ExtenalProject should also pull its own dependencies
with ExternalProject. So then if every project on my system used CMake,
this would mean that I would recursively rebuild my entire system for
every project I have. This doesn't seem right.
3) Some Find_Package () mechanism that will do a search for it.
The point I had is that we actually try to use this. However, the
find_package does not find all dependencies. And we don't know in
package C whether it depends on A1 or A2, because of build flags/CMake
checks that were used for project B. So we can't just do a find_package
for either A1 or A2, because we don't know which one was used unless we
perform all the CMake checks that were done in project B (in some cases
10k+ lines of CMake code).
4) Your option of including *.cmake files that provide the paths
[sorry, I might have misunderstood it].
This, so far, is the only option, because then B can tell us that it
used A2, not A1. This can just be done by providing absolute paths to
the libraries that were used in the compilation of B. But we are looking
for a standardized way to do this. I'd prefer to not have a lot of
custom code in all of my libraries.
Now some more information:
On supercomputers it is very common that every library on the system is
installed in a different directory. This is so every user can load their
own version of the library without breaking the system for others.
Therefore, you will never find libraries that are installed in the
standard system directories where CMake looks for the libraries. By
using PATH you can make it able to find the place where to look for the
FoobarConfig.cmake files, which is great when you want to build project
B, and this is also done automatically on all supercomputers I work on,
but those config files do not contain information on where the actual
libraries of project A are when you build project C. I guess Cfyz and me
think they should in some standardized way.
Sven
--
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:
http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake
