[MacPorts] #59834: Boost: refactor and enhance

[MacPorts]

#59834: Boost: refactor and enhance
--------------------------+----------------------
  Reporter:  michaelld    |      Owner:  mascguy
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:  boost        |
--------------------------+----------------------

Comment (by RJVB):

 Picking up on some criticism of the above idea, on PR 11185:

 On Tuesday June 01 2021 06:00:23 Ken wrote:
 >boost needs all it's headers installed. In many cases the headers are the
 only thing needed. If people take a moment, they can see if only headers
 are used in a given port, and if so, list boost as a build dep only.
 >
 >But installing boost without the headers would be very problematic.
 >
 >Creating a whole new system of boost lib-only installations is way too
 confusing.

 I think you and Chris are making an error one should never make: under
 (and over!) estimating users.

 Think of what port this is, and who is likely to install it, why, and how.
 1 the majority of people will probably inherit it as a dependency of a
 binary package. They probably couldn't care less what's in the port, aside
 (maybe) from how much disk space it takes
 2 the next biggest group probably consists of people who install it
 because of a build dependency. They too probably don't care what's in it,
 as long as their builds succeed. Here the boost PG comes in: any port that
 declares a dependency on boost can automatically add a depends_build on
 the -dev subport in addition to the (optional) depends_lib on the main
 port, through the PG. Here a -dev *subport* (instead of a variant)
 probably makes things easier.
 3 and then there will be people who use boost in their own software, i.e.
 developers. More likely than not they'll have at least some experience
 with Linux (and -dev packages), but above all I assume they are savy
 enough to realise that they have to install more than just the main port
 (if they simply haven't already, or after they discover that the main port
 installs just the shared libraries).

 >if we were ever going to get into that on MP, I guess it would have
 happened by now...too big of a project to ever undertake now, though,
 IMHO.

 I see 2 reasons to spring for -dev ports : 1) size of the developer
 content and 2) making build conflicts a lot easier. About that: the 1st
 ports in which I used my devport PG in my MacPorts adaptation for Linux
 were gettext and openssl. They often caused conflict, gettext notably
 because a number of the functions in its libintl are also provided in libc
 but not all symbols that get referenced when you use gettext headers (or
 something like that). I used conflicts_build for a while, but these ports
 are ubiquitous enough that deactivating them makes a whole lot of
 applications unusable. Not such problem with a -dev port - and forgetting
 to reactivate it will only break subsequent builds (and even then only if
 the port isn't listed as a build dependency).

 I have never felt the need to use this approach in every single one of my
 own ports, and I agree that the endeavour to apply it throughout the
 entire ports tree would be an impossible one. But that doesn't mean one
 cannot use it where it's justified - and in this instance it would be
 easy. Ports that decide to use the new boost ports and PG will have to
 make some changes anyway, but in this case that wouldn't even be required
 (see point 2) above).

 PS: I do use a -dev port with my personal port:acl, again because its
 headers can cause problems (mask system headers IIRC) but disabling the
 entire port would render lots of my KF5 applications inoperable. But I
 remember having run into a few other ports where I would have appreciated
 this level of control.

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