Steps to ease packaging libgap

[nthiery]

The following steps would make it easier for packagers (e.g. Debian, ...) to include libgap, typically in a gap-devel package.

• Make rule to install gap headers in /include/gap/
• Somehow update gap headers to #include <gap/...> rather than <src/ ...>
• Resolve/work around the GAP <-> Python conflict for T_INT, T_BOOL, T_CHAR, T_STRING?
  We currently work around it in Sage by forcing the inclusion of the relevant Python header before the GAP header.
• Not have to rerun configure and make clean between compiling gap and libgap; this will be taken care of automatically when the gap binary will be built on top of libgap.
• GAP by default is compiled against gmp, while libGAP in Sage is compiled against MPIR. How bad is that?

cc @fingolfin

[fingolfin]

Some comments and links (feel free to comment on the linked issues!)

• Install GAP headers: this is part of Implement a sane, working "make install" fingolfin/gap#44
• On src/foo.h vs gap/foo.h see Include paths <src/foo.h> not appropriate for installed library? fingolfin/gap#89
• On T_INT conflict: @nthiery for now implemented a functional workaround. I also got rid of a lot of T_INT uses in the GAP kernel, and determined that no packages in the distribution reference T_INT. So we could rename it to e.g. T_INTIMM for a slightly better workaround. (Of course it could also go to GAP_T_INT, but that sticks out like a sore thumb; we could also rename all T_FOO values to GAP_T_FOO, but I wonder if that really is so useful, considering that tons of other GAP symbols may result in clashes with other projects...
  Unfortunately, C++ namespaces will not help, as the preprocessor does not know or care about them; so both GAP and Python would need to change from a #define to e.g. an enum for this to help (I actually would like that but I am not sure if it is realistically possible to get Python to make such a change)
• In the future, it should indeed be possible to build libgap and gap in parallel. We'll work on that.

[jdemeyer]

In the future, it should indeed be possible to build libgap and gap in parallel.

I don't quite understand what you mean with "in parallel". I think what @nthiery meant was that GAP should simply be a command-line application linked against libGAP. So GAP would implement the Read-Eval-Print-Loop using libGAP to evaluate the GAP code.

This is also the model used by PARI/GP, where PARI is the library and GP is a command-line application linked against PARI.

[nthiery]

I believe that's also what @fingolfin has in mind.

[fingolfin]

Indeed. "In the future" here indicates "this is currently not possible, but we'll work on making it possible".