[MacPorts] #34806: mkvtoolnix needs boost and icu built with same compiler

[MacPorts]

#34806: mkvtoolnix needs boost and icu built with same compiler
-------------------------+--------------------------------
  Reporter:  brian@…     |      Owner:  macports-tickets@…
      Type:  defect      |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.1.1
Resolution:              |   Keywords:
      Port:  mkvtoolnix  |
-------------------------+--------------------------------

Comment (by Kona8lend@…):

 Replying to [comment:31 raimue@…]:
 > Replying to [comment:24 Kona8lend@…]:
 > > All 3 ports are aware of and use /opt/local/private/mkvtoolnix/ as a
 private subtree for mkvtoolnix special needs. There are several good
 reasons for this. Firstly, we guarantee that all C++ and C++11 libraries
 for which mkvtoolnix depends on, either directly or indirectly, are built
 with the same compiler, and same c++11 mode flags. Second, this must co-
 exist with all other ports and not impact them negatively. Thirdly,
 mkvtoolnix tracks boost version bumps much faster than other apps, so
 tying them to the same version is not possible without halting mkvtoolnix
 version bumps.
 >
 > I don't understand how you ensure these promised guarantees. The ports
 still have variants to select different compilers as explained below.
 Doesn't this still allow to use different compilers for each of the ports?

 The compilers that are known to work and tested are explicitly supported
 variants. What's the issue you have? Is it legalese? Sorry, but IANAL.

 > If mkvtoolnix is advancing too fast to allow a stable build with our
 toolchains we should just stick with an older, working release.

 That is of course one choice. The reason for which these custom ports were
 created is because I made the other choice: to not wait an indeterminate
 number of years for tools and dependencies of "macports proper" to satisfy
 modern releases of mkvtoolnix.

 > As far as I know no other port uses the `${prefix}/private` namespace,
 which is outside the port hierarchy defined by porthier(7). I don't think
 "private" is exactly what we want here, the libraries should rather live
 in `${prefix}/lib/mkvtoolnix/lib*.dylib`.

 There is also {bin,include,sbin,share} directories for which need to be
 unique, and for each port one or more of said directories. One choice is
 to go your route and mix-in such directories for each custom port into the
 main tree, which I think is too messy. Maybe another name besides
 "private" but if you actually try to convert these ports to your layout,
 it will become very intertwined. Remember, these ports must co-exist with
 existing macports proper.

 > > The positive side is, port:mkvtoolnix.boost has been optimized to
 build on the necessary libraries and takes an order of magnitude less time
 to build than the port:boost .
 >
 > Except you need yet another port installed. boost is binary
 distributable and available as binary archives.

 Boost and ICU as built and distributed via binary archives of "macports
 proper" do not satisfy mkvtoolnix. The dependencies that are custom are
 that way for a reason: to satisfy mkvtoolnix. The c++ mode for which
 "macports proper" boost and icu are built are not likely to satisfy
 mkvtoolnix for quite sometime. This last part is an educated guess based
 on what I've seen with macports, its progress rate, and its complexity. No
 insults or negatives intended. Just the cold reality of incompatibilities.

 Cheers.

-- 
Ticket URL: <https://trac.macports.org/ticket/34806#comment:32>
MacPorts <http://www.macports.org/>
Ports system for OS X