about 2nd and 3rd party cmake modules, rpath components etc.

[René J.V. Bertin]

Hi,

This will be one of my thinking-aloud emails ...

There have been a few recent posts on my qt_select submission ticket on trac, probably from users who have ran into inconvenience issues using the concurrent Qt ports for development of their own. It's true that it is no longer trivial to build software against those "hidden-away" Qt installs, even if you have qt_select or (even better) qtchooser installed.

While this isn't the case with Qt (*), the main culprit there seems to be cmake, which doesn't always find the required 2nd and 3rd party .cmake scripts. I understand that Michael is endeavouring to install those files in a central, "official" location where cmake will search by default, but I'm not sure that's the best solution. There must be a reason if software installs its .cmake files elsewhere, and I'm not aware that mainstream Linux distributions interfere with that systematically (which I would consider an example to follow).

If cmake has (or can be provided with) support for a system-wide configuration/initialisation file (i.e. an initial-cache file that is loaded without need for using the -C option) another solution would be to keep an updated file that sets all relevant variables to an appropriate initial value. That file would be initialised itself with the variables that are now set via the cmake PortGroup.
A dedicated utility (or set of utilities) would give ports the possibility to register information like install locations of their .cmake scripts, using familiar syntax like modules_locations-{append,delete,replace}.
Given how cmake works this would undoubtedly mean that the variables and values are maintained in a separate file from which the initial-cache file is generated in the post-activate phase.

Given that complexity it might also work to provide cmake wrapper (cmake-mp?), that obtains relevant information from the cmake PortGroup and provides options to add module locations, rpath elements and whatever else might be required. That wrapper could be written in Tcl so it can parse the CMake PortGroup directly and use existence convenience procedures. Not all information in the CMake PortGroup is relevant for cmake invocation outside a Portfile though, so the relevant settings could also be stored in a "private" cmake-settings PortGroup designed to be usable from (ba)sh (or python) scripts, whatever scripting language choice is sufficient and efficient for the task.

Your thoughts?

R.

*) the official/mainstream Qt5 ports install their .cmake files into ${prefix}/libexec/qt5/lib/cmake and put symlinks to there into ${prefix}/lib/cmake . My own proposed qt5-kde port simply puts the .cmake files into ${prefix}/lib/cmake directly .