pylibfdt/meson.build: fix Python library being rebuilt during install

[blmaier]

User @sharkcz noted that when the '--quiet' flag is removed from ./setup.py, the following can be seen from the ./setup.py install stage.

  Running custom install script 'dtc/g/pylibfdt/../setup.py --top-builddir \
    dtc/g/redhat-linux-build install --prefix=/usr/local --root=$DESTDIR'
  running install
  ...
  building '_libfdt' extension
  swigging dtc/g/pylibfdt/../pylibfdt/libfdt.i to \
    dtc/g/pylibfdt/../pylibfdt/libfdt_wrap.c
  swig -python -Idtc/g/pylibfdt/../libfdt -o \
    dtc/g/pylibfdt/../pylibfdt/libfdt_wrap.c dtc/g/pylibfdt/../pylibfdt/libfdt.i
  gcc -fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 \
    -DNDEBUG -fexceptions -fexceptions -fexceptions -fPIC -DPY_SSIZE_T_CLEAN \
    -Idtc/g/pylibfdt/../libfdt -I/usr/include/python3.12 -c \
    dtc/g/pylibfdt/../pylibfdt/libfdt_wrap.c -o \
    build/temp.linux-ppc64le-cpython-312dtc/g/pylibfdt/../pylibfdt/libfdt_wrap.o
  creating build/lib.linux-ppc64le-cpython-312
  gcc -shared build/temp.linux-ppc64le-cpython-312dtc/g/pylibfdt/../pylibfdt/libfdt_wrap.o \
    -Ldtc/g/redhat-linux-build/libfdt -L/usr/lib64 -lfdt -o \
    build/lib.linux-ppc64le-cpython-312/_libfdt.cpython-312-powerpc64le-linux-gnu.so
  copying dtc/g/pylibfdt/../pylibfdt/libfdt.py -> build/lib.linux-ppc64le-cpython-312

Meaning the python library is getting recompiled during the meson install phase. This causes build issues as Meson does not set the compiler and linker flags during the install phase.

The reason the library is getting rebuilt is during the normal build with "build_ext", the --build-lib flag gets passed which changes the default output build directory. But there is no equivalent option for the "install" command. Install instead looks in the default directory "./build" and so does not find the previously built library.

Since we can't fix the "install" command, drop the --build-lib flag. This causes setup.py to compile the libraries at <meson-build>/build/lib.linux-x86_64-cpython-312/. We must also then fix run_tests.sh to find the library build directory as it's machine-dependent.

Fixes: #135

[dgibson]

@blmaier thanks for the patch. Unfortunately, something still seems to be missing. It appears the logic you added to find the library during the tests only works on some distros when making meson builds: as you can see the github actions for alpine and fedora are failing, and likewise a local meson build fails the tests for me, because it's unable to import the libfdt module.

[blmaier]

@dgibson weird I can't reproduce this locally, but I was able to fix it with the github workflow.

There does seem to be a clang64 test failing under Windows. Though it appears this is failing on 'main' so that is likely unrelated :smiley:

[dgibson]

@blmaier thanks for the update

@dgibson weird I can't reproduce this locally, but I was able to fix it with the github workflow.

Huh, odd.

There does seem to be a clang64 test failing under Windows. Though it appears this is failing on 'main' so that is likely unrelated 😃

Yes, that's been around for a while, the reason is not obvious to me but seems to be something with the environment rather than a bug in dtc itself. Don't really have the Windows knowledge to fix it.

[dgibson]

Merged, thanks.

[sharkcz]

for the record, it resolves the issue for me