> Am 07.08.2020 um 01:13 schrieb Ken Cunningham
> <ken.cunningham.web...@gmail.com>:
> An example: let’s take the port MacVIM, which is ripe for this treatment.
>
> We can build and install the current macvim on some newer systems - let’s say
> 10.12 to current.
>
> port -v install macvim gets you that.
>
> We will all know what that port represents, without trouble, if there is a
> ticket.
>
> Now say on 10.7 to 10.11, we want to install a binary version of macvim.
> macvim won't build on those systems, but there is a binary that works.
Good example, really. If we can handle this case of a hybrid port properly, the
case where a port is totally binary only and won't build from source ever is
covered as well.
> We need a clear, identifiable port name to install the macvim binary. It
> should not be called macvim, that is just a *crazy* recipe for trouble. You’d
> never be able to keep up with what was what. We need the port to clearly be
> recognizable as the macvim binary. We need a new name.
Totally disagree here, though. If we have two ports with different names that
provide the same application *that* is exactly the point where the confusion
begins. I'd rather have one port that handles both cases properly. Think of two
port files in one, sharing the equalities but differentiation where required. A
couple of ports do that already and Portfile syntax already allows that today.
In case of trouble, a look at the Portfile (the only one existing, thus correct
one) shows where the if/then/else forks and which version is installed which
way. Verbose mode during install would also print all the info required to see
what's happening as well.
And if we can do this depending on macOS version, we can differentiate based on
other criteria as well. So a single port could theoretically provide both
install modes for all macOS versions (provided the port builds on all versions
and a binary is available for all versions as well). All we'd need to make it
possible would be a way for the user to tell the port command which route to
choose.
Here's where I see a variant as an option as this is an already existing
mechanism through which a user can select which kind of final binary he wants
to be installed. Each variant results in a different binary (being compiled by
MacPorts) already, so using another variant as a way to choose a pre-built
binary where available seems a simple and logical extension of what we already
have and use.
Ports that are always built from sourec to not implement that variant, ports
that always use a binary implement it and define it as the default variant.
Hybrid ports implement it - possibly for a few older macOS versions - and
defaults to building from source where possible. If a port can be build from
source or be installed from binary in a certain environment, the user has the
option of requesting "+pre-built" and will just get that.
