PortFile command

[René J.V. Bertin]

On Thursday January 26 2017 15:18:40 Brandon Allbery wrote:

> The complication is that, on installing, the Portfile (and, with this
> change, any inclusions) gets saved in the registry so that its uninstall

Yes, currently that's only the Portfile, and that happens in portinstall.tcl . A bit further down is the code that copies the used PortGroups (stored in PortInfo(portgroups)) into the registry.
I only took a quick look, but I don't think it would be particularly hard to copy other files along with the Portfile, and I assume that copying them that way is all that's required for running the port from the registry.

On Thursday January 26 2017 21:56:59 Rainer Müller wrote:
> Looking at the VLC port it looks like the subport ffmpeg-VLC and the
> main port have nothing in common at all.

You're not wrong but that's not entirely true either, the subport builds an ffmpeg version that's patched specifically for use by VLC, and VLC also has a few patches to make it work with that ffmpeg build.
They're only subports because it's not supposed to be a permanent solution and as such it didn't feel right either to make ffmpeg-VLC a standalone port.

> Don't force yourself to use subports if it adds unwanted complexity.

That's true, but splitting off really related ports into separate port directories also adds complexity which to me can be more cumbersome to deal with in practice than the main kind of complexity that (lots of) subports cause: a big file.

Let's take another example then: my KF5-Frameworks meta-port (https://github.com/RJVB/macstrop/blob/master/kf5/KF5-Frameworks/Portfile), which shares a number of properties with port:qt5's Portfile. It's essentially a list of relatively simple subports, one each for the 60+ KF5 Frameworks with a few -devel versions thrown in, plus some common code and variants. The subports are simple because a lot of reusable code has been refactored into the PortGroup and because the checksums are stored in a table that's defined in a file in ${filespath}. Still, it's a bit unwieldy at over 2300 lines, and as such I'd love to be able to break it up following the Tier1,2,3,4 + PortingAids categorisation that KDE use (where the tiers correspond to the level of framework inter-dependencies). There are a meta-ports corresponding to those tiers but there's no functional argument that would justify making those standalone meta-ports. That organisation only makes sense during upgrade cycles; these frameworks are version-linked, and when upgrading you start with the Tier1 level and end with the porting aids.

So ideally I'd have a Portfile that includes the checksum table, and then Portfile.{tier1,tier2,tier3,tier4,portingAids} . The checksum table doesn't need to be copied into the registry, but the other 5 files would.
Actually, I don't know if it'd be the ideal solution because I haven't tested it, but I'm quite certain I wouldn't want to have to deal with the code duplication and keeping-in-sync that would come from splitting up the beast.

'nuf said...

R.