Use environment variables to create the hard-coded 'pylibdir' path

This patch also avoids multi-arch conflicts in g-ir-annotation-tool, g-ir-doc-tool and g-ir-scanner.

I'm hesitant to review multi-arch stuff like this. But…

What's the specific issue you are trying to solve here?

And what happens when LIBDIR and MULTIARCH aren't set?

Hi @jbicha,

Sorry for the delayed reply. I've been busy with freetype.

The template used to create the python scripts g-ir-annotation-tool, g-ir-doc-tool and g-ir-scanner all have a hard-coded pylibdir path based on the Makefile variable @libdir@. This means that all three python scripts conflict on different architectures, since @libdir@ is substituted with /usr/lib/<triplet>.

Replacing the hard-coded path with a dynamically generated path avoids the multi-arch file conflict and is another step towards making gobject-introspection multi-arch co-installable.

And what happens when LIBDIR and MULTIARCH aren't set?

These variables are stored in python's sysconfig module and are set when python is compiled (during an autoconf-like process). If these variables aren't set, then we have far bigger problems to worry about.

Ok, so it's now being set at runtime instead of at compile time.

another step towards making gobject-introspection multi-arch co-installable.

Only some of gobject-introspection's binaries are python scripts so this doesn't end up helping much, does it?

Well, it removes the file conflict for half of the gobject-introspection binaries.

Are you intending to split the others into a separate binary package?

Possibly. It depends on whether they have architecture-independent interfaces and output. I'm looking into this now. Another possibility is to move the files out of /usr/bin and into an arch-dependent path. But that depends on how the binaries are called by other packages now.

changed target branch from debian/master to debian/latest

Obsoleted by the (extensive!) changes made since November 2023 to support cross-compiling.

closed