boost needs a new build system

[adfernandes (Andrew Fernandes)]

As a maintainer, the boost build system is driving me crazy. The boost team has decided to write their own installer, and it is buggy, poorly documented, and only vaguely supported on OS X (in my opinion).

Since we do not need all the compiler support and test-case support (and documentation) that the main boost distribution supplies, I am volunteering to write a CMake-based build for mac-specific building and installation. That should eliminate a lot of the problems seen lately under boost and it's reliance on gnumake and it's own internal bjam build system.

My plan is to support shared and dynamic builds, release-only (no debugging) and multithreaded only (since that's the only valid arch on OS X anyway).

The only tricky bit is the python and mpi variants.

I hope to have it working within a couple of weeks.

Comments, anyone?

Overrides #30377, #31060, #31134.

[tvb377@…]

Cc Me!

[tvb377@…]

You know that there has been some effort for cmake based build of boost? ​https://svn.boost.org/trac/boost/wiki/CMake

What do you mean with "their own installer"? Could you give a link explaining what that is?

And in what sense is it only "vaguely" supported on OSX?

[adfernandes (Andrew Fernandes)]

Those are good questions! Sorry for not being clear. If you haven't spent a lot of time trying to build boost, this might look insane. :-)

The cmake-based boost-build is now a dead project. They are doing something called ryppl (you can google it).

The boost-team's installer/builder is 'bjam'. I'm not sure of the version... well, nobody really knows the version. There is jam1 and jam2, then there's bjam and boost-jam... but boost will only build with it's own internal bjam. That's the problem for some people; the internal bjam searches for headers in a different way than expected...

The current state of the project - for boost 1.47.0 - can be summarized as very, very hard to understand. If you want linux and windows stuff, and all the unit testing... then fine. However, major functionality is missing, too: you cannot select python variants, nor can you optionally build mpi or python+mpi.

In the sense of "vaguely" supported, the current boost build system doesn't know anything about install_path, os x multithreading, or things like "frameworks".

It has gotten to the point where maintaining the Portfile is too much work. Most of the portfile is adding

For the MacPorts build, I have a 68 line CMakeLists.txt file that builds almost all of boost, static and dynamic, uses the correct install_name, and installs into the destroot. It is clear, logical, and simple. Moreover, it is standard; anyone with knowledge of cmake can easily modify and debug it.

The only complex bits will be the python and mpi code, and those will be in side-modules anyway.

[tvb377@…]

OK, now I see what you meant with "installer". I thought that boost was giving up b(jam)?(2)? for something even more arcane.

I just tried hard to understand about the multithreading variant but was unable to locate much more than setting CFLAGS depending on the threading=single/multi (but not for OSX, ref ticket #31134).

So I do understand the idea of throwing away the bjam stuff.

I'd only wish that this would be a boost, not macports-trac ticket and the cmake stuff gets back to boost trunk, but that's something that wouldn't happen before.

That's why I myself would be reluctant to develop another build system just for macports.

Do you see any chances for integrating your work upstream?

If you need any help with testing, let me know.

[adfernandes (Andrew Fernandes)]

Do you see any chances for integrating your work upstream?

None whatsoever. The boost devels are brilliant coders, but... well, I've had poor interactions with them in the past. I file bugs, and they get ignored. I (politely) ask for an update, or provide a patch. I get ignored. I ask "is anyone reading this? here's a bug and a tested patch" and I get a short very, very snarky one-liner about how "stupid" OS X must be for my bug to be true.

This cycle has happened more than once; I can only hope that it isn't because of my personality! :-) I know that others have had much more positive experiences with them... maybe I've just had bad luck.

If you need any help with testing, let me know.

Thanks.

A mac-specific cmake file is really not a bad thing. There's very little mac-specific code in it; cmake 2.8 handles -install_name with it's built-in rpath handling, so... no big deal.

[maehne (Torsten Maehne)]

Cc Me!

[titus@…]

I gave ​https://github.com/pocb/boost a try today.

Almost works. I checked out the 1.48.0 branch and used

CC=clang CXX=clang++ ccmake <cmake-boost-dir>

After make ; sudo make install I was able to build and link a small project that uses iostreams+zlib date_time regex file_system and system.

Two patches were necessary for me to link chrono and locale. I attach them here.

But it seems to me that also this project does not really try hard to integrate volunteers...

I don't understand where to send these patches (and if they would be welcome).

[titus@…]

patch for linking chrono of cmake-boost

[titus@…]

patch for compiling and linking locale of cmake-boost

[adfernandes (Andrew Fernandes)]

Okay - I've played and played and played with this. The majority of it works, but, as you can see from the attached CMakeLists.txt file, I've had to back out almost all my changes.

Boost is just too hardwired to bjam for the python, mpi, and other variants. The "main body" of boost builds easily... but the corner cases kill you, and there are a lot of corner-cases.

I'm closing this ticket - it's just too much time for too little reward.