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
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@gmx.eu ! Germany
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Regards, Rashad