> If in someApp I find foo find_package(foo CONFIG REQUIRED)
> I get an error: "The following imported targets are referenced, but are
> missing: bar::bar"
>
> The current workaround is to manually add in someApp
> find_package(bar CONFIG REQUIRED) before
> find_package(foo CONFIG REQUIRED)
>
>
> But in my understanding this find_package(bar) should somehow be
> resolved from the package foo - am I wrong?
> The client should not have to resolve the entire dependency tree
> manually bay adding find_package() in the correct order.
> How can this be done?
As far as I know find_package(foo) will not search for its
dependencies (e.g. bar) except if you put another find_package inside
Findfoo.cmake script that finds it for you.
On the other hand I doubt that this is a CMake issue/shortcoming.
I imagine that your dependency tree looks something like this:
your_program <- foo <- bar
<- bar
so both your program and foo library depend on bar library and there
are three cases that I see:
1) your application has direct dependency on bar library (is using bar api)
2a) your application depends on foo that exposes bar api because it
uses bar api as public foo api
2b) you application depends on foo that exposes bar api but foo
doesn't use it as public foo api
In all cases you will have to search for bar library yourself and link
it to your application but:
In case 1 it is logical that you have to search for bar lib yourself
since it is just a coincidence that foo is using bar internally.
In case 2a dependency to bar is by design and it's questionable why
bar is used in public foo api (maybe performance reasons?) so it might
be a flaw in library design (or is your own library in which case it
would probably be better to create an object library and do all the
linking and searching for libraries in you applications cmake list -
in this case you could also set a variable with PARENT_SCOPE that gets
propagated to root cmake list to automate you dependency detection).
In case 2b dependency to bar is accidental and is just poor/old
library design - library is not linked with everything being a private
symbol and only public api being marked as public either by using an
attribute (https://gcc.gnu.org/wiki/Visibility - supported in one
way or the other in gcc, Visual C++, xlC from version 13.1 and
probably clang and others) or some other form like export lists or
static keywords
(http://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility/).
If this is an external library and you are using it for production
application I would suggest that if possible you write a wrapper
library that only exposes its public api and link your application
only to your wrapper - or if library is open sourced ask if they are
interested in such patches and contribute them there.
In any case if this is not supporter directly by CMake (could be that
it is and I only don't know about it) I doubt that it should be since
libraries leaking their internal implementation probably have API and
ABI compatibility issues between versions and can cause interesting
compile and runtime errors when linked twice as in your case but with
different shared library versions (e.g. you get an already compiled
library and just want to link to it but don't know with which version
of internally dependent library it was built).
Issues with this can be easily seen in cases such as:
your_program <- foo <- bar (v 1.0)
<- bas <- bar (v 2.1)
<- bar (v 1.3)
If your application, foo, bar and bas are not built as the same super
project or expect different (not API compatible) versions of bar and
they all leak their internal use to the world (and let's also say that
bar 1 and 2 were not tested for combined use in the same application)
then have fun building such an application without causing interesting
runtime errors (e.g. constructor from being called version 1.0 and
destructor from version 2.1).
Hope this helps.
Regards,
Domen
--
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
