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)
ager 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 that Ray gave. Here I will use the
>> package dependencies C -> B -> A{1,2}:
>>
>> 1) The "ad-hoc"
en
On 06/30/2016 01:05 PM, Raymond Wan wrote:
> 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
hrough 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 wrote:
>> This is a reply to the options that Ray gave. Here I will use the
>> package dependencies C -> B -> A{1,2}:
&
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
oversight. Everything should be fine if there
> was an option to resolve and export transitive dependencies along the
> targets in CMake export() command. Probably this may be fixed by an
> external helper script (similar to CMakePackageConfigHelpers module)
> providing some function that tak
PATH correctly.
Sven
On 06/28/2016 12:25 PM, Raymond Wan wrote:
> 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 wor
n the
mailing list archive, so instead I just put it on Github. It can be
found here:
https://github.com/Sbte/cmake-example
I hope the example shows my workflow, and also what doesn't work for me.
Sven
On 06/28/2016 11:52 AM, Raymond Wan wrote:
> Hi Sven,
>
>
> On Tue, Jun 28, 2016
reproduces the problem.
Cheers,
Sven
On 06/10/2016 01:34 PM, Sven Baars wrote:
> 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
7;re not sure what they are
> you should be able to dig through the provided Config.cmake and
> Targets.cmake files for FooBar and see which targets are created bu
> "add_library(FooBar::Foo ... IMPORTED)".
>
> - Chuck
>
> On Wed, Jun 8, 2016 at 11:31 AM, Sven Ba
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
12 matches
Mail list logo
