Hi Ryan,
Ryan Schmidt wrote:
- building "always safe" binaries which can be used at system level, e.g. login shells,
tools, things put in launchd. That is things you want to always work, even if you are during a
MacPorts upgrade. NetBSD offers two packages for the same thing, e.g. bash and bash-static, IIRC.
perhaps in MacPorts it could be a "variant"?
No, we should not offer a variant of any port to do a static build. Static
build means all of the libraries that a program depends on are copied into the
program executable. That means if we later update one of those libraries to a
newer version, the statically-built program will not benefit from those fixes,
unless its revision is increased to rebuild it, but whoever updated the library
would not know that that needs to be done. We should not introduce more
situations into MacPorts where developers updating library ports need to know
about increasing the revisions of ports that use the library. Instead we should
do the opposite, identifying those ports that only build a static library and
fixing them so that they also or instead build a dynamic library so that ports
that link with them can benefit from new versions without needing to be rebuilt.
Indeed, you are right, a "variant" here would indeed be an issue I
didn't think about.
We should not replace a dylib with it static version, we should provide
both, one possibly used only for build reason.
Under the assumption that "static libraries" are of no real interest if
not to build static commands and that these should remain a minority in
your installed ports, it should be a different thing
E.g. suppose libA is needed by many ports, we install it as shared and
right so.
However tool X needs libA and if you want toolX as static, its dependent
static library libA should be built *also* as static. Technically, once
built, the static library could be even removed.
So it is only a "build" dependency.
If libA gets an update, no lookup can tell you to update toolX, but this
side effect is also the goal - toolX will continue working (but might
have a security issue or whatever). Another command to look up toolX
could envisioned, but toolX would continue working and that is the
important thing.
Riccardo
