"dev" ports (=/= "devel" ports!)

[René J.V. Bertin]

Hi,

I'd like to draw some attention to a prototype implementation of a PortGroup I wrote for creating "dev" ports, akin to Debian/Ubuntu's "-dev" packages:
https://trac.macports.org/ticket/52713

I've been using this for a while now and find it particularly useful for avoiding build conflicts. That kind of conflict usually arises when the presence of certain files from a port A interferes with building port B. Most often that concerns headerfiles but "linker interface" libraries can also be at cause, or even pkgconfig/cmake files. Those are all files that are only required when using port "A" as a dependency for *building* other software but not as a dependency for running that dependent software.

I think that it should even be possible to use this kind of approach for ports that cannot be built when an older version is already installed; such ports could probably declare a build conflict with their own -dev port (possibly even deactivate it in an appropriate stage).

The current implementation moves selected files into a "fake" port image in an appropriate location during the main port's post-destroot; unpacks that tarball during the -dev port's destroot and zeroes the "fake" port image during the pre-activate because it is now unnecessary. Rather than being emptied that tarball could be replaced with a symlink to the actual software image (but how to get its name?). Or it could be completely removed if rev-upgrade can be told not to complain about certain missing files.

A more elegant version would install that dev port in deactivated fashion when the main port is installed. The basic implementation shouldn't be too difficult (move the selected files into a second DESTDIR, e.g. ${destroot_dev}, use that as the root for installing but not activating ${subport}-dev) but it might be tricky to get right with upgrades etc.
My current simpler implementation via a PortGroup has the advantage that it can help assess how much use this kind of feature would see, and thus how much effort should be put into it.

R.