PortGroup directory hierarchy/priority

René J.V. Bertin rjvbertin at gmail.com
Sun Apr 3 04:26:01 PDT 2016


On Sunday April 03 2016 12:28:05 Rainer Müller wrote:

>As I understood it. Your proposal was to change the lookup strategy for
>port groups, which is currently tied to the lookup for all files in
>_resources.

And I understood that you were thinking of treating every *file* differently, rather than distinguishing PortGroups and the other types of resources.

>Maybe. The point of _resources/port1.0/ is to keep them separate for
>each PortSystem. Whether this versioning is necessary is arguable.

Maybe there should be a wider discussion involving not just the few participants on this thread, before I start hacking "base"?

I tend to view PortGroups as header files, that is files where you move variables and code that should be available to more than just the port that "goes with" the PortGroup. In fact, you could (almost) imagine an implementation where, say, Qt5 installs its PortGroup in some appropriate place, just like it installs Qt headerfiles. That would disambiguate the whole issue, and hopefully also illustrates exactly how I interpret PortGroups (and Mojca too, from what I gather). I suppose it would also remove any requirement for PortSystem versioning.
You could even think of such an implementation where the port decides whether it installs any PortGroup(s). That should allow for custom ports with custom PortGroups that shouldn't apply outside of their port tree. I think it would also allow for backward compatibility if it keeps a fallback to the current lookup strategy.

I can try to make a draft implementation of this, but I'd prefer to have some idea of incorporation likelihoods first. I've already got a few too many draft implementations I've come to rely on.

>The other option would be to properly document how the lookup works for
>the files in _resources.

Yes, but that doesn't address the underlying issue.

R.


More information about the macports-dev mailing list