Enable more packages in the GAP distro CI tests

[lgoettgens]

#1067 added CI tests for all packages in the GAP package distribution (ref. #1065).
However, many packages are still excluded due to various reasons.

The current list and some notes on why they are excluded can be found in https://github.com/oscar-system/GAP.jl/blob/master/.github/workflows/CI-distro.yml#L63-L86.

Missing JLL

• semigroups -- resolved by Add precompiled binaries for the "semigroups" GAP package #1125

Missing Software: GAP

More specifically, it needs a working gap executable in the path, e.g. something created by GAP.create_gap_sh() or a variant thereof.

• examplesforhomalg
• localizeringforhomalg
• ringsforhomalg

Missing Software: Pari

In Oscar we replace the code in alnuth which calls PARI by calls into OSCAR, so we don't want to install PARI with GAP.jl.

However, we could install it just for the CI job on GAP.jl testing GAP packages. Done in PR #1124

• alnuth
• guarana
• polenta
• radiroot

Missing Software: polymake

For details on getting polymake to work see my comment below.

• polymaking
• hap
• hapcryst

Needs changes in the GAP package

• autodoc
  • tries and fails to build its own documentation, inside the (partially write protected) artifacts dir
  • one could patch AutoDoc upstream so that a future release builds the documentation in a tmp dir instead? See Change test suite to not write into package directory / allow building manuals "out of tree" gap-packages/AutoDoc#281
• normalizinterface
  • NormalizInterface currently bundles Normaliz 3.9.3 and its test suite is tuned to that, but our JLL builds it against normaliz_jll which has 3.10.2
  • so NormalizInterface should be updated to bundle and use that version of Normaliz.
• polycyclic
  • test suite currently broken and also disabled by GAP package distribution

Hopeless or irrelevant

• example
  • no JLL, on purpose, as the kernel extension is just a uselesss toy example
  • it is OK to not test this package
• itc
  • requires xgap and as such is out of scope
• xgap
  • requires X Window and needs to start a gap executable in a special mode
  • getting this to work would be a major effort with very few if any people benefiting
  • so we won't package this

Other

• atlasrep
  • random segfaults during testing
• guava
  • random test failures in guava-3.19/tst/guava.tst:649: Syntax error: expression expected in /tmp/gaptempfile.i8tlxS:1 GUAVA_TEMP_VAR := � &
• help
  • test failure in HeLP-4.0/tst/yes_4ti2.tst:39
• io
  • segfaults, most likely due to child process handling
  • see issue Patch GAP_pkg_io_jll to disable a bunch of "dangerous" functions like IO_fork #1107
• packagemanager
  • test suite has various failures when run in our context
• profiling
  • segfaults during testing

[fingolfin]

To get the GAP package 'polymaking' working (and hence hap, hapcryst) we need access to polymake. This has a JLL and we could use BinaryWrappers.jl. However, this is complicated by the fact that the polymake executable is just a perl script, which begins with #!/usr/bin/env perl. Hence the following doesn't work:

GAP.Globals.POLYMAKE_COMMAND = GapObj(joinpath(polymake_binpath, "polymake"))

... as this ends up trying to use a system install version of Perl (which may not even exist). So we need to use the perl from our Perl_jll. E.g this works to launch polymake:

import Oscar.Polymake: polymake_jll
run(addenv(`$(polymake_jll.Perl_jll.perl()) $(polymake_jll.polymake_path)`,
           polymake_jll.JLLWrappers.LIBPATH_env=>polymake_jll.LIBPATH[]))

But GAP needs a path to an executable and we can't tell it to set environment variables. So we either need to generate our own wrapper shell script; or someone needs to generalize BinaryWrappers to teach it to generate wrappers that set up environment variables based on one JLL (here: polymake_jll), but executes something from another (here: perl from Perl_jll).

Since nobody has request anything using polymaking right now, we'll leave it at that for the moment (ideally any code using it would be rewritten to instead use our Julia-GAP and Julia-polymake bridges instead anyway).