"devports"

[René J.V. Bertin]

Hi,

I know this comes up once in a while, and how it's non-trivial to integrate with MacPorts's way of doing things: "dev ports" that contain the developer/ment resources corresponding to (usually) a library. These can be very useful to prevent blocking or at least awkward situations in case of build conflicts, where you would prefer not to (or can't) deactivate the runtime components of a conflicting library.

To my knowledge gettext is the only port for which something similar has been implemented; I think it was also for this port that I first implemented my own solution a few years ago when I started porting MacPorts to Linux.

I just added an automatic install/upgrade of the devport after installing or upgrading the mainport, and that seemed like a good time to bring up my implementation :

https://github.com/RJVB/macstrop/blob/master/_resources/port1.0/group/devport-1.0.tcl

I'm not really looking to propose it for inclusion, more for some constructive feedback on how I might improve it.

This PortGroup-based solution introduces a subport called `${name}-dev` and defines some funtions to populate it with standard content (the headerfiles, static libraries and "link-libraries" (libfoo.dylib on Darwin or libfoo.so elsewhere)) and/or user-defined port-specific content. This is all moved into a tar archive in the main port's post-destroot phase.
The devport itself has only a destroot phase, in which that archive is unpacked into `$destroot` and a pre-activate phase that replaces that archive with an empty file because it is no longer required. For this reason the devport's destroot also has a `restore_devport_tarball` feature, in case one wants to reinstall the devport for some reason.

This has been working flawlessly for years, though I almost only use it on Linux, but it has always irked me a little bit that the devport content is installed twice. Writing this I realise that I could probably rewrite the "move into a tar archive" approach with something even naughtier but also more elegant: move it directly into `port work ${name}-dev`/destroot . It was always a question how I'd continue from there, actually installing the port, but I seem to have figured that bit out now:

https://github.com/RJVB/macstrop/blob/6e61d3c444bbd49cf4bed2f886c0a6432b8a643f/_resources/port1.0/group/devport-1.0.tcl#L238

The remaining question is then how to do the "move into the devport's destroot" step in a way that doesn't make it completely impossible to install the devport manually, or else how to handle that fact.

Anyone feel like kicking these tyres with me? :)

R