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 .
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
