[CMake] How do you handle recursive dependencies in CMake

[Marcel Loose]

Hi Sven,

Sorry to chime in so late. I was wondering, since you're mentioning
large computer clusters, don't you use the "module" system to select
which versions of which packages you want to use? If so, then (I assume)
your PATH and LD_LIBRARY_PATH environment variables will have been set
such that the correct binaries and libraries can be found, right? CMake
also searches for libraries in the paths specified in the environment
variables PATH and LIB (unfortunately not LD_LIBRARY_PATH). Isn't that
the way to tackle this problem?

Cheers,
Marcel Loose.


On 30/06/16 13:42, Sven Baars wrote:
> Hey Ray,
>
> For myself it is not a big problem either, but I don't want to tell
> users of my libraries that they have to look up how the administrators
> at their supercomputing facility compiled 20 other libraries so they can
> set  their environment variables in the right way, while at the same
> time making my own CMakeLists.txt files much longer (because I would
> need many more find_package calls for dependencies of dependencies that
> I don't use). Whereas if CMake would just provide some means of using
> absolute paths instead of targets for libraries, or attach the
> information about those paths to the targets or something like that,
> this would never be a problem, since in that case everything would be
> found automatically.
>
> Also, it still doesn't make sense to me that instead of one find_package
> call for a package I actually use, I also need 20 find_package calls for
> dependencies of that other package. Also it doesn't make sense that I
> would actually need these find_package calls, whereas if the packages
> were just installed in /usr/lib or something it would work without any
> knowledge of this package even being used.
>
> Something that causes problems is the case where you use either A1 or
> A2. Then in B you would do something like
>
> option(B_USE_A2 OFF "Use package A2 instead of A1")
>
> if (NOT B_USE_A2)
>     find_package(A1)
>     if (A1_FOUND)
>         ...
>         target_link_libraries(B ${A1_LIBRARIES})
>         ...
>     else()
>         set(B_USE_A2 ON)
> endif()
>
> if (B_USE_A2)
>     find_package(A2)
>     if (A2_FOUND)
>         ...
>         target_link_libraries(B ${A2_LIBRARIES})
>         ...
>     endif()
> endif()
>
> which makes sense, but then also in C instead of doing
>
> find_package(B)
> if (B_FOUND)
>     target_link_libraries(C ${B_LIBRARIES})
> endif()
>
> you would also have to do
>
> if (B_FOUND)
>     option(C_USE_A2 OFF "Use package A2 instead of A1, which is used in
> package B. Make sure C_USE_A2 is equal to what you used in package B as
> B_USE_A2")
>
>     if (NOT C_USE_A2)
>         find_package(A1)
>         if (A1_FOUND)
>             ...
>             target_link_libraries(C ${A1_LIBRARIES})
>             ...
>         else()
>             set(C_USE_A2 ON)
>     endif()
>
>     if (C_USE_A2)
>             find_package(A2)
>             if (A2_FOUND)
>                 ...
>                 target_link_libraries(C ${A2_LIBRARIES})
>                 ...
>             endif()
>     endif()
>     target_link_libraries(C ${B_LIBRARIES})
> endif()
>
> or something like that, which is quite silly. Especially the part where
> compilation fails if B_USE_A2 is unequal to C_USE_A2. In general, my
> CMakeLists.txt is a lot more complicated, so I'd prefer the option where
> I only look for B.
>
> Sven
>
> On 06/30/2016 01:05 PM, Raymond Wan wrote:
>> Hi Sven,
>>
>>
>> On Thu, Jun 30, 2016 at 6:40 PM, Sven Baars <s.baars at rug.nl> wrote:
>>> 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).
>> Perhaps I'm alone here, but I actually don't see this as being a "big" problem.
>>
>> For the environment variables, you can place them all in a bash script
>> and source it during log in.
>>
>> For all of the Find_Package calls, they only matter whenever you have
>> to re-run cmake.  I don't know what Trilinos is, but for something
>> that big, I presume it takes more time to compile it (during active
>> development) than to run cmake to look through all those paths...
>>
>> Ray

-------------- next part --------------
A non-text attachment was scrubbed...
Name: loose.vcf
Type: text/x-vcard
Size: 292 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160630/581d651d/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160630/581d651d/attachment.sig>