Thanks much, Tim!
Hemant
From: CMake On Behalf Of Tim Rae
Sent: Tuesday, June 19, 2018 9:39 AM
To: cmake@cmake.org
Subject: Re: [CMake] How do you handle recursive dependencies in CMake
Hi all,
I spent a bit of time working on this issue the last few days, and since I
didn'
Hi all,
I spent a bit of time working on this issue the last few days, and since I
didn't see a satisfactory answer in this thread I thought I'd resurrect the
thread since it's one of the first google hits.
it seems that all you need to do to solve the problem of transitive
dependencies is make yo
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_p
On 2016-06-30 10:59+0200 Sven Baars wrote:
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 so
Hey again Marcel,
Your reply got me thinking. I just checked again, and found that I just
have to set the LIBRARY_PATH correctly as well. After that everything
seems to work. Apparently this was not done in the right way. Since I
have to use PATH anyway to find the FoobarConfig.cmake files, it is
Hey Marcel,
They are indeed always set correctly, and for this reason, find_package
is also always able to find these packages, which is great, and this is
why I love using CMake, but then it still happens that when you don't
explicitly use find_package, so in this case I don't use find_package(A)
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 tha
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. 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
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 wrote:
> This is a reply to the options tha
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 mak
Hi Sven,
On Thu, Jun 30, 2016 at 6:40 PM, Sven Baars 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:
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
Hi Sven,
On Thu, Jun 30, 2016 at 4:59 PM, Sven Baars 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
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 f
On 29 June 2016 at 05:08, Raymond Wan wrote:
> I agree that what we're observing is a problem, but I don't think it is
that big.
I must admit I am mixing a bit of my own situation here and trying to think
about the most general case. It's just there is a missing bit in the
dependency search syste
On Wed, Jun 29, 2016 at 3:23 AM, Cfyz wrote:
> On 28 June 2016 at 17:19, Raymond Wan wrote:
>> I think if I were presented with the same problem as Sven, I'd <...> Or,
>> if that wasn't possible, use ExternalProject.
>> It's inefficient in terms of disk space, but at least A (assuming A
>> depend
Hello Sven, Raymond.
On 28 June 2016 at 16:07, Sven Baars wrote:
> Hence my question if there is some "right" way of doing this with CMake,
without all of the code I wrote to work around the problem.
I am under impression there is an important bit missing from CMake export
system. If some librar
Hi,
On Tue, Jun 28, 2016 at 8:41 PM, Cfyz wrote:
> dependencies' locations. Personally I do not agree with that as I see
> neither any way around specifying paths to dependencies not any substantial
> harm in that. Maybe I am missing something but as far as I've found there
> was not discussion
Hey Cfyz,
After reading your post to the list, it does indeed seem like we have
the same problem. I also wrote a lot of homebrew code you mentioned at
the end of the post, but it indeed always seems to always break
something for some user of the code, even though it seems to work for
everyone else
Hello.
I've posted a message a few days ago on a very similar subject. Didn't know
there was a discussion already.
The main problem in my opinion is that CMake target exporting system does
not handle transitive dependencies at all. CMake handles them correctly at
the build step, but not at the ex
Hey Ray,
Project A is used by many projects, and so is project B. So
ExternalProject is not the right solution. I just want to be able to fix
project B in such a way that people, including myself, can easily use it
without knowledge of where project A is located. The packages will all
be used most
Hi Sven,
On Tue, Jun 28, 2016 at 6:03 PM, Sven Baars wrote:
> The packages I use are installed in a non-standard path, because I don't
> have access to the system directories on most systems I work on, but are
> used by many other libraries. They are also all separate packages, not
> packages in
Hi Ray,
The packages I use are installed in a non-standard path, because I don't
have access to the system directories on most systems I work on, but are
used by many other libraries. They are also all separate packages, not
packages in the same source tree. I did not see my attachment on the
mail
Hi Sven,
On Tue, Jun 28, 2016 at 5:26 PM, Sven Baars wrote:
> Hey all,
>
> Since I did not receive a reply to my previous mail, I decided to write a
> minimal example explaining my problem, where I kept al the names as I used
> in my previous mails. I hope that after seeing my example, someone c
Hey all,
Since I did not receive a reply to my previous mail, I decided to write
a minimal example explaining my problem, where I kept al the names as I
used in my previous mails. I hope that after seeing my example, someone
can explain me what I am doing wrong here. I included a script that
repro
Hey Chuck,
In ATargets.cmake it says
add_library(a SHARED IMPORTED)
and in BTargets.cmake it says
add_library(b SHARED IMPORTED)
However, if I build C it will say
/usr/bin/ld: cannot find -la
when I do
find_package(B)
target_link_libraries(c b)
add_executable(main main.cpp)
If the projects are each providing their own Config.cmake file then you
probably will want to use those instead of Find modules. Instead of using
the Foo_Bar_LIBRARIES variable though, try using the actual imported
targets from the config files. Those should have the appropriate
dependency inform
In my case all projects provide their own FooBarConfig.cmake, but not a
FindFooBar.cmake. For this reason I wanted to use those, because I
thought it saves me the effort of writing a lot of FindFooBar.cmake
files, and it also seemed like the right way to do it, because it
provides things like FooBa
The FooBarConfig.cmake is something that should be generated by FooBar's
build. The reason you don't get absolute paths for the "libraries" from a
package config file is that they're not actually libraries but imported
targets. The imported target let's you treat "foo" as though it were a
librar
Hey everyone,
I posted a question on StackOverflow a while ago, but got no real answer
to my question there. I posted an answer there by myself, but this
solution does not work on every system. Since it also involves some
possible inconsistencies in the CMake documentation, I decided to ask
the qu
30 matches
Mail list logo
