Hi Ray,
This still has the same problem. If I use FindBoost in project B, I can
use BOOST_ROOT to be able to find it. This works fine. Now, if I try to
compile project C, I can set B_ROOT for FindB, but then Boost will not
be found, because it is not in B_ROOT, so project C will not compile.
That is, unless Boost sets absolute paths for all its libraries. Which
is something we have would have to do manually with custom CMake code as
per option 4.
I don't find it weird that CMake should be able to find Boost in project
C, since Boost was already found and used in project B. And we only link
to project B explicitly in project C, not to Boost. Actually in C we
don't use any Boost functionality other than what is used inside of B.
So why should C then explicitly look for Boost, require BOOST_ROOT to do
so, then do a lot of checks to see if B actually uses Boost, and in that
case link to it, when we don't use Boost in C?
So let's take Trilinos as an example, which is quite a big library,
which depends on a lot of libraries as well. In every project that
builds upon it (but does not even use functionality of any libraries),
we would have to set: SCALAPACK_ROOT, LAPACK_ROOT, BLAS_ROOT,
BOOST_ROOT, GTEST_ROOT, BLACS_ROOT, UMFPACK_ROOT, MKL_ROOT, etc... and
then inside the CMakeFiles.txt do a find_package(Trilinos),
find_package(Scalapack), find_package(LAPACK), etc... just to compile
int main() {} with one call to a Trilinos function inside of it. I'd say
that it should be enough to just do a find_package(Trilinos).
Note that by finding a library, I mean that it should know where it is,
by for instance using absolute paths at linking time, which I think is
sufficient. I don't mean doing all the things that are done in Find*, or
going through directories to find the library.
Sven
On 06/30/2016 12:10 PM, Raymond Wan wrote:
> Hi Sven,
>
>
> On Thu, Jun 30, 2016 at 4:59 PM, 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}:
>
> Well, I presented some options to you. Perhaps there are others, but
> if none of them are right for you then there's nothing more I can add,
> I think.
>
>
>> 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.
>
> Sure. So, during the CMake run, you can set CMAKE_INSTALL_PREFIX to
> be something like ~/lib/ or ~/mylib/ or whatever.
>
>
>> Therefore, you will never find libraries that are installed in the
>> standard system directories where CMake looks for the libraries. By
>
> Well, I wasn't suggesting that you use Find_Package as-is. I mean the
> phrase "CMake looks for the libraries" isn't quite correct here since
> its behaviour is affected by the Find_Package's implementation.
>
> Presumably, you will need to write your own for the modules you're
> working with. One person would write it and this file would be
> shared.
>
> How it would work is "something like" (i.e., you need to look at how
> it works yourself) the Boost library. With that, you can set
> BOOST_ROOT to override the system-installed version. (Take a look at:
> https://cmake.org/cmake/help/v3.3/module/FindBoost.html)
>
> I think I said this early on, but perhaps I didn't explain it very well.
>
> Thus, each user would set an environment variable that would affect
> the search path of this Find_Package that you wrote. If this is
> troublesome, then you can add some favourite paths like ~/lib/ and
> ~/mylib/ as default paths to the search first.
>
> I think it is a bit unreasonable for CMake to "automatically" know
> where libraries are stored for each user other than performing a
> recursive search down ~/ . (I suppose that's possible.) To reduce
> the search space for binary programs that we've installed in ~/, we
> would set the PATH variable. I don't think it's that much different
> from setting something like BOOST_ROOT and then getting a Find_Package
> that you've written to use this as the starting point for a search.
>
> I mean, it seems strange to expect CMake to be able to find archive
> files by itself but, by default, we do not expect the same for
> executable files...
>
> Ray
--
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
