LibGAP

[vbraun]

Do not merge

This PR shows the libgap changes to the gap kernel

[fingolfin]

To fully understand how this work, one should also look at the cython code invoking libgap: https://github.com/sagemath/sage/blob/master/src/sage/libs/gap/

Then look for example at https://github.com/sagemath/sage/blob/master/src/sage/libs/gap/element.pyx and the call methods there which use libGAP_CALL_1ARGS etc. to directly invoke GAP functions.

[dimpase]

there is also https://github.com/sagemath/sage/blob/master/src/sage/libs/gap/test/main.c
showing how to call libGAP from C, although perhaps this needs to be expanded to show more techniques.

[dimpase]

The intrusive changes in fc14c8a are very minimal, we are basically talking about 20-30 lines added, and more removed. I'd be happy to make them nicely ifdf'ed if it comes to this. I think it's not bigger than support for some exotic OSs...

The bigger issue is the build system; we do have a mechanism to build the library using libtool, that uses the full autotools toolchain, see #504
Indeed before the latter is resolved, we cannot progress here.

[ChrisJefferson]

One minor issue in fc14c8a, files starting 'c_' are auto-generated, so changes to these files should be made to the compiler, and then the files regenerated.

[dimpase]

@ChrisJefferson - perhaps these changes to c_* files can be avoided all together (as all they do, they change a directory in an include statement).

Anyway - we can also think of making libGAP a package or another kind of add-on, with only common code in fc14c8a, and the rest, including the libGAP build system, being in a package/add-on. This way, the only intrusive change would be fc14c8a, and the rest, including libGAP's build system, would be living outside of GAP source tree, say, in pkg/libgap/.

[markuspf]

The commits have been ported to #1205, so I'll close this. Work continues on #1205.