[MacPorts] #70077: The stub PG should (be able to) clear all pre- and post- blocks

[MacPorts]

#70077: The stub PG should (be able to) clear all pre- and post- blocks
--------------------------+--------------------
  Reporter:  RJVB         |      Owner:  (none)
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+--------------------

Comment (by RJVB):

 Maybe not hard but it doesn't help readability, esp. if there are multiple
 blocks to be protected this way. My own approach is often to put the stub
 subport as close to the top as possible, with a `return` to shunt parsing
 of the rest of the Portfile, but that has other potential side-effects.

 Implementation-wise it seems easiest to skip the invocation of the
 corresponding code if e.g. `stub::setup_stub` is defined (implies
 considering the stub PG as part of "base" I suppose). I'm adopting that
 for now in my Linux adaptation (where I can't get around the fact that
 certain packages/ports are best taken from the host and I want to see how
 far I can get with central `+fromHost` variant that turns the port into a
 shim, rather than making custom ports that don't declare the dependencies
 in question).

 But if one takes the position that "base" implements a dedicated language
 (I tend to think of it that way) then it feels like a lacking feature that
 `build {}`, `destroot {}` etc. allow to skip those stages but there is no
 way to skip the associated pre- or post- stages. At the very least there
 could be `use_pre_???` options like there is a `use_configure` option
 (does that one disable the `pre-configure` and `post-configure` blocks in
 fact?), or a single option to "skip pre- and post- for empty build stages.
 Sticking with the 2 examples: `build no` or `destroot no` could also be an
 elegant way to achieve selective skipping of the entire phase.

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