Remove autogen?

[tobiasdiez]

Instead of auto-generating parts of the pari interface upon building, I would propose to commit the autogenerated files and use them for the build. From time to time, the autogeneration has to be rerun to include newly added functions from pari updates. Similar to how the flint autogen works in sage: https://github.com/sagemath/sage/blob/cb030433d73cb3a25d5a8c79c5e0c3b1f41893b3/src/sage_setup/autogen/flint/README.md?plain=1#L23

This has the advantage to remove the moving parts in the build system and should speed up the build a bit.

---

Background: I got quite often now the following error during build:

error: [Errno 2] No such file or directory: 'gphelp'
      hint: This usually indicates a problem with the package or the build
      environment.

(eg on gentoo https://github.com/sagemath/sage/actions/runs/17171782258/job/48722349482?pr=40663)

[videlec]

The current workflow has the great advantage of being compatible with a lot of pari versions (including most often the development one). Note that the auto-generated files do depend on the PARI version. But then which version of PARI will you target for a given cypari release? I would rather propose to

• not commit the auto-generated files
• include the auto-generated files in each tarball of a cypari release (possibly several cypari releases if one insists on having precise compatibility with PARI)

Note that the flint story is quite different since it is a (tiny) part of sagemath which works with a fixed version of flint.

[tobiasdiez]

Note that the auto-generated files do depend on the PARI version.

I tried to understand how this works. It reads the pari.desc file and then based on it generates some headers. What I don't understand is how those headers then are really used. For example, what happens if Pari v1 declares foo(a, b) but Pari v2 declares it as foo(a,b,c). Does this change then automatically propagates through and the python pari (i..e cypari2.Pari()) has then two different foo methods?

Note that the flint story is quite different since it is a (tiny) part of sagemath which works with a fixed version of flint.

It also supports a few versions of flint (not only the one that is shipped with sage-the-distro).