Hi,
I've begun to wonder about any guidelines, principles, conventions etc.
concerning where ports are supposed to install their various components.
I've been meaning to ask about this; it's probably more of a macports-dev
question, but one that I think will get more attention here. My apologies to
anyone who cannot be bothered ...
There's of course the ${prefix} which basically replaces the root (/). But
under that ${prefix}, what's supposed to happen?
Looking at the port list, it's evident that a very large part (if not majority)
of ports come from more traditional Unix platforms and are conceived to operate
on systems where Freedesktop/XDG conventions apply.
>From a pragmatic point of view, it seems that the best approach here would be
>to let those ports install their stuff in locations that are as much as
>possible the equivalent of the locations they'd occupy on their native
>platform, basically /opt/local/foo instead of the default /usr/local/foo.
That same approach will see ports for native OS X apps put their stuff into
locations like ${prefix}/Library/Frameworks, as one would expect.
It's probably fine to tune the layout to adhere to guidelines like "cmake files
should go under ${prefix}/share/cmake/Modules", but to what extent does one
have to accept having to patch unknown numbers of dependent ports in order to
comply with such guidelines?
Case in point: port:automoc which was modified (more or less) recently; I'm not
yet convinced that only a few ports need patching to comply with that "fix"
(and at least port:polkit-qt has not been "fixed" so it builds again as of this
moment).
What really inspired this email though is what's happening with the Qt ports,
with the underlying question: is there anything in MacPorts
guidelines/conventions/etc that advises, dictates, dis-advises or forbids
putting all of Qt under a single version-specific prefix?
Or idem re: the approach I have been following, one that maintains the current
Qt layout as much as possible.
As many of you know, I've been working since december 2014 to make Qt4 and Qt5
co-installable (concurrent). I took that task upon me because I had need for it
(and the time and experience) and because the official maintainers didn't have
the time (for another 6-9 months; actually, one was MIA for so long I almost
filed a request to take over the Qt5 port).
After some experimenting I concluded that it was best to make only minimal
changes to the existing installation layout, moving only those components that
made concurrent installation impossible. Everything Qt under ${prefix}/share
was already installed under qt4 and qt5 directories, like it is on
Linux/Freedesktop/XDG platforms (in reality the whole resulting layout is
comparable to what's usual on Linux). In fact I ran into issues with an
approach that seemed easier, putting all of Qt4 into its own
${prefix}/libexec/qt4 prefix. I didn't record exactly what kind of issues they
were, but in hindsight it seems evident that software coming from a Qt-based
Freedesktop/XDG environment (like all KDE ports) expects shared resources in
locations like ${prefix}/share, and that those are at least in part runtime
rather than linker dependencies.
Keeping ${prefix}/share/qtN, ${prefix}/share/doc/qtN etc. locations also avoids
duplicating directory structures (no additional ${prefix}/libexec/qtN/share),
which I consider an advantage as someone often digging for files from a
commandline.
For pure Qt applications that aim to behave like native apps there shouldn't be
a difference. Many of those will build be default as self-contained app bundles
(copying Qt resources from wherever they're stored). In that operation mode,
having a single Qt install dir has advantages, but that directory isn't
specifically intended to be a central repository of shared runtime resources
and libraries. And from what I've seen it is accepted behaviour in the
corresponding ports to disassemble the app bundle or to patch the build system,
in order to force the use of shared resources rather than private copies.
In other words, arguments like "this is how Qt installs on OS X" aren't
relevant for MacPorts (at least in my understanding).
A few final words because this message is already way longer than intended:
I have been running the minimal-change concurrent Qt4 layout since late
December 2014, with a trivially simple variant that puts symlinks to the Qt
framework bundles in their old locations and that removed the need to rebuild
all dependent ports at once, and have had equivalent Qt5 ports in place for
only slightly less time. I have had to change only a handful (<5) ports to
comply with the new layout, and those only because the Portfiles used hardcoded
locations rather than variables from the PortGroup, or added explicit
dependencies to port:qt4-mac.
In other words, I've been able to hot-swap the mainstream/official port and my
own which has been helpful a few times.
BR,
R.
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
