Split package (optionally)
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-compiler. My library probably doesn't depend on
girepository, except indirectly through the private copy
g-ir-compileruses (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
girepositoryand 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,
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
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.
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.
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.
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.
typelib files of deps
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
grepositoryitself, 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
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".
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
libffi, other deps, and their associated
typelibswithout any g-i tools, C or python.
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:
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.