Opened 4 years ago
Last modified 4 years ago
#21480 closed enhancement
Make sagelib setup.py selfcontained, independent of SAGE_ROOT, and handle buildbase — at Version 70
Reported by:  mkoeppe  Owned by:  

Priority:  blocker  Milestone:  sage7.4 
Component:  build  Keywords:  
Cc:  felixs, jdemeyer, fbissey, embray, leif, vbraun, dimpase, jhpalmieri, vdelecroix, saraedum, slabbe, nthiery, mmezzarobba  Merged in:  
Authors:  Matthias Koeppe  Reviewers:  
Report Upstream:  N/A  Work issues:  
Branch:  u/mkoeppe/keep_src__clean_by_using___build_base_when_building_sagelib (Commits)  Commit:  e5f90659f21cc7ac1e39cdcf7974dba2ba223da5 
Dependencies:  Stopgaps: 
Description (last modified by )
This ticket changes the build process of sagelib in the following way:
src/Makefile
delegates ALL building tosrc/setup.py
src/setup.py
no longer depends on environment variables$SAGE_ROOT
,$SAGE_SRC
,$SAGE_DOC_SRC
,$SAGE_CYTHONIZED
etc. (to demonstrate this,Makefile
poisons these environment variables). It still depends on$SAGE_LOCAL
and environment variables that point below it.src/setup.py
acceptsbuild buildbase=BUILDBASE
. This is where building takes place (where subdirectoriescython_debug
,cythonized
,lib.UNAME
,temp.UNAME
are created). The default is thebuild
subdirectory (ofsrc
).src/Makefile
setsbuildbase
to thebuildsagelib
subdirectory (ofsrc
).
This ticket is meant as:
 preparation for VPATH builds of sagethedistribution (#21469)
 working towards the goal of making
sagelib
pipinstallable.
More specifically, the goal of this ticket is that only SAGE_LOCAL needs to be set when the user does 'pip install' of the sagelib. (This ticket almost achieves this, except it also needs SAGE_PKGS to be set. The hope is that #20382 or a future ticket will develop a better mechanism to communicate package information to the build.)
. . . . . . .
Some possibly useful information:
 Documentation on distutils (https://docs.python.org/2/install/), describing use of
buildbase
to do VPATH builds. pip install
keeps the source directory clean, building instead in a temporary directory, by copying the sources.pip install
also offers optionsbuild
to select a build directory, but there are some pip issues: 2060, 2053, 804 that affect this #14807 has some tricks to making VPATH builds work without copying all python source files. But it uses automake instead of setup.sh; we will not do this in our ticket.
Change History (70)
comment:1 Changed 4 years ago by
comment:2 in reply to: ↑ description ; followup: ↓ 4 Changed 4 years ago by
comment:3 Changed 4 years ago by
... and sagelib
perhaps with a version suffix.
comment:4 in reply to: ↑ 2 ; followup: ↓ 6 Changed 4 years ago by
Replying to leif:
Replying to mkoeppe:
In preparation for VPATH builds of sagethedistribution (#21469), let's keep
src/
clean by usingsetup.py buildbase=$SAGE_ROOT/var/tmp/sage/build/sagelib
Please use
buildbase=$SAGE_BUILD_DIR/sagelib
.
Yes, the plan *after* #21469 is to use the Sage builddir  not just for sagelib, but also for other packages.
*Before* #21469 is merged, I want to use $SAGE_ROOT/var/tmp/sage/build/sagelib
to match what other packages do.
comment:5 Changed 4 years ago by
 Description modified (diff)
Ah, I see what you meant, now I've found $SAGE_BUILD_DIR. Changed description accordingly.
comment:6 in reply to: ↑ 4 ; followup: ↓ 7 Changed 4 years ago by
Replying to mkoeppe:
Replying to leif:
Replying to mkoeppe:
In preparation for VPATH builds of sagethedistribution (#21469), let's keep
src/
clean by usingsetup.py buildbase=$SAGE_ROOT/var/tmp/sage/build/sagelib
Please use
buildbase=$SAGE_BUILD_DIR/sagelib
.Yes, the plan *after* #21469 is to use the Sage builddir  not just for sagelib, but also for other packages.
??? SAGE_BUILD_DIR
exists since years already... (Its default is $SAGE_ROOT/var/tmp/sage/build/
.)
*Before* #21469 is merged, I want to use
$SAGE_ROOT/var/tmp/sage/build/sagelib
to match what other packages do.
comment:7 in reply to: ↑ 6 Changed 4 years ago by
Replying to leif:
???
SAGE_BUILD_DIR
exists since years already... (Its default is$SAGE_ROOT/var/tmp/sage/build/
.)
Yes, thanks, see my other comment.
comment:8 Changed 4 years ago by
Ah ok, race condition.
comment:9 Changed 4 years ago by
By the way, help with implementing this change would be appreciated. I haven't looked at the sagelib build system at all so far.
comment:10 Changed 4 years ago by
 Branch set to u/mkoeppe/keep_src__clean_by_using___build_base_when_building_sagelib
comment:11 Changed 4 years ago by
 Commit set to e399bf41d805da7ea602daa5b554e0c7ecf2e7b5
New commits:
e399bf4  First, wishful step

comment:12 Changed 4 years ago by
 Description modified (diff)
comment:13 Changed 4 years ago by
Really sagelib$SAGE_VERSION
? Do you want to fill up everybody's hard disks with Sage build directories? Not to mention that this would require to rebuild everything whenever the Sage version changes.
comment:14 Changed 4 years ago by
 Description modified (diff)
comment:15 Changed 4 years ago by
Fine with me without $SAGE_VERSION; I was just following leif's suggestion in comment 3.
comment:16 followup: ↓ 17 Changed 4 years ago by
i understand that SAGE_BUILD_DIR is the srcdir for toplevel configure.
as long as sagelib is rooted in $(toplevel)/src, it might be less confusing to choose $SAGE_BUILD_DIR/src (not $SAGE_BUILD_DIR/sagelib) as the builddir for sagelib.
(future: replace src by sagelib, but on both ends)
i dont know exactly how the approach using setup.py will emulate VPATH builds. i think it should imitate "what automake would do", where applicable.
comment:17 in reply to: ↑ 16 Changed 4 years ago by
Replying to felixs:
i understand that SAGE_BUILD_DIR is the srcdir for toplevel configure.
No, it's $SAGE_ROOT/var/tmp/sage/build/
comment:18 Changed 4 years ago by
ok, nevermind (i meant to write "SAGE_BUILD_DIR is the *builddir* for toplevel"). that does not seem to be the case either.
still i am wondering why "src" does not (simply) translate to "src". (sure, i am slightly autotools biased).
comment:19 Changed 4 years ago by
 Commit changed from e399bf41d805da7ea602daa5b554e0c7ecf2e7b5 to a73fa065f5030c3b260c04a7e36867fd7f89362f
comment:20 Changed 4 years ago by
 Status changed from new to needs_review
Here's a first version for review. It seems to work for me.
There are still some todo items (see comments in src/Makefile
):
 I am now using
buildbase
, but setup.sh also depends onSAGE_CYTHONIZED
, defined insrc/sage/env.py
.
I think it would be better if
setup.sh
instead inferred that location from the buildbase that was passed to it.
However, setup.sh already does a lot of stuff depending on
SAGE_CYTHONIZED
beforedistutils.core.setup
is even called. Can this be fixed?
I think I could use some help from the Python experts in the cc list of this ticket on this.
sage/libs/pari/auto_gen.pxi
andsage/ext/interpreters/__init__.py
still need to be taken care of in preparation for the VPATH build.
comment:21 Changed 4 years ago by
 Description modified (diff)
comment:22 followups: ↓ 26 ↓ 28 Changed 4 years ago by
 Status changed from needs_review to needs_work
Thinking about it more, I disagree with building in $SAGE_BUILD_DIR/sagelib
by default.
$SAGE_LOCAL
(which contains $SAGE_BUILD_DIR
) is meant as install directory, not as build directory.
Let's keep $SAGE_LOCAL
to be exactly the install directory and nothing else (*).
I do agree with making the build directory configurable for VPATH
builds. For typical packages however, if you do not do a VPATH
build, the build directory is the same as the source directory. Sage should follow the same model. This means that the build directory should be $SAGE_SRC
by default.
(*) One could argue that
$SAGE_BUILD_DIR
is currently used as build directory for packages. That is true, but they are only used temporarily, they are not meant to actually store stuff. So this isn't so bad.
comment:23 followups: ↓ 24 ↓ 27 Changed 4 years ago by
Let's keep $SAGE_LOCAL to be exactly the install directory and nothing else (*).
this is part of the problem with the current "build system". SAGE_LOCAL is *not* the install directory. it is where stuff ends up during the build process.
outside sage, an install directory is typically what you pass to prefix, and where stuff is put into by "make install". you do that (if you are a sysadmin), after assuring that "make check" passes...
yes i know why SAGE_LOCAL exists, but it should be clear that it's not necessary and that it only has "evolved" that way. having simplified things in the past, now it is falling on your feet.
note how i tried to fix/work\ around that in my attempt to autotoolize sage (both the library and the distribution)... my point: the best approach will be to *not use SAGE_LOCAL* at all. here's the chance to cleanup sagelib, as a start.
that said: keep up the good and interesting work @mkoeppe. i hope i will have some more time later this year ...
comment:24 in reply to: ↑ 23 Changed 4 years ago by
Replying to felixs:
this is part of the problem with the current "build system". SAGE_LOCAL is *not* the install directory.
Why do you think that $SAGE_LOCAL
is not the install directory? It is the directory where everything is installed, which by definition makes it the install directory. The fact that Sage does not (yet) support prefix
doesn't change this fact.
the best approach will be to *not use SAGE_LOCAL* at all.
I like to know why you think that.
that said: keep up the good and interesting work @mkoeppe. i hope i will have some more time later this year ...
To be clear: I didn't say that this branch needs to be thrown out. I am just saying: keep the build directory configurable but keep the default what it currently is.
comment:25 followup: ↓ 29 Changed 4 years ago by
Why do you think that $SAGE_LOCAL is not the install directory?
you wrote it. "prefix" is not implemented/supported. (but it should be). there's no way to really "install" stuff in the usual sense. e.g., there is no way to *install stuff after make check has passed*. (i don't know if toplevel make check is currently implemented at all, just a thought).
where everything is installed, which by definition makes it the install directory
actually nothing gets installed. what is done is mostly overhead. working around the fact that some packages don't work right after the build alone. when i was done with the "package content lists" for spkginstall, i noticed that it was a huge waste of time... don't repeat that, better just skip the "install" step.
I like to know why you think that [SAGE_LOCAL should not be used].
every instance/use of SAGE_LOCAL breaks sagelib on (lets call it) foreign distros a bit. that's not helpful. it will as well interfere with any attempt on rewriting sagethedistribution (be it autotools based, or pip or ebuild). the autotools approach (not a necessary step, but an example) provides a transition path to anything...
sagethedistribution is a platform for sage (core) development. no more, no less. other platforms will come and go. what is needed is sagelib without the dependency on this (and on SAGE_LOCAL). why: because developers should be able to use sagelib and develop sage extensions on *their own platforms*, with *their own* tools and *their own* review policies.
so: please embrace contributions that reduce the use of SAGE_LOCAL.
(yes, its getting offtopic. but i hope, this answers the question.)
comment:26 in reply to: ↑ 22 Changed 4 years ago by
Replying to jdemeyer:
Thinking about it more, I disagree with building in
$SAGE_BUILD_DIR/sagelib
by default.
$SAGE_LOCAL
(which contains$SAGE_BUILD_DIR
) is meant as install directory, not as build directory.Let's keep
$SAGE_LOCAL
to be exactly the install directory and nothing else (*).
I agree with you; see #21479.
comment:27 in reply to: ↑ 23 Changed 4 years ago by
Replying to felixs:
outside sage, an install directory is typically what you pass to prefix, and where stuff is put into by "make install". you do that (if you are a sysadmin), after assuring that "make check" passes...
See #21479 for a discussion of prefix
and make
vs. make install
.
But let's keep the discussion of the present ticket focused on the task at hand.
comment:28 in reply to: ↑ 22 Changed 4 years ago by
Replying to jdemeyer:
I do agree with making the build directory configurable for
VPATH
builds. For typical packages however, if you do not do aVPATH
build, the build directory is the same as the source directory. Sage should follow the same model. This means that the build directory should be$SAGE_SRC
by default.
I agree on this as well. #21469 (VPATH for distro) will do that.
In this ticket, I first want to make the buildbase
work. In particular, get rid of SAGE_CYTHONIZED.
This also works towards the eventual goal of making 'sagelib' pipinstallable.
The actual location used is a detail that will be easy to change later.
(*) One could argue that
$SAGE_BUILD_DIR
is currently used as build directory for packages. That is true, but they are only used temporarily, they are not meant to actually store stuff. So this isn't so bad.
Yes, the current patch follows this practice. But this is temporary until #21469 is done.
comment:29 in reply to: ↑ 25 ; followup: ↓ 30 Changed 4 years ago by
Replying to felixs:
Why do you think that $SAGE_LOCAL is not the install directory?
you wrote it. "prefix" is not implemented/supported.
The fact that the installation process does not implement ./configure prefix
does not mean that it's not an installation process...
every instance/use of SAGE_LOCAL breaks sagelib
But why?
Of course, it's all a matter of definition. I consider the process of copying files to $SAGE_LOCAL
an "installation" and you do not (for reasons which are still unclear to me). I think things will become much simpler for you if you accept the fact that $SAGE_LOCAL
is the installation directory and that copying files to $SAGE_LOCAL
is an installation.
but i hope, this answers the question
I absolutely does not. You are just saying "it breaks stuff" but not explaining why.
comment:30 in reply to: ↑ 29 ; followup: ↓ 32 Changed 4 years ago by
Replying to jdemeyer:
Replying to felixs:
[...]
but i hope, this answers the question
I absolutely does not. You are just saying "it breaks stuff" but not explaining why.
One reason why is that in many deployment scenarios you will want to test what you have built before installing it. And Sage does not support this.
comment:31 followup: ↓ 34 Changed 4 years ago by
indeed. in "build""check""install" there is not much room for definitions of "build" and "install".
this is drifting towards the question of whether or not sage should stick to common practices and terminology. you know i think it should.
apologies for being offtopic again, this may be more related to #15105  there is no ticket for just "practices and terminology".
comment:32 in reply to: ↑ 30 ; followup: ↓ 37 Changed 4 years ago by
Replying to dimpase:
One reason why is that in many deployment scenarios you will want to test what you have built before installing it. And Sage does not support this.
How does this relate to the existence of $SAGE_LOCAL
?
comment:33 Changed 4 years ago by
 Commit changed from a73fa065f5030c3b260c04a7e36867fd7f89362f to a854831e3274b69eadc52eb4642b8c0bd221a391
Branch pushed to git repo; I updated commit sha1. New commits:
a854831  Put setup.sh in charge of all sagelib building

comment:34 in reply to: ↑ 31 Changed 4 years ago by
Replying to felixs:
this is drifting towards the question of whether or not sage should stick to common practices and terminology. you know i think it should.
If those "common" practices and terminology make sense, of course it should.
Anyway, I am completely not following what you are trying to say. I feel that you are always wandering around my questions instead of answering them.
comment:35 Changed 4 years ago by
I have created #21495 as a place for such discussions.
comment:36 Changed 4 years ago by
 Description modified (diff)
comment:37 in reply to: ↑ 32 ; followup: ↓ 38 Changed 4 years ago by
Replying to jdemeyer:
Replying to dimpase:
One reason why is that in many deployment scenarios you will want to test what you have built before installing it. And Sage does not support this.
How does this relate to the existence of
$SAGE_LOCAL
?
$SAGE_LOCAL
is fine as long as you can also install things from there somewhere else. Currently you cannot do this in a proper way (yes, you can certainly create symbolic links etc, but this is often not enough).
comment:38 in reply to: ↑ 37 Changed 4 years ago by
Replying to dimpase:
$SAGE_LOCAL
is fine as long as you can also install things from there somewhere else. Currently you cannot do this in a proper way
Of course you can:
$ cd $package_source $ sage sh $ ./configure prefix="$SAGE_LOCAL" $ make install
I have done this many times as first step of testing a new package or a package upgrade.
comment:39 Changed 4 years ago by
If I understand Dima correctly, he wants to install "from" $SAGE_LOCAL, not "to" $SAGE_LOCAL.
But really this discussion should go to #21495. Thanks!
comment:40 Changed 4 years ago by
 Commit changed from a854831e3274b69eadc52eb4642b8c0bd221a391 to 1a027d5d535f4dbf7314479e8c6905ad8af34bca
Branch pushed to git repo; I updated commit sha1. New commits:
1a027d5  Have setup.sh derive SAGE_CYTHONIZED from buildbase

comment:41 Changed 4 years ago by
 Status changed from needs_work to needs_review
Jeroen, how does this look to you now? (I haven't changed $SAGE_BUILD_DIR yet, but will in a moment.)
comment:42 Changed 4 years ago by
 Commit changed from 1a027d5d535f4dbf7314479e8c6905ad8af34bca to f6555cea1f1695c99a9011ba13bd64c6995d17fc
Branch pushed to git repo; I updated commit sha1. New commits:
f6555ce  Fix last change  handle buildbase earlier

comment:43 Changed 4 years ago by
 Commit changed from f6555cea1f1695c99a9011ba13bd64c6995d17fc to d829eb435729cf3280a5206d005bffef8e1dfd52
comment:44 Changed 4 years ago by
 Description modified (diff)
 Summary changed from Keep src/ clean by using buildbase when building sagelib to Make sagelib setup.sh selfcontained, independent of SAGE_ROOT, and handle buildbase
I've changed the description of this ticket, as it has changed its focus. Ready for review.
comment:45 Changed 4 years ago by
 Commit changed from d829eb435729cf3280a5206d005bffef8e1dfd52 to ef0919c1bc7d7182d79ae725c97ce057b8336d34
comment:46 Changed 4 years ago by
 Commit changed from ef0919c1bc7d7182d79ae725c97ce057b8336d34 to bd670afd3c7510113b686a9b1545873bda5165dc
comment:47 Changed 4 years ago by
 Commit changed from bd670afd3c7510113b686a9b1545873bda5165dc to 751bd0fbde10aa234867122308c7bb76673cbaba
Branch pushed to git repo; I updated commit sha1. New commits:
751bd0f  Reword TODO item

comment:48 Changed 4 years ago by
 Cc jhpalmieri vdelecroix saraedum slabbe nthiery added
comment:49 Changed 4 years ago by
 Description modified (diff)
 Summary changed from Make sagelib setup.sh selfcontained, independent of SAGE_ROOT, and handle buildbase to Make sagelib setup.py selfcontained, independent of SAGE_ROOT, and handle buildbase
comment:50 Changed 4 years ago by
 Cc mmezzarobba added
comment:51 followup: ↓ 66 Changed 4 years ago by
I would prefer to do this ticket after #21479 because there might be nontrivial interactions.
comment:52 Changed 4 years ago by
 Status changed from needs_review to needs_work
Also in the code setup.sh
> setup.py
comment:53 Changed 4 years ago by
Regarding
(cd $(srcdir) && export SAGE_ROOT=/doesnotexist SAGE_SRC=/doesnotexist SAGE_SRC_ROOT=/doesnotexist SAGE_DOC_SRC=/doesnotexist SAGE_SCRIPTS_DIR=/doesnotexist SAGE_BUILD_DIR=/doesnotexist SAGE_CYTHONIZED=/doesnotexist SAGE_PKGS=$(abs_top_srcdir)/build/pkgs && python u setup.py build buildbase=$(abs_builddir)/buildsagelib install)
Did you know that make
supports backslashcontinued lines? :)
comment:54 followup: ↓ 57 Changed 4 years ago by
For backwards compatibility, can we please keep the name build
instead of changing it to buildsagelib
?
comment:55 followup: ↓ 58 Changed 4 years ago by
What is the rationale for splitting the Makefile
in two (Makefile
and generate_py_source.mk
)? That seems like additional complication without reason.
In any case, using make
is wrong. You need to use os.environ["MAKE"]
.
comment:56 Changed 4 years ago by
 Commit changed from 751bd0fbde10aa234867122308c7bb76673cbaba to 3a8cc0e1bc0c09142275a7ea6b03775e83d73e28
Branch pushed to git repo; I updated commit sha1. New commits:
3a8cc0e  Fix typo in comment

comment:57 in reply to: ↑ 54 ; followup: ↓ 62 Changed 4 years ago by
Replying to jdemeyer:
For backwards compatibility, can we please keep the name
build
instead of changing it tobuildsagelib
?
If I keep the default, it's hard to demonstrate that "buildbase" actually works.
Moreover, there are too many things already called "build"  better be specific.
comment:58 in reply to: ↑ 55 ; followup: ↓ 64 Changed 4 years ago by
Replying to jdemeyer:
What is the rationale for splitting the
Makefile
in two (Makefile
andgenerate_py_source.mk
)? That seems like additional complication without reason.
setup.sh
needs to be in charge of building everything, if sagelib is to become a wellbehaved Python package.
comment:59 followup: ↓ 63 Changed 4 years ago by
generate_py_source.mk
could certainly be implemented in pure Python and could become a part of setup.py
. But I don't want to work on this.
comment:60 Changed 4 years ago by
 Commit changed from 3a8cc0e1bc0c09142275a7ea6b03775e83d73e28 to 0dd9c50021302e4d8cfc6f95e8bbdea232c60b97
Branch pushed to git repo; I updated commit sha1. New commits:
0dd9c50  Respect environment variable MAKE

comment:61 Changed 4 years ago by
 Commit changed from 0dd9c50021302e4d8cfc6f95e8bbdea232c60b97 to 17f90d8d1e8b35f9ae08bb98bb876083ba968824
Branch pushed to git repo; I updated commit sha1. New commits:
17f90d8  beautification

comment:62 in reply to: ↑ 57 Changed 4 years ago by
Replying to mkoeppe:
Replying to jdemeyer:
For backwards compatibility, can we please keep the name
build
instead of changing it tobuildsagelib
?If I keep the default, it's hard to demonstrate that "buildbase" actually works.
Well, it's easy for the reviewer to test a different value of buildbase
.
Moreover, there are too many things already called "build"  better be specific.
But src/build
is pretty clear: it is the build directory corresponding to src
, which is the Sage library. I don't like to change it just for the sake of changing it.
comment:63 in reply to: ↑ 59 Changed 4 years ago by
Replying to mkoeppe:
generate_py_source.mk
could certainly be implemented in pure Python and could become a part ofsetup.py
That doesn't answer my question. Why do you not keep this in src/Makefile
?
comment:64 in reply to: ↑ 58 Changed 4 years ago by
Replying to mkoeppe:
setup.sh
needs to be in charge of building everything, if sagelib is to become a wellbehaved Python package.
Sorry, I didn't see this comment. Okay, that makes sense but it wasn't clear to me,
I guess you should add some comments to src/Makefile
to explain this better than just
## All sagelibbuilding is done by setup.py. ## DON'T ADD ADDITIONAL STEPS TO THIS MAKEFILE.
comment:65 Changed 4 years ago by
 Commit changed from 17f90d8d1e8b35f9ae08bb98bb876083ba968824 to e5f90659f21cc7ac1e39cdcf7974dba2ba223da5
Branch pushed to git repo; I updated commit sha1. New commits:
e5f9065  More comments

comment:66 in reply to: ↑ 51 Changed 4 years ago by
comment:67 Changed 4 years ago by
OK, I'll have #21479 ready in a few days.
comment:68 Changed 4 years ago by
I just tested this with #21501. It mostly works but there are these two doctest failures:
sage t src/sage_setup/find.py ********************************************************************** File "src/sage_setup/find.py", line 107, in sage_setup.find.find_extra_files Failed example: find_extra_files(["sage.modular.arithgroup"], SAGE_SRC, SAGE_CYTHONIZED, ".") Expected: [('./sage/modular/arithgroup', ['.../src/sage/modular/arithgroup/farey.pxd', ...farey_symbol.h...])] Got: [('./sage/modular/arithgroup', ['/usr/local/src/sageconfig/src/sage/modular/arithgroup/farey.pxd'])] ********************************************************************** File "src/sage_setup/clean.py", line 87, in sage_setup.clean._find_stale_files Failed example: for f in stale_iter: if f.endswith(skip_extensions): continue print('Found stale file: ' + f) Expected nothing Got: Found stale file: sage/stats/distributions/dgs_gauss.h Found stale file: sage/libs/lcalc/lcalc_sage.h Found stale file: sage/geometry/triangulation/data.h Found stale file: sage/misc/cython_metaclass.h Found stale file: sage/rings/finite_rings/stdint.h Found stale file: sage/stats/distributions/dgs_misc.h Found stale file: sage/misc/darwin_memory_usage.h Found stale file: sage/stats/distributions/dgs.h Found stale file: sage/ext/python_debug.h Found stale file: sage/libs/eclsig.h Found stale file: sage/ext/solaris_fixes.h Found stale file: sage/ext/pyx_visit.h Found stale file: sage/matroids/minorfix.h Found stale file: sage/modular/arithgroup/farey_symbol.h Found stale file: sage/ext/mod_int.h Found stale file: sage/combinat/matrices/dancing_links_c.h Found stale file: sage/ext/interpreters/wrapper_rr.h Found stale file: sage/symbolic/ginac_wrap.h Found stale file: sage/ext/interpreters/wrapper_cdf.h Found stale file: sage/ext/interpreters/wrapper_el.h Found stale file: sage/groups/perm_gps/partn_ref2/refinement_generic.h Found stale file: sage/libs/polybori/pb_wrap.h Found stale file: sage/sat/solvers/cryptominisat/solverconf_helper.h Found stale file: sage/combinat/partitions_c.h Found stale file: sage/ext/ccobject.h Found stale file: sage/geometry/triangulation/triangulations.h Found stale file: sage/libs/ntl/ntlwrap.h Found stale file: sage/stats/distributions/dgs_bern.h Found stale file: sage/sat/solvers/cryptominisat/cryptominisat_helper.h Found stale file: sage/libs/pari/parisage.h Found stale file: sage/geometry/triangulation/functions.h **********************************************************************
comment:69 Changed 4 years ago by
One thing I don't like about the approach of this ticket is that SAGE_CYTHONIZED
is set by the value of buildbase
. I would much rather have it the other way around: that some environment variable is set by configure
which is then used to define the value for buildbase
and for the environment variable SAGE_CYTHONIZED
.
This would be more analogous to #21501 where I want to set $SAGE_LOCAL
just once and then derive everything from that.
comment:70 Changed 4 years ago by
 Description modified (diff)
Am interesting issue is that technically
cython_debug
has to be installed somewhere (preferably somewhere standard) to be accessible at runtime separately from the source.I do something in sageongentoo but that's not really satisfactory.