CI: lint job to check LALSuite library dependencies
Description
In attempting to reverse the dependencies between LALPulsar and LALInference (cc #540 (closed)) I've written a script gnuscripts/check_library_dependencies to check that LALSuite library dependencies are consistent across Autoconf/GitLab CI/Conda/Debian/RPM.
The script necessarily takes a conservative approach, in that e.g. if it says libA depends on libB, it will apply that dependency across C/Python/Octave packages, even if e.g. the Python code in libB doesn't have an explicit import libA. This is not unreasonable; as I've noted elsewhere, the internal workings of the SWIG wrappings means that the C and Python/Octave dependencies are closely linked, so e.g. the SWIG wrappings of libA will implicitly import libB. (The only way libA could have a Python-only dependency on libB is if both libraries has the SWIG wrappings disabled; an import libB statement in libA would then import Python code only.)
Even if this approach leads to some over-dependence, that's probably not such a bad thing, at least for the development packages. The danger of under-dependence (i.e. not specifying all dependencies) could mean that the CI tests end up pulling in production packages and not local builds (cf. !1854 (merged)). Also, new code added to LALSuite could start using the complete dependencies. So perhaps it makes sense to use conservative dependencies for development, and then trim them down for the production packages (which I assume are maintained elsewhere).
As a result of running the script I've added a few new dependencies to the packages. The conda builds threw up warning messages about over-dependence; I'm not whether these are false positives or not, as I'm not sure if the conda builds are smart enough to track the SWIG wrapper dependencies. In any case I've used ignore_run_exports to silence the error messages.
I've added a lint job to run the script, but could drop it if that's overkill.
Closes #435 (closed)
API Changes and Justification
Backwards Compatible Changes
-
This change does not modify any class/function/struct/type definitions in a public C header file or any Python class/function definitions -
This change adds new classes/functions/structs/types to a public C header file or Python module
Backwards Incompatible Changes
-
This change modifies an existing class/function/struct/type definition in a public C header file or Python module -
This change removes an existing class/function/struct/type from a public C header file or Python module