On 17/11/2015 07:53, Ruslan Baratov wrote:
On 16-Nov-15 21:01, rle...@codelibre.net wrote:
I have attached a patch to add imported targets to FindBoost, in the form
of Boost::<component> (e.g. Boost::date_time) or Boost::Boost as a
generic
interface library for header-only components.
Since it's `Boost::date_time` I expect that it will be `Boost::boost`
(lowercase).
Yes, I've merged most of the previous work Brad pointed to yesterday,
and this included this change.
On 16-Nov-15 21:39, Brad King wrote:
On 11/16/2015 09:26 AM, Florent Castelli wrote:
But one there’s one thing that comes to mind. Some compiled libraries
have dependencies on other compiled libraries.
Don’t you think it would make sense to teach FindBoost about those
so we link everything properly?
And also maybe add the native dependencies for some modules that
have one like maybe pthread or openssl.
Though, this might be hard to get right in a cross platform way.
Please look at adding these. The imported targets should come
with all usage requirements as if they were provided by upstream
Boost. It may be tricky to get right on all platforms but if we
do not do it then application code will have to do it instead.
One tricky part about it is that dependency can be optional. I.e.
Boost::iostreams may or may not depends on ZLIB/BZip2. Such information
is known only by build procedure. I.e. should be installed by b2 itself
or by wrapped ExternalProject_Add instructions.
For the specific case of the zlib/bzip2 dependencies, this is only the
case when using the static libraries? It's not exposed via the headers
is it?
Looking at the information embedded in the sources for use with
autolinking, we could certainly process the headers for the requested
components and pull out the referenced libraries. This would get us all
of the header dependencies without hardcoding anything ourselves, which
would make it work with arbitrary versions of boost without having to
hardcode the differences between Boost versions.
Fully supporting static linking would be much more difficult. As you
say, it depends upon how Boost was built. Full support here would need
to wait for the upstream to generate this data at build time?
I'll have a look at doing the above and should have an updated patch soon.
Regards,
Roger
--
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-developers
