Skip to content

Comments

Migrate to meson build system with PPL 1.2#38

Open
cxzhong wants to merge 22 commits intosagemath:masterfrom
cxzhong:meson
Open

Migrate to meson build system with PPL 1.2#38
cxzhong wants to merge 22 commits intosagemath:masterfrom
cxzhong:meson

Conversation

@cxzhong
Copy link

@cxzhong cxzhong commented Feb 7, 2026

Replace the setuptools/distutils build with Meson:

  • Add meson.build for the root project, ppl/ package, and tests/
  • Add pyproject.toml with meson-python backend
  • Remove setup.py, setup.cfg, and tests/setup*.py

Use Meson wrap to fetch PPL 1.2 source on demand instead of bundling:

  • Add subprojects/ppl-1.2.wrap downloading from sagemath/sage releases
  • Add subprojects/packagefiles/ppl-1.2/meson.build as build overlay
  • Add compiler-fixes patch for C++17 compatibility (std::iterator,
    std::auto_ptr, std::mem_fun_ref, memcpy casts, missing includes)
  • Generate ppl-config.h at configure time without template file
  • Prefer system PPL via ppl-config script, fall back to subproject

Update CI workflows:

  • Add wheel builds for ubuntu, macOS ARM, macOS Intel, and linux-arm
  • Build GMP and GLPK from source for manylinux wheel portability
  • Add free-threading (cp314t) and musllinux support
  • Add macOS-15-intel runner to dist.yml matrix
  • Update pyproject.toml license to GPL-3.0-only
  • Pin cibuildwheel to v3.3.1, upgrade CI actions to v6
  • Fixes Use meson-python to build #33

@cxzhong cxzhong marked this pull request as ready for review February 7, 2026 21:46
@cxzhong cxzhong requested review from dimpase and tobiasdiez February 7, 2026 21:49
@dimpase
Copy link
Member

dimpase commented Feb 8, 2026

This should not bundle ppl unconditionally. ppl is relatively popular library and is available on many systems.

While ppl does not provide pkg-config configuration, it installs a script called ppl-config, which does things like ppl-config --cxxflags, etc

That is, to get the correct CXXFLAGS (important for C++ compatibility), one can just get them by calling ppl-config --cxxflags. Same for linking (call ppl-config --ldflags)

@cxzhong
Copy link
Author

cxzhong commented Feb 8, 2026

This should not bundle ppl unconditionally. ppl is relatively popular library and is available on many systems.

While ppl does not provide pkg-config configuration, it installs a script called ppl-config, which does things like ppl-config --cxxflags, etc

That is, to get the correct CXXFLAGS (important for C++ compatibility), one can just get them by calling ppl-config --cxxflags. Same for linking (call ppl-config --ldflags)

Since the traditional wheel build also pack ppl and others into wheel.

@dimpase
Copy link
Member

dimpase commented Feb 8, 2026

one does not need to build a dylib from source in order to pack it into a wheel.
pplpy is packaged by Arch, Gentoo, and they certainly will object
to this kind of design

@cxzhong
Copy link
Author

cxzhong commented Feb 8, 2026

one does not need to build a dylib from source in order to pack it into a wheel.
pplpy is packaged by Arch, Gentoo, and they certainly will object
to this kind of design

OK, Then I try to find ppl. If do not find then use subproject. but for wheel build. I think it is better to build everything static.

@dimpase
Copy link
Member

dimpase commented Feb 8, 2026

I don't see how it's better. If you have a dylib on your system, you want to reuse it
(ppl also has gmp as a dependency, so it's basically bloating
things up for no reason)

@cxzhong
Copy link
Author

cxzhong commented Feb 8, 2026

I don't see how it's better. If you have a dylib on your system, you want to reuse it
(ppl also has gmp as a dependency, so it's basically bloating
things up for no reason)

because it will let user just pip install pplpy, then the user can run this without install some system packages

@cxzhong
Copy link
Author

cxzhong commented Feb 8, 2026

Now, if you install libppl-dev and ppl-dev. it can build from system's ppl. If not, it will run a subproject.

@dimpase
Copy link
Member

dimpase commented Feb 8, 2026

I don't see how it's better. If you have a dylib on your system, you want to reuse it
(ppl also has gmp as a dependency, so it's basically bloating
things up for no reason)

because it will let user just pip install pplpy, then the user can run this without install some system packages

there is a number of reasons why it's less preferable: @orlitzky has a good answer I am sure

@tobiasdiez
Copy link
Contributor

A good compromise is to try to detect ppl and if not available use it from a subproject. But pls don't include the source files directly, but use a wrap (eg https://github.com/dimpase/primecountpy/blob/master/subprojects/primecount.wrap): https://mesonbuild.com/Wrap-dependency-system-manual.html

@orlitzky
Copy link

orlitzky commented Feb 8, 2026

There is a good list at https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies but even that is missing some things like needing to duplicate patches to fix the build with newer compilers, and the ways various licenses change when you are copy/pasting code rather than linking.

And who wants to install pplpy if they don't have PPL first?

@dimpase
Copy link
Member

dimpase commented Feb 8, 2026

A good compromise is to try to detect ppl and if not available use it from a subproject. But pls don't include the source files directly, but use a wrap

yeah, vendoring the sources of ppl is totally unnecessary - I haven't looked at the implementation details yet.

@tobiasdiez
Copy link
Contributor

And who wants to install pplpy if they don't have PPL first?

Well, from a user's perspective installing a binary wheel of pplpy that includes PPL is definitively more friendly than having to install PPL first manually, and then building pplpy from source.

Replace the setuptools/distutils build with Meson:
- Add meson.build for the root project, ppl/ package, and tests/
- Add pyproject.toml with meson-python backend
- Remove setup.py, setup.cfg, and tests/setup*.py

Use Meson wrap to fetch PPL 1.2 source on demand instead of bundling:
- Add subprojects/ppl-1.2.wrap downloading from sagemath/sage releases
- Add subprojects/packagefiles/ppl-1.2/meson.build as build overlay
- Add compiler-fixes patch for C++17 compatibility (std::iterator,
  std::auto_ptr, std::mem_fun_ref, memcpy casts, missing includes)
- Generate ppl-config.h at configure time without template file
- Prefer system PPL via ppl-config script, fall back to subproject

Update CI workflows:
- Add wheel builds for ubuntu, macOS ARM, macOS Intel, and linux-arm
- Build GMP and GLPK from source for manylinux wheel portability
- Add free-threading (cp314t) and musllinux support
- Add macOS-15-intel runner to dist.yml matrix
- Update pyproject.toml license to GPL-3.0-only
- Pin cibuildwheel to v3.3.1, upgrade CI actions to v6
Removed default C++ standard option from project configuration.
Removed default C++ standard option from project configuration.
@cxzhong cxzhong requested review from dimpase and orlitzky February 9, 2026 09:22
@cxzhong cxzhong changed the title Migrate to meson build system with bundled PPL 1.2 Migrate to meson build system with PPL 1.2 Feb 9, 2026
@cxzhong cxzhong mentioned this pull request Feb 9, 2026
Copy link
Contributor

@tobiasdiez tobiasdiez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. This looks prettyy good to me. A few smaller suggestions/nit-picks from my side.

@cxzhong cxzhong requested a review from vbraun February 9, 2026 14:53
@dimpase
Copy link
Member

dimpase commented Feb 11, 2026

looks mostly good.

Are you sure you need to do things like computing the absolute path to GMP headers?
This looks like an overkill. Pkg-config will tell you if you need any -I to be added to CXXFLAGS

…emove deprecated include/lib directory resolution
configure_env += ['LDFLAGS="' + ' '.join(extra_ldflags) + '"']
endif

# ---------- Build PPL via autotools ----------
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use https://mesonbuild.com/External-Project-module.html instead of calling configure & make manually. The sagemath repo contains some examples of how to do this as well

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ppl package does not provide pc file

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have tested this way, meson can not find ppl

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't need a pkg config file if you use it that way. The dependency is found via

mylib_dep = p.dependency('mylib')
meson.override_dependency('mylib', mylib_dep)

see eg https://github.com/sagemath/sage/blob/5473e598ac601e989b33945622529a827ff9ed0d/subprojects/packagefiles/maxima/meson.build#L35-L43

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you can change the license terms just like this. You need an approval from all significant contributiors - @videlec @vinklein, possibly more

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pplpy is distributed under the terms of the GNU General Public License (GPL) published by the Free Software Foundation; either version 3 of the License, or (at your option) any later version. See http://www.gnu.org/licenses/.

It is in the readme. I think it is should be GPL-3.0-or-later not GPL-3.0-only.
I found the mistake today. @dimpase

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you can change the license terms just like this. You need an approval from all significant contributiors - @videlec @vinklein, possibly more

I do not change the license.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know which of the two conflicting entities should take precedence - from readme or here

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know which of the two conflicting entities should take precedence - from readme or here

and ppl is distributed by gpl 3.0 or later
https://support.bugseng.com/ppl/
We should follow this

Copy link
Author

@cxzhong cxzhong Feb 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know which of the two conflicting entities should take precedence - from readme or here

And I think before that GPLv3 is not clear license statement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Use meson-python to build

4 participants