Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[rleigh]

> On 12/01/2015 05:11 PM, Roger Leigh wrote:
>> Attached.  I also attached the BoostScanDeps raw output and after
>> search-and-replace to make into valid cmake conditionals, and then after
>> simplifying where following release dependencies are unchanged, so you
>> can see where the logic in FindBoost comes from.
>
> Thanks.  That is a nice breakdown.
>
> Please revies the "FindBoost: Embed component dependency table" commit
> message to explain the steps used to run the script and ultimately get
> the content added by the commit.
>
>> + # Note: When adding a new Boost release, also update the dependency
>> + # information in _Boost_COMPONENT_DEPENDENCIES
>
> This is a good note.  Please extend it with a reference to instructions
> somewhere on how to actually perform the update.

I have updated both as requested, please find the updated patch attached.


Regards,
Roger
>From 3db45dbf0f41279dbf1b5288167cb96a84bef3fe Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Tue, 1 Dec 2015 21:53:50 +
Subject: [PATCH 2/5] FindBoost: Embed component dependency table

The function _Boost_COMPONENT_DEPENDENCIES is used to query the
library dependencies for a given component for a given version of
Boost.  This covers Boost releases from 1.33 to 1.59, using the
information generated by Utilities/Scripts/BoostScanDeps.cmake.
---
 Modules/FindBoost.cmake | 221 
 1 file changed, 221 insertions(+)

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 33e6a49..41b728d 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -472,6 +472,223 @@ function(_Boost_GUESS_COMPILER_PREFIX _ret)
 endfunction()
 
 #
+# Get component dependencies.  Requires the dependencies to have been
+# defined for the Boost release version.
+#
+# component - the component to check
+# _ret - list of library dependencies
+#
+function(_Boost_COMPONENT_DEPENDENCIES component _ret)
+  # Note: to add a new Boost release, run
+  #
+  #   % cmake -DBOOST_DIR=/path/to/boost/source -P Utilities/Scripts/BoostScanDeps.cmake
+  #
+  # The output may be added in a new block below.  If it's the same as
+  # the previous release, simply update the version range of the block
+  # for the previous release.
+  #
+  # This information was originally generated by running
+  # BoostScanDeps.cmake against every boost release to date supported
+  # by FindBoost:
+  #
+  #   % for version in /path/to/boost/sources/*
+  # do
+  #   cmake -DBOOST_DIR=$version -P Utilities/Scripts/BoostScanDeps.cmake
+  # done
+  #
+  # The output was then updated by search and replace with these regexes:
+  #
+  # - Strip message(STATUS) prefix dashes
+  #   s;^-- ;;
+  # - Indent
+  #   s;^set(;set(;;
+  # - Add conditionals
+  #   s;Scanning /path/to/boost/sources/boost_\(.*\)_\(.*\)_\(.*);  elseif(NOT Boost_VERSION VERSION_LESS \10\20\3 AND Boost_VERSION VERSION_LESS );
+  #
+  # This results in the logic seen below, but will require the 
+  # replacing with the following Boost release version (or the next
+  # minor version to be released, e.g. 1.59 was the latest at the time
+  # of writing, making 1.60 the next, so 106000 is the needed version
+  # number).  Identical consecutive releases were then merged together
+  # by updating the end range of the first block and removing the
+  # following redundant blocks.
+  #
+  # Running the script against all historical releases should be
+  # required only if the BoostScanDeps.cmake script logic is changed.
+  # The addition of a new release should only require it to be run
+  # against the new release.
+  set(_Boost_IMPORTED_TARGETS TRUE)
+  if(NOT Boost_VERSION VERSION_LESS 103300 AND Boost_VERSION VERSION_LESS 103500)
+set(_Boost_IOSTREAMS_DEPENDENCIES regex thread)
+set(_Boost_REGEX_DEPENDENCIES thread)
+set(_Boost_WAVE_DEPENDENCIES filesystem thread)
+set(_Boost_WSERIALIZATION_DEPENDENCIES serialization)
+  elseif(NOT Boost_VERSION VERSION_LESS 103500 AND Boost_VERSION VERSION_LESS 103600)
+set(_Boost_FILESYSTEM_DEPENDENCIES system)
+set(_Boost_IOSTREAMS_DEPENDENCIES regex)
+set(_Boost_MPI_DEPENDENCIES serialization)
+set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization)
+set(_Boost_WAVE_DEPENDENCIES filesystem system thread)
+set(_Boost_WSERIALIZATION_DEPENDENCIES serialization)
+  elseif(NOT Boost_VERSION VERSION_LESS 103600 AND Boost_VERSION VERSION_LESS 103800)
+set(_Boost_FILESYSTEM_DEPENDENCIES system)
+set(_Boost_IOSTREAMS_DEPENDENCIES regex)
+set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 math_tr1f math_tr1l)
+set(_Boost_MPI_DEPENDENCIES serialization)
+set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization)
+set(_Boost_WAVE_DEPENDENCIES filesystem system thread)
+set(_Boost_WSERIALIZATION_DEPENDENCIES serialization)
+  elseif(NOT Boost_VERSION VERSION_LESS 103800 AND Boost_VERSION VERSION_LESS 104300)
+   

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[Brad King]

On 12/01/2015 05:11 PM, Roger Leigh wrote:
> Attached.  I also attached the BoostScanDeps raw output and after 
> search-and-replace to make into valid cmake conditionals, and then after 
> simplifying where following release dependencies are unchanged, so you 
> can see where the logic in FindBoost comes from.

Thanks.  That is a nice breakdown.

Please revies the "FindBoost: Embed component dependency table" commit
message to explain the steps used to run the script and ultimately get
the content added by the commit.

> + # Note: When adding a new Boost release, also update the dependency
> + # information in _Boost_COMPONENT_DEPENDENCIES

This is a good note.  Please extend it with a reference to instructions
somewhere on how to actually perform the update.

Thanks,
-Brad

-- 

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

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[rleigh]

> On 11/30/2015 11:54 AM, rle...@codelibre.net wrote:
>> I do worry about the maintenance burden of hardcoding the information in
>> the script.
>
> I do too.  We already have to update the script for each Boost release.
> This is among the reasons the work is better integrated with upstream
> Boost instead.

I'd definitely like to see this for future Boost releases, though for
historical releases we're a bit stuck.  I'll revisit the work I pointed to
and see if I can figure out bjam/boost-build and integrate this, since it
would effectively give us CMake configuration "for free" off the back of
the autolink data, and would also come directly from the compiler so
wouldn't require parsing all the headers by hand.

>> How should this cater for dependency changes between boost releases?
>> How far back in time does this dependency information need to go?
>
> One would need to fill out tables per version and then detect the
> version to populate the info.  Just don't provide imported targets
> if the version does not have dependency info available.  If someone
> needs it they can run something to fill out the tables for their
> version and submit a patch.

I've attached an updated version of the patch which does this.  The
behaviour is otherwise identical to the earlier patches.  It's less awful
than I expected--the information for many Boost releases was the same so
it could be reduced in size significantly.  This also includes a utility
script to do the parsing, so it can be potentially used for future Boost
releases as well.  I've run the script against all versions of Boost
supported by the script, and it's verified with the unit test for some of
the components.

Just FYI, the boost components in 1.59 are as follows:

Header  Library Mismatched name
--- --- ---
archive serialization   *
archive wserialization  *
atomic  atomic
chrono  chrono
container   container
context context
coroutine2  coroutine   *
coroutine   coroutine
date_time   date_time
endian  endian
filesystem  filesystem
iostreams   iostreams
locale  locale
log date_time   (*)
log log
log log_setup
mathmath_c99*
mathmath_c99f   *
mathmath_c99l   *
mathmath_tr1*
mathmath_tr1f   *
mathmath_tr1l   *
mpi mpi
mpi mpi_python  *
program_options program_options
python  python
random  random
regex   regex
serialization   serialization
signals signals
system  system
testprg_exec_monitor*
testtest_exec_monitor   *
testunit_test_framework *
thread  thread
timer   timer
wavewave

The dependency parsing handles the case where the component library name
matches the include directory name.  For most cases, this is correct, but
there are cases marked * where it isn't.  These cases require the user to
request the appropriate component name by hand with find_package (since
the include directory name isn't a valid component name).  For most cases
we can't make the assumption since e.g. if you use  we have
no idea which serialisation library to use; and if you use  we
don't know which of the math_* libraries you /might/ use.  We have to
leave that up to the user.  Likewise for .  For these
libraries we also need to special-case the dependency info since we can't
easily get it via the headers; currently only mpi_python needed handling
in this way; the others have no dependencies.

The above isn't really a problem, it's just something to be aware of which
limits just how user-friendly we can make things.  The granularity of the
FindBoost component selection means the user will need to know which
libraries they need when they use certain headers; but this was already
the case for the variables, and is no different for the imported targets.


Regards,
Roger>From cbfb157c60ab7bdc22833db1534d1663f869ae4e Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Mon, 16 Nov 2015 13:21:33 +
Subject: [PATCH] FindBoost: Add imported targets

---
 Modules/FindBoost.cmake | 295 
 Tests/CMakeLists.txt|   4 +
 Tests/FindBoost/CMakeLists.txt  |  10 ++
 Tests/FindBoost/Test/CMakeLists.txt |  18 +++
 Tests/FindBoost/Test/main.cxx   |  26 
 Utilities/Boost/ScanDeps.cmake  | 156 +++
 6 files changed, 509 insertions(+)
 create mode 100644 Tests/FindBoost/CMakeLists.txt
 create mode 100644 Tests/FindBoost/Test/CMakeLists.txt
 create mode 100644 Tests/FindBoost/Test/main.cxx
 create mode 100644 Utilities/Boost/ScanDeps.cmake

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 33e6a49..a3e8474 

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[Brad King]

On 12/01/2015 10:58 AM, rle...@codelibre.net wrote:
> I'd definitely like to see this for future Boost releases, though for
> historical releases we're a bit stuck.  I'll revisit the work I pointed to
> and see if I can figure out bjam/boost-build and integrate this, since it
> would effectively give us CMake configuration "for free" off the back of
> the autolink data, and would also come directly from the compiler so
> wouldn't require parsing all the headers by hand.

Good.  Once Boost provides that then our FindBoost script can switch
to looking for it when the version number is high enough.

> I've attached an updated version of the patch which does this.  The
> behaviour is otherwise identical to the earlier patches.  It's less awful
> than I expected--the information for many Boost releases was the same so
> it could be reduced in size significantly.  This also includes a utility
> script to do the parsing, so it can be potentially used for future Boost
> releases as well.  I've run the script against all versions of Boost
> supported by the script, and it's verified with the unit test for some of
> the components.
[snip]
> The dependency parsing handles the case where the component library name
> matches the include directory name.  For most cases, this is correct, but
> there are cases marked * where it isn't.  These cases require the user to
> request the appropriate component name by hand with find_package (since
> the include directory name isn't a valid component name).  For most cases
> we can't make the assumption since e.g. if you use  we have
> no idea which serialisation library to use; and if you use  we
> don't know which of the math_* libraries you /might/ use.  We have to
> leave that up to the user.  Likewise for .  For these
> libraries we also need to special-case the dependency info since we can't
> easily get it via the headers; currently only mpi_python needed handling
> in this way; the others have no dependencies.

Great.  Please split this up into a few commits, perhaps:

- Add parsing script, perhaps `Utilities/Scripts/BoostScanDeps.cmake`.
  I see it documents in the comments the need for special cases already.
  Please also add a comment next to each special case to explain it.

- Run script to populate the table in FindBoost.cmake.  Document in
  the commit message the range of versions included.

- Add imported targets using the now-available tables.

Thanks,
-Brad

-- 

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

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[Brad King]

On 11/30/2015 11:26 AM, rle...@codelibre.net wrote:
> I have improved the parsing speed somewhat and added some progress
> diagnostics to inform the user what's happening to compensate for the time
> it takes to process the dependencies.  It's still slower than I'd ideally
> like, but it's a bit better.  If there's any way to make it even faster
> I'd be interested.  I think what's there is technically correct though.

I'm sorry I didn't have a chance to look at this sooner.

Parsing dependencies out of the header files is far too heavy-weight
for a find module.  We should memorize the known dependencies as
is done for other find modules that provide imported targets.  If
that is not tractable then the FindBoost module is the wrong place
to solve this problem.

FWIW, I think effort would be better spent working with Boost
folks to get cmake package files provided.  They don't have to
build with CMake to do this.  Qt5 for example builds without
CMake but still provides CMake package files.

-Brad

-- 

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

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[rleigh]

> On 11/30/2015 11:26 AM, rle...@codelibre.net wrote:
>> I have improved the parsing speed somewhat and added some progress
>> diagnostics to inform the user what's happening to compensate for the
>> time
>> it takes to process the dependencies.  It's still slower than I'd
>> ideally
>> like, but it's a bit better.  If there's any way to make it even faster
>> I'd be interested.  I think what's there is technically correct though.
>
> I'm sorry I didn't have a chance to look at this sooner.
>
> Parsing dependencies out of the header files is far too heavy-weight
> for a find module.  We should memorize the known dependencies as
> is done for other find modules that provide imported targets.  If
> that is not tractable then the FindBoost module is the wrong place
> to solve this problem.

I do worry about the maintenance burden of hardcoding the information in
the script.  But if that's what's required I can look at doing this.

How should this cater for dependency changes between boost releases?
How far back in time does this dependency information need to go?

I can certainly write a script to manually trawl the headers for this
information, as done in this patch, and then embed that in FindBoost.cmake
(or put it in an ancillary script--might be easier to cater for multiple
versions this way?).

> FWIW, I think effort would be better spent working with Boost
> folks to get cmake package files provided.  They don't have to
> build with CMake to do this.  Qt5 for example builds without
> CMake but still provides CMake package files.

I already did some work towards this goal five years ago:

  https://svn.boost.org/trac/boost/ticket/1094

See the attached patches.  This was a proof of concept to introspect the
headers for generation of pkg-config files during the boost build (it uses
the compiler to dump the dependencies directly), but it could be trivially
updated for cmake configuration generation.  If I had any clue regarding
bjam internals, it would have been completed years ago, but I don't have
the expertise to integrate it to complete the task.

If there's anyone at all here who understands bjam, your help here would
be greatly appreciated by many people!


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

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[Brad King]

On 11/30/2015 11:54 AM, rle...@codelibre.net wrote:
> I do worry about the maintenance burden of hardcoding the information in
> the script.

I do too.  We already have to update the script for each Boost release.
This is among the reasons the work is better integrated with upstream
Boost instead.

> How should this cater for dependency changes between boost releases?
> How far back in time does this dependency information need to go?

One would need to fill out tables per version and then detect the
version to populate the info.  Just don't provide imported targets
if the version does not have dependency info available.  If someone
needs it they can run something to fill out the tables for their
version and submit a patch.

> I already did some work towards this goal five years ago:
> 
>   https://svn.boost.org/trac/boost/ticket/1094
> 
> See the attached patches.  This was a proof of concept to introspect the
> headers for generation of pkg-config files during the boost build (it uses
> the compiler to dump the dependencies directly), but it could be trivially
> updated for cmake configuration generation.  If I had any clue regarding
> bjam internals, it would have been completed years ago, but I don't have
> the expertise to integrate it to complete the task.
> 
> If there's anyone at all here who understands bjam, your help here would
> be greatly appreciated by many people!

I'm not familiar with bjam or Boost Build v2 enough to help.  However,
once this work is done the problem will be solved and mostly free of
maintenance moving forward.  In the long run, figuring it out there
will be less work than maintaining a huge amount of information in
FindBoost.

-Brad

-- 

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

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[Roger Leigh]

On 18/11/2015 11:27, rle...@codelibre.net 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.


I have made a first attempt at this.  I suspect it will need some
refinement, but hopefully useful as a starting point.  Please see the
attached patch.  I'd certainly be very appreciative of any comments.


[...]

Did anyone have a chance to look at this yet?  I'd very much like to get 
this to a state where it can be included.  The performance is something 
I'd like to improve, and I hope someone might have a suggestion for 
speeding up the parsing overhead.



Kind 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

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[rleigh]

> Thanks for working on this.  Please read through this mailing list
> thread:
>
>  IMPORTED targets for some Find modules
>  https://cmake.org/pipermail/cmake-developers/2014-June/010694.html

Done.

> 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.

I have made a first attempt at this.  I suspect it will need some
refinement, but hopefully useful as a starting point.  Please see the
attached patch.  I'd certainly be very appreciative of any comments.

I considered whether we would need to hardcode all the dependencies, since
some are known.  But since they can change from release to release, and we
don't know the complete set, I opted to do this automatically to ensure
it's correct (for some definition of correct) for any arbitrary Boost
release.

- This will iteratively discover all the potential dependencies for each
component via the header defines which would trigger autolinking on
Windows.  This is very aggressive and not all the discovered libraries may
be required under all circumstances, if e.g. a particular set of #defines
and headers must be used to pull in another component dependency, we will
pull it in anyway.  However, it is almost always going to link
successfully as a result.
- Any missing dependencies are automatically added to the component list
and as imported targets.

This makes linking correctly much simpler and much more transparent, as
demonstrated by the added testcase.

Problems and missing features:

- Scanning all the headers line-by-line is slow, and this is noticeable;
if I have read a file into a variable and converted it to a list, if there
was a way of filtering the list in a single pass, that would be a big
improvement.  We basically just want the #includes and library names, but
don't want to run two regexes on every line.
- I've had to special-case boost_bzip2 and boost_zlib since they don't
work under all (most?) circumstances.
- I've made boost_thread link with Thread::Thread automatically.  I'm not
a heavy user of all Boost library components, so other dependencies will
also require adding.
- Header-only components with implicit dependencies on components with
libraries are not currently handled; these could be added as imported
targets as a future improvement.
- You can now disable autolinking and enable shared libraries with
imported targets.  (Personally, I've never had autolinking work ever--it
can never find the libs!  Once the dependency discovery is fully
functional, we could potentially always disable it when using the imported
targets to give consistent linking behaviour on all platforms.)

In the mailing list thread you pointed to, there was some question over
FindBoost being compatible with the future modularised Boost libraries and
with Boost using CMake in the future.  These are reasonable concerns, but
personally I'd rather have something that works now with current and
previous Boost releases, since progress upstream is somewhat unpredictable
and leaves us in limbo waiting on them otherwise.  So long as the
modularised Boost cmake config files are compatible with the variables and
targets defined here, and to be backward compatible they would have to be,
won't they be automatically used instead of FindBoost when installed? 
Unless I'm missing something, upstream could make the modularisation
completely transparent if they care to be backward compatible with what is
already in wide use.


Regards,
Roger>From 0a15cd57d0d2924f77372b65985f5b5c0ee477c1 Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Mon, 16 Nov 2015 13:21:33 +
Subject: [PATCH] FindBoost: Add imported targets

---
 Modules/FindBoost.cmake | 216 
 Tests/CMakeLists.txt|   6 +-
 Tests/FindBoost/CMakeLists.txt  |  10 ++
 Tests/FindBoost/Test/CMakeLists.txt |  18 +++
 Tests/FindBoost/Test/main.cxx   |  26 +
 5 files changed, 275 insertions(+), 1 deletion(-)
 create mode 100644 Tests/FindBoost/CMakeLists.txt
 create mode 100644 Tests/FindBoost/Test/CMakeLists.txt
 create mode 100644 Tests/FindBoost/Test/main.cxx

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 33e6a49..d688734 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -54,6 +54,33 @@
 #   Boost__LIBRARY_DEBUG   - Component  

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[Ruslan Baratov via cmake-developers]

On 17-Nov-15 15:48, Roger Leigh wrote:

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:: (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?
I'm not sure about all aspects it's not my main point anyway :) I'm 
saying that this kind of information can be installed by CMake project 
and I can predict that it will be hard to achieve the same in 
FindBoost.cmake when build already done and this info is lost.




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?
This is a best option but not necessary. As I said earlier if you're 
using wrapper to install boost (like ExternalProject_Add) you can add 
some extra files which will hold this info.


Ruslan
--

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

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[Roger Leigh]

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:: (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

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[Florent Castelli]

It’s nice and I was thinking of doing the same!

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.

/Florent

> On 16 Nov 2015, at 15:01, rle...@codelibre.net wrote:
> 
> I have attached a patch to add imported targets to FindBoost, in the form
> of Boost:: (e.g. Boost::date_time) or Boost::Boost as a generic
> interface library for header-only components.
> 
> If this type of patch is acceptable, I would like to do this for a number
> of other modules for which I would like to be able to use so I export
> generic configurations for my own libraries, including XercesC, PNG, TIFF
> and a few others.  If that's OK, I'll follow up with patches for these
> modules.
> 
> 
> Regards,
> Roger Leigh<0001-FindBoost-Add-imported-targets.patch>-- 
> 
> 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

-- 

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

[cmake-developers] [PATCH] FindBoost: Add imported targets

[rleigh]

I have attached a patch to add imported targets to FindBoost, in the form
of Boost:: (e.g. Boost::date_time) or Boost::Boost as a generic
interface library for header-only components.

If this type of patch is acceptable, I would like to do this for a number
of other modules for which I would like to be able to use so I export
generic configurations for my own libraries, including XercesC, PNG, TIFF
and a few others.  If that's OK, I'll follow up with patches for these
modules.


Regards,
Roger Leigh>From 2fd86f82b12569c990dd2befbfb82d3d8103d374 Mon Sep 17 00:00:00 2001
From: Roger Leigh 
Date: Mon, 16 Nov 2015 13:21:33 +
Subject: [PATCH] FindBoost: Add imported targets

---
 Modules/FindBoost.cmake | 58 +
 1 file changed, 58 insertions(+)

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index 33e6a49..b5f5e22 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -34,6 +34,11 @@
 #information about Boost's automatic linking
 #displayed during compilation
 #
+# The following :prop_tgt:`IMPORTED` targets are also defined::
+#
+#   Boost::Boost   - Target for header-only dependencies
+#   Boost:: - Library target for specific component dependency
+#
 # This module reads hints about search locations from variables::
 #
 #   BOOST_ROOT - Preferred installation prefix
@@ -142,6 +147,14 @@
 # add_executable(foo foo.cc)
 #   endif()
 #
+# Example to find Boost libraries and use imported targets::
+#
+#   find_package(Boost 1.56 REQUIRED COMPONENTS
+#date_time filesystem system iostreams)
+#   add_executable(foo foo.cc)
+#   target_link_libraries(foo Boost::date_time Boost::filesystem
+# Boost::system Boost::iostreams)
+#
 # Example to find Boost headers and some *static* libraries::
 #
 #   set(Boost_USE_STATIC_LIBSON) # only find static libs
@@ -1222,6 +1235,51 @@ else()
 endif()
 
 # 
+#  Add imported targets
+# 
+
+if(Boost_FOUND)
+  # For header-only libraries
+  if(NOT TARGET Boost::Boost)
+add_library(Boost::Boost INTERFACE IMPORTED)
+if(Boost_INCLUDE_DIRS)
+  set_target_properties(Boost::Boost PROPERTIES
+INTERFACE_INCLUDE_DIRECTORIES "${Boost_INCLUDE_DIRS}")
+endif()
+  endif()
+
+  foreach(COMPONENT ${Boost_FIND_COMPONENTS})
+string(TOUPPER ${COMPONENT} UPPERCOMPONENT)
+if(Boost_${UPPERCOMPONENT}_FOUND)
+  add_library(Boost::${COMPONENT} UNKNOWN IMPORTED)
+  if(Boost_INCLUDE_DIRS)
+set_target_properties(Boost PROPERTIES
+  INTERFACE_INCLUDE_DIRECTORIES "${Boost_INCLUDE_DIRS}")
+  endif()
+  if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY}")
+set_target_properties(Boost::${COMPONENT} PROPERTIES
+  IMPORTED_LINK_INTERFACE_LANGUAGES "CXX"
+  IMPORTED_LOCATION "${Boost_${UPPERCOMPONENT}_LIBRARY}")
+  endif()
+  if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}")
+set_property(TARGET Boost::${COMPONENT} APPEND PROPERTY
+  IMPORTED_CONFIGURATIONS DEBUG)
+set_target_properties(Boost::${COMPONENT} PROPERTIES
+  IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX"
+  IMPORTED_LOCATION_DEBUG "${Boost_${UPPERCOMPONENT}_LIBRARY_DEBUG}")
+  endif()
+  if(EXISTS "${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}")
+set_property(TARGET Boost::${COMPONENT} APPEND PROPERTY
+  IMPORTED_CONFIGURATIONS RELEASE)
+set_target_properties(Boost::${COMPONENT} PROPERTIES
+  IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "CXX"
+  IMPORTED_LOCATION_RELEASE "${Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE}")
+  endif()
+endif()
+  endforeach()
+endif()
+
+# 
 #  Notification to end user about what was found
 # 
 
-- 
2.1.4
-- 

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

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[Brad King]

Hi Roger,

Thanks for working on this.  Please read through this mailing list
thread:

 IMPORTED targets for some Find modules
 https://cmake.org/pipermail/cmake-developers/2014-June/010694.html

There is some discussion there about similar FindBoost changes.

Also please take a look at these tests:

 $ ls -d Tests/Find*

such as FindGSL, FindOpenSSL, and FindThreads to see our current
convention for adding tests for modules.  See the conditions in
Tests/CMakeLists.txt for adding most of them.  Please add similar
tests for FindBoost, at least for the new imported targets.

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.

Thanks,
-Brad
-- 

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

Re: [cmake-developers] [PATCH] FindBoost: Add imported targets

[Ruslan Baratov via cmake-developers]

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:: (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).


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.


Ruslan
--

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