-
-
Notifications
You must be signed in to change notification settings - Fork 481
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
Don't use make for autogenerated modules in sagelib #21613
Comments
comment:2
From the description:
Could you make a ticket on top of #21480 (and probably #21604) that moves the invocation of |
comment:3
Replying to @mkoeppe:
That's not so easy, for the same reason that #21600 is not so easy. We need to pass the list of Python packages, Cython extensions and data_files to |
comment:4
Again, the title of this ticket does not match the long description. Do you want to get rid of |
comment:5
I think it does match but I'm not sure what's unclear. |
This comment has been minimized.
This comment has been minimized.
comment:6
I feel like this is not hard, having done it many times before. There's nothing particularly special about sage either in any of these regards. |
Author: Erik Bray |
Commit: |
comment:9
Determine directly in the Python code whether or not autogenerated sources need to be built, without requiring a makefile or anything. I think this is simple and clear to anyone who looks at the code. If in the future we want more full make-like capabilities I've got something in the works for that, but it seems unlikely that anything more complicated than this is needed any time soon. Last 10 new commits:
|
Branch: u/embray/ticket-21613 |
comment:10
This looks nice and easy to understand. |
comment:12
Indeed. I just noticed that MANIFEST.in contains MANIFEST.in, which it really doesn't need to do :) |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:15
This needs rebasing on top of current develop and possibly some work there.
(this is from #21480). |
comment:53
I don't really think that belongs here in the first place but okay. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
New commits:
|
comment:56
In #21820, some paths changed. In particular, the generated files are now in |
Changed dependencies from #21820 to none |
comment:57
Yes, I see that now. Incidentally building still worked, it just built the files in the wrong place. |
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:61
Looks good to me; though the description of this ticket could use updating. |
Changed branch from u/embray/ticket-21613 to |
comment:63
Some changes made here are not py3 compatible, and need to be corrected to be so. try:
|
Changed commit from |
comment:64
proposal fix in #22044 |
comment:65
Breakage: #22094. |
Currently there is a
src/Makefile
at the root of the sagelib sources that is required to be invoked in order to make sure the packages insage_setup.autogen
and that autogenerated sources are placed in the sage sources before running itssetup.py install
.#21480 inverts things somewhat by removing the old Makefile (really making it into a no-op for now), but pulling out the
sage_setup.autogen
stuff into a separate makefile that is still invoked by callingmake
from thesetup.py
(in the current version of that ticket it is even called unconditionally). This is pretty non-standard.The appropriate time to do this would be either just before the
build_py
command is run, or thebuild_ext
command is run (in the case of autogenerated sources for extension modules).In the current cases we have its very trivial to check whether or not any of the sources actually need to be regenerated, and this is a pretty normal thing to do in some other complex Python packages. For example, the package responsible for generating the source files (e.g. currently the
sage_setup.autogen
sub-packages) simply needs to be responsible for knowing what its own source code files are, and knowing the paths for its generated sources--then just compare modtimes. Invoking make is not required at all.One can do even better by having one of the generated files be a hash of the source files, and compare the hashes instead (this avoids rebuilds when switching between git branches but where the files didn't otherwise change).
CC: @mkoeppe @jdemeyer
Component: build
Author: Erik Bray
Branch:
34ca46c
Reviewer: Matthias Koeppe
Issue created by migration from https://trac.sagemath.org/ticket/21613
The text was updated successfully, but these errors were encountered: