[MacPorts] #35490: libtorrent-rasterbar won't compile against new default boost variants

[MacPorts]

#35490: libtorrent-rasterbar won't compile against new default boost variants
---------------------------------+------------------------------------------
 Reporter:  timbargen@…          |       Owner:  devans@…            
     Type:  defect               |      Status:  new                 
 Priority:  Normal               |   Milestone:                      
Component:  ports                |     Version:  2.1.2               
 Keywords:  boost, libtorrent    |        Port:  libtorrent-rasterbar
---------------------------------+------------------------------------------

Comment(by adfernandes@…):

 `boost` maintainer here. On a mac there are no huge changes between
 multithreaded and non-mt builds; all re-arrangement happens due to the
 code. (In other words, the ABI is always implicitly multithreaded and
 there is no code-generation that changes. The code may conditionally
 compile into something else, but this isn't like MSVC or GCC on Linux!)

 I can add the `mt` and `static` builds back to `boost`, but excessive
 compile-times are an often-reported bug.

 It appears to me that `libtorrent-rasterbar` is actually at fault here
 because it is assuming that `boost` libraries have a particular name. In
 fact, they don't. The `-mt` suffix is optional during build. Also, the
 python variant is not installed by default (and never has been!) and, last
 I checked, there is no way to make a port depend on a specific variant.

 My suggestion would be for the `libtorrent-rasterbar` Portfile to test
 specifically for the boost-python-mt library that it needs via
 `depends_lib lib:boost_python-mt` or whatever, but modified such that an
 error is printed such that it tells the user to rebuild boost with the
 appropriate python and single-threaded variants.

-- 
Ticket URL: <https://trac.macports.org/ticket/35490#comment:3>
MacPorts <http://www.macports.org/>
Ports system for Mac OS