[MacPorts] #31169: boost needs a new build system

[MacPorts]

#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