-
-
Notifications
You must be signed in to change notification settings - Fork 553
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pkgs/*/setup.cfg: Reduce boilerplate by m4-include, reduce complexity of m4 use #35867
Conversation
…to requirements.txt
…yproject.toml.m4 (fixup)
Documentation preview for this PR (built with commit 5ecf106; changes) is ready! 🎉 |
This
|
Can it be fixed by dropping Python 3.8 ? |
This error is new, from the incremental build introduced in #35652. Unrelated to the present PR and to unrelated to the Python version. Tracked in: |
Not sure about less scary, but factorisation of the repeated bits is good. It is much more easy to understand I think. What makes the build/test fail? |
An occurrence of #35813, unrelated |
I understand what Dima was talking about now :) Looks good to me. |
Thanks! May I set to "positive review"? |
After this was merged I can't bootstrap sagelib on its own. This works in 10.0.beta5:
After bootstraping sagelib like that one can build Same thing in 10.0.beta6:
Half of this is due to
Now the problem is that Actually creating |
On Thu, Jul 13, 2023 at 2:46 PM Gonzalo Tornaría ***@***.***> wrote:
After this was merged I can't bootstrap sagelib on its own.
This works in 10.0.beta5:
$ cd build/pkgs/sagelib
$ PATH=../../bin:$PATH ./bootstrap
After bootstraping sagelib like that one can build sagemath-standard on
its own and it works perfectly well (I've been doing it for the void linux
package since 9.5).
Same thing in 10.0.beta6:
$ cd build/pkgs/sagelib
$ PATH=../../bin:$PATH ./bootstrap)
m4:src/setup.cfg.m4:1: cannot open `sage_spkg_versions.m4': No such file or directory
m4:src/setup.cfg.m4:9: cannot open `setup_cfg_metadata.m4': No such file or directory
Half of this is due to SAGE_ROOT missing so M4PATH is not correctly set.
But still:
$ SAGE_ROOT=../../.. PATH=../../bin:$PATH ./bootstrap
m4:src/setup.cfg.m4:1: cannot open `sage_spkg_versions.m4': No such file or directory
Now the problem is that m4/sage_spkg_versions.m4 is not available and the
only way to create it seems to be running $SAGE_ROOT/bootstrap which
wants to bootstrap the whole sage-the-distro I don't need or want at all
(for one, it needs autotools which is not otherwise needed to build
sagelib, and worse it will take minutes vs. less than 1s).
Actually creating m4/sage_spkg_versions.m4 is done early and it's very
quick. Can you provide a standard simple way to create it on its own? More
importantly, could we actually support a standard way to bootstrap just
sagelib / sagemath-standard and build it on its own?
I don't think inventing workarounds to avoid using autotools is very useful
way to spend our time :-(
… —
Reply to this email directly, view it on GitHub
<#35867 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJXYHDR7SG3BOJUGCSKBLDXP732PANCNFSM6AAAAAAZ2ACTPA>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
This has nothing to do with autotools, which is not used or needed to build sagemath-standard. This PR broke the bootstrap script in What is the point of modularization if we don't support the most basic split, namely at the boundary between sage the library and distribution packages. |
No alternative? Why, you run the main ./bootstrap, if you must, or use pre-built configure spkg. I don't think modularisation at the moment means that parts of the source tree become independent on each other - it's still one tree. |
By design, the various source trees become self-contained after running |
Yes, I think some refactoring of the top-level |
Since there is a E.g. |
No, I definitely want to keep the bootstrap phase separate from the build system of the Sage distribution. |
Yes, I had the problem after the merge and I had myself to blame because I positively reviewed it. What really kills our old non-autotools way of boostraping sagemath-standard is that two generated .m4 files are missing without running the top bootstrap. But, and I want to stress that out, this is a problem only if you build from the dev branch - mostly via cloning. For stable releases, I build from the tarballs on pypi which are already bootstrapped. While it is annoying and non-minimalistic (and I tried to extract a minimum process for a few hours but it always ended broken in strange way) I accepted that running autoconf for something I pull from git is acceptable. I would need to do it for any autotooled package I pull from git out there. Of course it is weird for what is supposed to be python package. |
I also still do not run configure for people who wonder. While my attempt to generate only |
📚 Description
This makes the
pkgs/*/setup.cfg.m4
andpkgs/*/pyproject.toml.m4
files less scary and less repetitive.Split out from:
📝 Checklist
⌛ Dependencies