Re: Build and run-time triplets

[Julian Gilbey <julian@d-and-j.net>]

On Thu, Jun 09, 2022 at 11:00:28AM +0100, Simon McVittie wrote:
> On Thu, 09 Jun 2022 at 09:56:42 +0100, Julian Gilbey wrote:
> > OK (and yes, it does require the full path at runtime).  What triplet
> > do I use in d/rules?  dpkg-architecture offers 6 different ones:
> > DEB_{BUILD,HOST,TARGET}_{GNU_TYPE,MULTIARCH}?  I'm guessing
> > DEB_TARGET_MULTIARCH, but I'm really not certain, so it would be great
> > to confirm that.
> 
> You'd want DEB_HOST_MULTIARCH here (or use ${LIB} as I mentioned in a
> previous message to this thread).
> [...]

Thanks for this great explanation - I'm learning so much in this
thread!

> > About the location, though: why do compiled Python libraries live in
> > /usr/lib/python3/dist-packages/<pkgname> and not
> > /usr/lib/<triplet>/<pkgname>?
> 
> The Python jargon for a native C/C++ library that can be loaded to
> provide a Python module is an *extension*.
> [...]

> > And is there a good reason not to do
> > the same with this Python-package-specific library?
> 
> If it isn't a Python extension (cannot be loaded into Python with
> "import foo" to provide a module API to Python code) then it would seem
> inappropriate to put it in the directory that is reserved for Python
> extensions.

I hear this argument, though we do find data files and other sorts of
things other than Python files and compiled extensions that are needed
by Python modules in that same directory ("data_files" in setup.py);
for example numpy has dozens of other files in
/usr/lib/python3/dist-packages/numpy.

I think the counter-argument is exactly what you said: as long as the
shared library is in a place where the code that uses it knows where
to locate it, all will work fine.  The Python code as-written expects
the library to be in the same directory as the Python code.

Best wishes,

   Julian