[MacPorts] #69119: boost: enable static libraries by default

[MacPorts]

#69119: boost: enable static libraries by default
-------------------------------------------------+-------------------------
  Reporter:  mohd-akram                          |      Owner:  (none)
      Type:  enhancement                         |     Status:  new
  Priority:  Normal                              |  Milestone:
 Component:  ports                               |    Version:
Resolution:                                      |   Keywords:
      Port:  boost169, boost171, boost176,       |
  boost178, boost181                             |
-------------------------------------------------+-------------------------

Comment (by ryandesign):

 Of course there is a reason. 😊 But the reasons don't all necessarily
 still apply, and the way that the problems would be solved today would be
 different.

 Boost used to default to building all flavors of the libraries (dynamic
 multithreaded, dynamic single-threaded, static multithreaded, and static
 single-threaded). This took a very long time and people complained;
 [ticket:26466 that was in 2010]. The no_single and no_static variants were
 created so users could disable the flavors they didn't need if they wanted
 to save build time.

 It would have been more logical to have named those variants single and
 static and to have them do the opposite, as you suggested, but there was a
 longstanding bug in MacPorts base which did not preserve disabled variants
 across upgrades, so it was customary to name variants that disabled
 features with a "no_" prefix and to have users enable those variants
 instead. I think this bug was #2377 which was fixed in MacPorts 1.9.0
 which was released a few months before the variants were added to boost,
 so the variant names in boost were probably just following the existing
 convention by that point despite the underlying reason for that convention
 having already been removed. It took some time before most of the
 "no_"-prefixed variants were removed from ports. For example, the effort
 to change no_x11 variants to x11 lasted [ticket:39383 from 2013 to 2015].

 The addition of these variants in boost predated the existence of MacPorts
 2.0.0 ([https://lists.macports.org/pipermail/macports-
 users/2011-July/024788.html released in 2011]) with the capability of
 fetching pre-built archives and of our buildbot infrastructure
 ([https://lists.macports.org/pipermail/macports-
 announce/2012-May/000021.html installed in 2011]) for producing pre-built
 archives. For distributable ports, pre-built archives lessen the
 significance of long build times, but they don't eliminate it completely
 because users who cannot use pre-built archives are still affected.

 [changeset:2651d1ea9a273b1fb289244d7bbd06fce6b9ea1d/macports-ports In
 2012], the no_single and no_static variants were enabled by default so
 that only the most-commonly-used types of libraries were built by default.
 This made the build take only ¼ of the time.

 Using variants to control which libraries get installed is bad because
 MacPorts base does not offer the capability for other ports that require
 those libraries to depend on a variant of a port; see #126. The
 active_variants 1.1 portgroup implements a workaround for that but it is
 easily subverted by users. The correct solution would be for the different
 flavors of boost libraries to be made available as subports instead of
 variants. That way, each port can declare a dependency on the subport for
 whichever flavor of boost libraries it requires. The addition of the
 variants to the boost port predates the existence of the subport feature
 which was introduced in MacPorts 2.0.0. See #67116 for the similar request
 that the python variants should be subports for a similar reason.

 See also #38406 for a request similar to yours that single-threaded
 libraries should be enabled by default.

 All of this also predates the split of the boost port into multiple ports
 for different versions of boost. This doesn't really affect the solution
 except to the extent that it multiples the amount of work involved by the
 number of boost ports.

 Making any change (either renaming and changing the meaning of the
 variants or changing the variants into subports) requires attention not
 only to the boost ports but also to all the ports that depend on them. For
 example, alembic and librets check which flavor of boost libraries is
 installed, and blender, deal.ii, freecad, htcondor, ledger, ompl, openvdb,
 osl, pybind11, usd, and vigra check which python variant of boost is
 installed. Changes would have to be coordinated so that all of these ports
 experience a smooth upgrade path.

 Finally, why do you want static libraries? Their use is not recommended or
 customary on macOS.

-- 
Ticket URL: <https://trac.macports.org/ticket/69119#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS