Support for --disable-giac

[orlitzky]

Giac is a PITA to have as a dependency:

• There's no public source repository
• There's no bug tracker
• There are no release announcements, new releases just show up in some random directory...
• If you can tell what is the latest release, because there's no coherent version scheme
• No one knows what's in the new releases, breaking changes show up in what appear to be minor versions
• The tarball is manually generated and often contains random files from the author's computer
• The test suite for every version fails on almost every machine
• Recent releases contain undefined behavior that is retained intentionally even though it crashes glibcxx
• The build emits hundreds of compiler warnings
• As a result of all of this, each release requires heavy patching (i.e. time & effort) even on "boring" systems
• But now I have a new computer that is not boring, and those compiler warnings weren't kidding, because giac segfaults all over the place
• So I can't use giac any more, and if Sage has a hard dependency on it, then I can't use Sage any more either

Fortunately it looks like it won't be too hard to make giac optional in Sage:

1. Remove giac integration from GiNaC #38669
2. src/sage/features/giac.py: add new feature for the giac program #38672
3. Tweak a few tests to pass when giac is not installed #38690
4. src/sage/symbolic/integration: make libgiac integration optional #38756
5. Use the faster libgiac interface for "giac" integration #38686 (not strictly required, but it conflicts with several "needs" tags)
6. Add "needs" tags for giac and libgiac #38770
7. Replace sage.libs.giac with new optional package sagemath-giac #39376

We lose a few integration examples in the doctests when the giac algorithm is skipped in favor of sympy, but that's about it.

[parisseb]

I wonder if it's really worth replying such an attack.
For the records, there is a repository for giac source files inside geogebra git repo, changes are commented there. I do not maintain myself a repository. I copy the auto-generated tarballs when I build a binary deb package and it sets the version number. When I build a binary deb, I of course check my own regression tests (I have to make some times adjustements). I'm using glibcxx,without problems once some recent "features" are disabled (this is of course done by the configure script from giac if you don't patch it), because I do not want to modify working source code.
If you want to report a bug, you can do it on Xcas forum.

If sagemath chooses to make giac optional, it might be a problem for some sage users, not for me. There are plenty of users of giac worldwide, either from ports I maintain myself or embedded in other applications.
Bye!

[kiwifb]

Hi Parisse,
I am going to guess that you refer to this repo https://github.com/geogebra/giac which is quite different from the source tarballs we can find on your site. It has a different build system and I am not sure what we build with it. If this is your official repo, it would be nice to know how it relates to your releases.
Some of your latest source tarballs have come with arm objects and executables. Which kindly interferes with the build process because make does not know about the architecture of the object.
The compile does generate a lot (understatement) of warnings. C++ standard are moving much faster than you do. But if you accept PRs we may be able to catch up on that.
Disabling features and working source code. The end of that logic is usually not to update anything as much as possible. Which means developing in a specific, end of life, version of Linux in a Virtual Machine and exclusively distributing the application as containers produced on that machine - maybe I am too modern, virtual machine images would be safer. It means your application has now a lot in common with appliance such as dishwashers and washing machines (without IoT) - not necessarily a bad thing so long as we are clear about it.

[parisseb]

Geogebra has indeed it's own build system, but the source files and header files of giac are the same as in the giac tarball (except for the FLTK Xcas UI). The giac tarball is a unique source for the giac library and Xcas UI, that's the reason why it contains files relative to Xcas, like ARM32 firmwares port of Xcas for the Numworks calculators (Xcas can handle these calculators).
There are a lot of warnings if you enable all warnings (like unsigned vs signed integers warnings), with the default flags I don't get much warnings (a few while compiling Xcas UI source files).
If you have changes to propose, you can post them on Xcas forum (I believe you already have an account there). The best for me is a tarball with the changed files if there are many changes (I'll do the diff myself and merge within emacs), or just a diff for a small number of changes. I may have to reject some changes (or ifdef them), if they are not compatible with the many ports of giac (including all calculator ports with sometimes old compilers).
Sorry I did not understand your last paragraph.

[dimpase]

4. Add # needs giac tags everywhere else

5. Add the --disable-giac flag to ./configure

6. Figure out how to disable the building of sage.libs.giac when libgiac is not found

just changing the package type to optional enables --disable-giac.
So I'm going to do this, and then see which doctests fail, and tag them.
Should be done then :-)

[orlitzky]

For the last step (disabling sage.libs.giac), meson will help in the short term, but for sage-the-distro I think we should move the entire folder into a separate sagemath-giac package. We can have it depend on sagemath-standard rather than -categories and -objects unless someone wants to adopt Matthias's PR.