On Tue, Mar 18, 2025 at 9:37 AM Eli Schwartz <eschwartz@xxxxxxxxxx> wrote: > > On 3/18/25 10:15 AM, Rob Herring wrote: > > On Sun, Mar 16, 2025 at 7:42 PM Eli Schwartz <eschwartz@xxxxxxxxxx> wrote: > >> > >> We get full build parallelism and fewer confusing ancient distutils > >> paths. The python wheels build fully standalone, including linking > >> libfdt as a static library. > >> > >> For convenience, when running pip install a meson option is passed that g > >> prevents building tools or installing headers/pkgconfig files. > >> meson-python would otherwise include them in the wheel itself, in case > >> they are needed, but this is essentially a bit useless so don't bother. > > > > This is great as building a sdist that can be uploaded to pypi works. > > I've been maintaining a separate repo solely for that purpose. > > > Interestingly, the one you uploaded to PyPI seems to be called something > different from the name in setup.py and which I reused for pyproject.toml :) At the time I added it, there was a name collision with just "libfdt" which was something else, so I went with "pylibfdt". Now I don't see the libfdt one... FWIW, this is used to build the pypi package: https://github.com/devicetree-org/pylibfdt > >> Signed-off-by: Eli Schwartz <eschwartz@xxxxxxxxxx> > >> --- > >> MANIFEST.in | 12 ------ > >> libfdt/meson.build | 32 ++++++++------- > >> meson.build | 3 +- > >> meson_options.txt | 2 + > >> pylibfdt/meson.build | 28 ++++++++----- > >> pyproject.toml | 25 ++++++++++++ > >> setup.py | 97 -------------------------------------------- > > > > Isn't removing this going to break make based builds as that calls > > setup.py directly? Personally, I think that's fine because I think > > python things should be built "the Python way", rather than trying to > > wrap them in make or meson. David didn't agree though. I think the > > only somewhat sane path is making the make support purely a wrapper to > > call meson so we're not maintaining 2 parallel build systems. > > > Ah yes, that's true. > > Meson *is* "the python way", for what it's worth, as it's a genuine As a backend, yes it seems so, but I meant as a front-end where users run pip (or historically setup.py) rather than running ninja to run pip or setup.py. But looks like with this patch meson works as both the front-end and back-end. All news to me really, as pretty much nothing I've read on how to create and/or install python projects mentions meson, but it's certainly a moving target with setup.py, setup.cfg, pyproject.toml... > python build system, no wrapper :) but I do think it's not worth > supporting make as a route for the python bindings since Make can't > actually build the python code at all. Also, if you're interested in > python bindings you can afford to have python installed, and > consequently, to invoke a build system (meson) written in python. I don't think anyone is arguing that we need to keep the make build because the host doesn't have python. > I have no strong opinions about whether to maintain Makefile rules for > building pure C code. > > I'm not really sure that people building python bindings will need a > Make rule that just runs meson... I agree, but not my call. If that is all make is, then it's not a big deal to support. The problem is meson build is missing some features that make build supports, and no one has cared enough to address that so the make build can be dropped (to be just a wrapper of meson/ninja commands). Rob
