#31169: boost needs a new build system --------------------------------------+------------------------------------- Reporter: adfernandes@… | Owner: adfernandes@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: boost --------------------------------------+------------------------------------- Description changed by adfernandes@…: Old description:

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

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

Comments, anyone?

Overrides #30377, #31060, #31134.

New description: 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. -- -- Ticket URL: <https://trac.macports.org/ticket/31169#comment:1> MacPorts <http://www.macports.org/> Ports system for Mac OS

#31169: boost needs a new build system --------------------------------------+------------------------------------- Reporter: adfernandes@… | Owner: adfernandes@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: boost --------------------------------------+------------------------------------- Comment(by adfernandes@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/31169#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS

#31169: boost needs a new build system --------------------------------------+------------------------------------- Reporter: adfernandes@… | Owner: adfernandes@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: boost --------------------------------------+------------------------------------- Comment(by adfernandes@…):

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. -- Ticket URL: <https://trac.macports.org/ticket/31169#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS

#31169: boost needs a new build system ---------------------------------------+------------------------------------ Reporter: adfernandes@… | Owner: adfernandes@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Resolution: wontfix | Keywords: Port: boost | ---------------------------------------+------------------------------------ Changes (by adfernandes@…): * status: new => closed * resolution: => wontfix Comment: 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. -- Ticket URL: <https://trac.macports.org/ticket/31169#comment:9> MacPorts <http://www.macports.org/> Ports system for Mac OS