Migrate to meson build system with PPL 1.2#38
Migrate to meson build system with PPL 1.2#38cxzhong wants to merge 22 commits intosagemath:masterfrom
Conversation
|
This should not bundle ppl unconditionally. ppl is relatively popular library and is available on many systems. While That is, to get the correct CXXFLAGS (important for C++ compatibility), one can just get them by calling |
Since the traditional wheel build also pack ppl and others into wheel. |
|
one does not need to build a dylib from source in order to pack it into a wheel. |
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. |
|
I don't see how it's better. If you have a dylib on your system, you want to reuse it |
because it will let user just pip install pplpy, then the user can run this without install some system packages |
|
Now, if you install libppl-dev and ppl-dev. it can build from system's ppl. If not, it will run a subproject. |
there is a number of reasons why it's less preferable: @orlitzky has a good answer I am sure |
|
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 |
|
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? |
yeah, vendoring the sources of ppl is totally unnecessary - I haven't looked at the implementation details yet. |
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.
tobiasdiez
left a comment
There was a problem hiding this comment.
Thanks. This looks prettyy good to me. A few smaller suggestions/nit-picks from my side.
…pts for improved readability and maintainability
…lity and maintainability
|
looks mostly good. Are you sure you need to do things like computing the absolute path to GMP headers? |
…emove deprecated include/lib directory resolution
| configure_env += ['LDFLAGS="' + ' '.join(extra_ldflags) + '"'] | ||
| endif | ||
|
|
||
| # ---------- Build PPL via autotools ---------- |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
ppl package does not provide pc file
There was a problem hiding this comment.
I have tested this way, meson can not find ppl
There was a problem hiding this comment.
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)
…emove environment permissions
There was a problem hiding this comment.
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
There was a problem hiding this comment.
I don't know which of the two conflicting entities should take precedence - from readme or here
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
Replace the setuptools/distutils build with Meson:
Use Meson wrap to fetch PPL 1.2 source on demand instead of bundling:
std::auto_ptr, std::mem_fun_ref, memcpy casts, missing includes)
Update CI workflows: