On Thursday May 19 2016 01:14:19 Clemens Lang wrote:
Hi
>This is really something that should either be done completely and
>correctly, or not. In theory, it's actually not all that hard. You only
I agree.
>need the concept of one Portfile generating multiple different packages,
>allow separate installation of those packages, and introduce a phase
>that splits the files installed by a port into those packages (much of
>which can be automated using a set of rules, as you mention).
*That* would be a really useful feature that goes beyond just the distinction
of "user" and "development" ports - for instance for port:libgcc, or to make a
port:libclang more feasible.
But I don't really see how you could make a generic way of doing this that
doesn't modify the fundamental way MacPorts works.
I've been thinking about this quite a bit lately. What makes split packages
possible in "Debuntu" and presumably in "rpm" is that the build/packaging layer
is separate from the installation layer. This means that you have 1 process
that does patch/configure/build/destroot and then runs a packaging step that
gathers things into one or more secondary destroots, one per package. Actual
installation and package management is a completely different process that only
interacts with binary packages, AFAIK (even if you do an "install-from-source").
With MacPorts the packaging is more of an integrated detour, and installing
from a binary package is kind of like a shortcut into the regular
patch/configure/build/install process. With this approach, building a subport
that's a split off a "complete" port would mean you'd have to build that
complete port (a "shadow" or "mother" port?), the work dir of which you'd
ideally have to keep around for when you want to install another of its
subports. Or you'd have to archive that mother port in a dedicated location
which local builds check before building everything from scratch (but check
against what, how do you know if the user doesn't want to rebuild from scratch
if nothing has been upgraded?).
In any way that would mean changes to the default values provided in work*path
c.s., you'd probably need an additional set of destroot variables (the "mother"
destroot and the actual subport destroot), and if you want to be able to reuse
a build without keeping the full work directory on disk you'd need an automatic
shortcut into the destroot phase.
Thinking aloud about it actually makes it seem a (very) tiny bit more feasible
... but still a formidable challenge if it's supposed to be transparent.
>Yes, it's something we could do for library symlinks, but then you'd
>leave the pkg-config files around that reference libraries that don't
>exist where build systems would expect them. Same for CMake modules,
>header files and a bunch of other stuff.
I've clearly conceived a minimal approach, one that should prevent linker
confusion and not at all aimed at reducing the install footprint.
The presence of header files can indeed be an issue because there too it can be
hard to ensure you get the right ones (and for the exact same reason). They
could be handled very similarly though, by moving aside everything installed
directly into ${prefix}/include.
Ditto for pkg-config files (which go to a fixed location), and sadly you're
right that pkg-config isn't clever enough to look beyond the 1st hit, nor is
CMake (probably). OTOH, this whole situation is about avoiding to pick up
libraries from ${prefix}/lib during the link step despite the fact that the
corresponding -L option points the linker to the correct library location. IOW,
pkg-config or cmake have done their job, most likely because configure or cmake
were instructed that this particular library was to be found somewhere off the
standard path.
Still it's true that avoiding confusion at the pkg-config/cmake/whatever level
would be an additional ensurance that the inteded libraries are used in the end.
Do you see any other stuff that that could interfere during a build?
>tl;dr: It can be done, but it should be done right.
Again, agreed. There's no need for haste, there may not even be a real need to
go beyond thought exercises on this one.
R.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
