Re: [boost] Status of the CMake-ification

Subject: Re: [boost] Status of the CMake-ification
From: Rashad M (mohammedrashadkm_at_[hidden])
Date: 2015-11-18 16:11:18

Hello all,

If BJam is doing the job very well, we don't want to have it replace or
make a co-existing cmake build.

I was thiniking of:
Have a CMakeLists.txt on the boost source dir.
This will build and configure first bjam and then build boost via
ExternalProject
and creates cmake's imported targets based on how bjam is configured.

so i have a cmake target "boost-signals" and when i do make boost-singals
it uses bjam.

The bjam configure file can generated based on cmake variables
-DWITH_BOOST*=ON/OFF and flags

This way boost can use the cmake features like IDE, Generators etc.. and
can limit maintaining cmake files for each and every boost library.

On Wed, Nov 18, 2015 at 8:39 PM, Jürgen Hunold <jhunold_at_gmx.eu> wrote:

> Hi Robert,
>
> Am Tuesday 17 November 2015, 14:41:07 schrieb Robert Ramey:
> > On 11/17/15 1:52 PM, Stephen Kelly wrote:
> > > Vladimir Prus wrote:
> > >> On 17-Nov-15 11:37 AM, Stephen Kelly wrote:
> > >>> Note that for users of boost, there would be a great benefit if
> > >>> boost.build would generate cmake packages with imported targets.
> > >>>
> > >>> I can help if someone who maintains boost.build wants to pursue that.
> > >>
> > >> FWIW, this proposal is something that can be actually implemented, and
> > >> probably will help users.
> >
> > I appreciate your efforts to improve boost, but I would like to
> > discourage you from pursuing this.  Boost Build is already too complex
> > for most of us to understand.
>
> Using Boost.Build is usually simple. And I don't think that a CMake
> solution
> for all of Boost would be simple. I've closely followed the first CMake
> attempt. I've been really impressed by lots of boilerplate macros needed
> back
> then. I guess CMake 3.x has lots of improvements, but it will still need
> some
> tweaking. At least the modularisation code can be omitted now.
>
> > This idea follows the strategy - build it
> > all in so that it works automagically.  But the problem is that the job
> > is too varied and to complex for this to work.  We then end up with
> > something that usually works - until it doesn't.
>
> Well, in the end we need an "automagic" solution for all of Boost.
> Although I
> agree that small steps are better.
>
> > Please consider a different approach.
> >
> > Make a Boost/CMake cheat sheet which would serve as a "template" for
> > library authors to use to make their own CMakeList.text files.  Then be
> > available to help out anyone who asks for it.
>
> That would be a nice addition.
> But I'd prefer some immediate improvements for Boost users working with
> CMake
> now.
>
> > I believe it would be
> > more effective in getting Boost to work better with CMake.  I already
> > spent some time on this for the inclubator.  But my effort isn't
> > complete - it addresses only the running of test on header only
> > libraries.  So there is lots of opportunity to make an impact here.
>
> As always.
>
> Yours,
>
> Jürgen
> --
> * Dipl.-Math. Jürgen Hunold  !
> * voice: ++49 4257 300       ! Fährstraße 1
> * fax  : ++49 4257 300       ! 31609 Balge/Sebbenhausen
> * jhunold_at_gmx.eu             ! Germany
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Regards,
   Rashad