#21116: Improve Sage's top-level 'configure'
-------------------------------------------------+-------------------------
Reporter: leif | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: sage-7.4
Component: build: configure | Resolution:
Keywords: require check system python | Merged in:
Xcode version |
Authors: | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: #21102 | Stopgaps:
-------------------------------------------------+-------------------------
Old description:
> There are a couple of things which can (and should) be improved:
>
> * `configure` doesn't contain any check for `python` (and its version),
> despite Sage meanwhile requiring a ''system'' python to build (until one
> of Sage's python packages has been built). This is a critical defect on
> its own, but as we've been living with that since Sage 6.7 IIRC, I
> haven't made this issue a blocker. (`sage-download-file` or `sage-
> uncompress-spkg` simply ''won't run'' if there's ''not any'' `python` in
> the PATH, but we cannot be sure they'll work properly with some random
> version.)
>
> * The checks for Xcode on Darwin (MacOS X) are presumably outdated, and
> `configure` eventually only gives warnings or hints. (We should probably
> also check or deduce whether Xcode's default assembler is still Apple's
> ancient fork of the GNU assembler, which has major deficiencies, and
> install a wrapper script `$SAGE_LOCAL/bin/as` which invokes LLVM's more
> recent assembler in that case. Then the GCC package won't have to deal
> with that, which it currently doesn't anyway, potentially leading to
> build errors caused by the assembler not supporting the instructions
> Sage's GCC emits. The latter can also happen on (older) Linux distros
> when Sage's GCC gets built, though, so something not Darwin-specific
> should be added to GCC's spkg-install, too.)
>
> * The list of all Sage packages dumped near the end of `configure` lets
> any warning messages given earlier drown, so it's less likely people will
> notice them. We could collect at least important warnings in order to
> give (or repeat) them at the end (a `configure` "summary" would IMHO be
> good anyway), and/or print more than one package name per line.
>
> * ... (There are quite certainly other things which could be improved.)
New description:
There are a couple of things which can (and should) be improved:
* `configure` doesn't contain any check for `python` (and its version),
despite Sage meanwhile requiring a ''system'' python to build (until one
of Sage's python packages has been built). This is a critical defect on
its own, but as we've been living with that since Sage 6.7 IIRC, I haven't
made this issue a blocker. (`sage-download-file` or `sage-uncompress-
spkg` simply ''won't run'' if there's ''not any'' `python` in the PATH,
but we cannot be sure they'll work properly with some random version.)
* The checks for Xcode on Darwin (MacOS X) are presumably outdated, and
`configure` eventually only gives warnings or hints. (We should probably
also check or deduce whether Xcode's default assembler is still Apple's
ancient fork of the GNU assembler, which has major deficiencies, and
install a wrapper script `$SAGE_LOCAL/bin/as` which invokes LLVM's more
recent assembler in that case. Then the GCC package won't have to deal
with that, which it currently doesn't anyway, potentially leading to build
errors caused by the assembler not supporting the instructions Sage's GCC
emits. The latter can also happen on (older) Linux distros when Sage's
GCC gets built, though, so something not Darwin-specific should be added
to GCC's spkg-install, too.)
* The list of all Sage packages dumped near the end of `configure` lets
any warning messages given earlier drown, so it's less likely people will
notice them. We could collect at least important warnings in order to
give (or repeat) them at the end (a `configure` "summary" would IMHO be
good anyway), and/or print more than one package name per line.
* Exclude "dummy packages" (which are only built on a few systems) like
iconv:
{{{
#!sh
# Only build iconv on Solaris, HP-UX and Cygwin. See
# http://trac.sagemath.org/sage_trac/ticket/8567 and
# http://trac.sagemath.org/sage_trac/ticket/9603
# for details.
case "$UNAME" in
CYGWIN|HP-UX|SunOS)
...
*) # Not CYGWIN, HP-UX or SunOS (Solaris)
echo "iconv will not be installed, as we only need to build it on"
echo "Solaris, HP-UX and Cygwin, as the system's iconv will be used"
echo "on other platforms, rather than the one shipped with Sage."
echo "See:"
echo " http://trac.sagemath.org/sage_trac/ticket/8567"
echo " http://trac.sagemath.org/sage_trac/ticket/9603"
exit 0
esac
}}}
and Cephes (Cygwin-only IIRC) etc. from the build when appropriate
(i.e., set corresponding variables in the generated `Makefile` according
to the platform). We may in addition add checks for e.g. iconv instead,
where easily `need_to_install_FOO` could be set. (But then e.g. iconv's
`spkg-install` should probably get rewritten as well, to not decide on
installation of the package there [again].)
* ... (There are quite certainly other things which could be improved.)
--
Comment (by leif):
Added "dynamic" exclusion of (in most cases dummy) packages like iconv,
which we could handle just like the GCC package.
--
Ticket URL: <https://trac.sagemath.org/ticket/21116#comment:2>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.