Split package (optionally)
Motivation
There's a few interlocking concerns that make the current full-featured installation a bit subpar:
Compiled libraries and end-consumers of typelibs have different needs.
Using https://gi.readthedocs.io/en/latest/architecture.html as a guide:
-
If I am compiling a library, I just need
g-ir-scanner
andg-ir-compiler
. My library probably doesn't depend ongirepository
, except indirectly through the private copyg-ir-compiler
uses (which is statically linked, IIUC, precisely so it doesn't "leak"). -
I am using a library from a dynamic language, I don't need access to any of the tool, just
girepository
and the typelibs.
Distro's usually like to have separate "dev" vs "deploy" build artifacts. Traditionally, this is to reduce space usage on deployed machines, but as a distro maintainer I think equally important is limiting package's access to dependencies to ensure they are used in correct ways---ambient authority is the distro maintainer's worst enemy and PoLP the distro maintainer's best friend. I would certainly like to distinguish the two above scenarios for these reasons.
Cross compilation requires mixing and matching builds anyways
The python tools are target agnostic. I've spent some time pouring over tools/g-ir-tool-template.in
and how those builtins are used.
$ git grep -E '(DATA|GIR)DIR'
giscanner/dumper.py: gdump_path = os.path.join(os.path.join(DATADIR),
giscanner/transformer.py: data_dirs.append(DATADIR)
giscanner/transformer.py: searchdirs.extend(GIRDIR)
tools/g-ir-tool-template.in:builtins.__dict__['DATADIR'] = datadir
tools/g-ir-tool-template.in:builtins.__dict__['GIRDIR'] = [girdir]
tools/g-ir-tool-template.in: builtins.__dict__['GIRDIR'].append(os.path.join(filedir, os.pardir, 'gir'))
# elided other results
From chasing all those results down, it is clear there are two basic usages:
- Initializing various search paths,
- Finding
gdump.c
(which is target agnostic)
This confirms that the python scripts really are target agnostic, which is why the prebuilt ones can be used with the new options from !64 (merged).
However, if we just use a regular build-time install of g-i to get the python tools, that search path initialization will mean we have a mix of native and foreign arch typelibs
and gir
files on the search path, which is a maintainability nightmare.
Cross compilation would also benefit from limiting access, so as to keep the search path clean.
Conceptual Proposal
My plan is to optionally allow 3 separate installation, which can then be mixed/wrapped together into two packages corresponding to the two use-cases described above.
Underlying packages
Python tools
I want to install the python tools alone with just gdump.c
, so they are truly target agnostic and don't per-initialize the search path with any introspection data for any particular architecture.
The "native" tools are always used. Now python is interpreted which blurs what architecture the platform is "built" for, but these tools additionally use an extension module (in C), which is bona-fide built, and thus clarifies that we really are using the native tools.
C tools
The C tools are only needed by compiled libraries for which we want to build introspection data. Because the C tools dl open the library, for cross we need to run them via QEMU or other emulator.
gir
and typelib
files of deps
(Tentative) If I understand correctly, this package provides gir files for glib, libxml, etc., in order to break dependency cycle of using those libs to build grepository
, but the gobject-introspection
to build those libs(' introspection data).
If that is correct, this makes sense to me. But I would want these in a separate installation too.
- The practical reason is library that need to generate introspection data need not depend on
grepository
itself, but quite likely depend on those deps too - The philosophical reason is the choice of where to break a cycle is somewhat arbitrary, and I wish to hide the specific choice from downstream packages.
(An example of another way to break the cycle would be building all those libraries, building g-i, and then building all those libraries again, this time with introspection data. That is a wasteful bootstrap, but does have the advantage for downstream that the introspection data for a library always comes with that library, not in another package.)
girepository
library, headers, and own gir
and typelib
files
Finally, there is girepository
itself and it's development data. Of course, per useful practice, this might be further broken down so the the shared objects and typelibs might be put in a "deployment" package, while the girs and headers go in a "development package".
Meta/Wrapper packages
So, per the two original use-cases, a distro can have two meta-wrapper packages:
-
For libraries that need to generate bindings, we can give them:
- python tools for the build-time platform
- c tools for the run-time platform
- wrapper scripts that properly initialize search paths and use emulators
Distros may also want to use the wrapper script to collect dependencies' typelib and gir files, or may do that separately.
-
For packages that use the bindings, they use
girepository
,libffi
, other deps, and their associatedtypelibs
without any g-i tools, C or python.
Implementation strategy
I am not sure what's best, please suggest!
So far, I see two basic options to allow building the 3 core packages for distros to wrap into the two:
-
Conditional
subdir
, controlled by meson configure options, like today -
Switch to separate Meson subprojects, mixed together into one meta-project distro for back-compat.
The second option does seem nicer, but I don't want to mess up users that already use g-i as a meson subproject, since there are no nested subprojects.
Appendix: Original issue description
(Original title: Split *.pc
files for sake of cross compilation)
!64 (merged) was a great start, but there's more work to do.
Note that when we build the library, with introspection data, using prebuilt tools (cross_use_host_gi
), we still will put a bindir
in the newly-built library's pc file. This rather impedes more cross compilation, when we do not wish to use any cross-compiled g-ir-scaner
but again keep on using a native build one. Meson's gir support in particular stumbles all over this (though I will try to work on Meson about that in any event).
If we were to have a separate library vs tools pc file, or even pc files per tool, It would be easier to tell build systems "I need these native: true
tools and native: false
libs", requiring just what was needed.