Debian/Ubuntu-style -dev ports

[René J.V. Bertin]

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.