Re: [PATCH 2/2] pylibfdt: Compile and build libfdt directly into shim library

[David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3392 bytes --]

On Thu, Feb 03, 2022 at 12:04:08PM -0600, Rob Herring wrote:
> The interactions between pylibfdt setup.py and the host and build system
> is fragile. setup.py can be called directly or via pip, tox, pytest, etc.
> Building the SWIG shim library needs the libfdt headers and library .so
> file. These can be located in the source tree, the OOT build directory,
> or several locations in the host filesystem if installed.

Right.  I do believe that if feasible we should only support building
from the main dtc tree, and therefore only using the files from that
tree, not anywhere else on the host system.

> Furthermore, the SWIG shim library is tightly coupled to the version of
> libfdt it is built against. Specifically, all functions defined in the
> libfdt.h header used for the build must resolve at runtime whether they
> are used or not. IOW, the installed libfdt must be the same version (or
> newer?) than what pylibfdt was built against.

I believe "or newer" should be safe, at least assuming we don't badly
screw up the symbol versioning.  That's a pretty significant
difference from "must be the same version".

> The typical way to solve this problem would be to allow user provided
> library and include directories, but this doesn't seem to work too well
> with setup.py. While setup.py sub-commands can take such options, it
> doesn't work with implicit commands (e.g. an 'install' triggers 'build')
> or pip.
> 
> The simplest solution to all this is just build libfdt into the shim
> library. This avoids any possibility of version mismatches. The python
> setuptools already knows how to compile C files in extensions, we just need
> to list the files.

Urgh.  I don't love having what's essentially a different way of
building the code than the existing make or meson stuff.

> Cc: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Cc: Hector Oron <zumbi-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
> Cc: Peter Robinson <pbrobinson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Marc-André Lureau <marcandre.lureau-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Cc: Natanael Copa <ncopa-Tvuechaw34bCfDggNXIi3w@public.gmane.org>
> Signed-off-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> RFC because this leaves the meson integration broken and I suspect the
> distro folks (Cc'ed here) won't really like duplicating libfdt. Note that
> the 'shim' alone is about 3x the size of libfdt.

No, they probably won't.  Note that the primary reason that distro
folks like to re-use shared libraries as much as possible isn't about
size, it's about ease of deploying updates (including for security).

Then again, they're probably having to get used to the harder case
these days, due to Go's static linking fetish.

> IMO, the meson wrapper should just be removed. Python users know how to
> run setup.py or pip. Why add a layer of indirection?

I'm not exactly sure what you're considering the "meson wrapper".
Note that from my point of view anything which means that doing a full
build and test from scratch would require more than a single make or
meson command is pretty much unacceptable.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]