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

[rleigh at codelibre.net]

> On 11/30/2015 11:26 AM, rleigh at 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