Compiling a port statically

[Richard L. Hamilton]

Why should that change? You don't pre-build binaries for more than a few very common variants, so you wouldn't do so for static variants using such a capability. It (hypothetically) would merely be there for those cases where (a) the needed library ports provided a static version, (b) someone wanted a static (except for libSystem etc) variant that used them, and (d) wanted to have it treated as if it was outdated if anything referenced when it was built had changed.  But it'd probably be doable for the buildbots even for a static variant, IF they knew to actually check for outdated-ness using the hypothetical new mechanisms. But for the user to know, the binary bundle would have to include the version(s) info for the statically linked components, so their installation would be able to determine whether it was outdated by the hypothetical new definition.

I _think_ that covers most of the possibilities. Again, it looks like a LOT of pain for a minimally beneficial capability.  My point is mostly don't buy that something is impossible, or even impossible given existing goals...IF the resources existed to come up with a good implementation, and there weren't higher priorities. But they don't, and there are, which is why I'm not suggesting it.


> On Dec 6, 2020, at 16:59, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> 
> 
> On Dec 6, 2020, at 15:52, Richard L. Hamilton wrote:
> 
>> I'm going to play devil's advocate on this and another post (with competing positions, so don't feel bad).
>> 
>> MacPorts knows the library dependencies of a port. While it does not now (AFAIK) record the specific versions of each used to build an installed port, in principle, it could; at which point it could (also in principle) determine whether any of them had changed, thus requiring a rebuild of the port that depended on them, even if its version hadn't changed.
>> 
>> That's NOT a feature request, or probably even a practical idea. But IMO, it does indicate that there are solutions such that the library ports would NOT have to be aware of what used them.
> 
> You are correct, MacPorts does not work like this today. And as an example of something for you to think about, and not something to which I'm asking for answer: how would the binaries that we distribute get rebuilt under this hypothetical scenario?
> 
>