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.
