Add a `gap-config` script

[fingolfin]

trafficstars

A gap-config script would allow the user (and more importantly: the build systems of GAP packages) to query the CFLAGS, LDFLAGS, etc. that were used to build GAP, as well as various other options. Currently this is handled by squeezing all this data into sysinfo.gap -- but that file is static, and it is currently read / "included" into both shell scripts and Makefiles, so we are very limited in what we can put into it... If we instead parse and read the output of a tool, we are much more flexible. One reason why a static file is not enough is the usecase of a relocatable GAP installation, which can be installed anywhere; right now one can kinda do this by regenerating sysinfo.gap as needed, but that only works if one has an opportunity to do so before something accesses that file.

(In addition to a gap-config script one could also as add a gap.pc pkg-config file; but no GAP package is able to use such a file right now, and adding support for parsing them (for those packages which don't use autoconf, which are quite a few) is considerably more work, with no immediate benefit to us. (Yes, pkg-config could be nice to specify further dependency, e.g. that of the float package on mpfr and more; but again, for this to be useful, the build systems of our packages would have to be able to deal with all that, which is not a given. As such, while I wouldn't mind pkg-config support, it's a much lower priority for me).

The gap-config script would complement or replace sysinfo.gap, and also likely gac would use it / share code with it.

Of courrse these files are only useful if scripts can find them, which typically would mean that the user has to "install" GAP first, say via a to-be-implemented "make install". But once that is done, it would allow the build systems of packages to automatically "discover" the GAP installation and all relevant flags. In particular, packages which also use GMP or readline could use this to ensure they link against the exact same GMP / readline as GAP did, which is quite important.

To support multiple "configs" (32bit, 64bit, HPC-GAP...) one would ensure that each GAP build (i.e. including out-of-tree builds) gets its own gap-config (just like they all have their own sysinfo.gap); then to build a package, just point it at the desired gap-config resp. the directory containing the desired gap-config.

[fingolfin]

Some notes:

• pkg-config format is documented on various places:
  • http://people.freedesktop.org/~dbn/pkg-config-guide.html
  • https://autotools.io/pkgconfig/index.html
• A project which generates both a FOO-config and a FOO.pc is e.g. libpng; it does so using both autotools and cmake
  • https://sourceforge.net/p/libpng/code/ci/libpng16/tree/libpng-config.in
  • https://sourceforge.net/p/libpng/code/ci/libpng16/tree/libpng.pc.in
  • https://sourceforge.net/p/libpng/code/ci/libpng16/tree/CMakeLists.txt
  • https://sourceforge.net/p/libpng/code/ci/libpng16/tree/configure.ac
• note that libpng-config is a bit "non-standard" (but then, all "FOO-config" are non-standard, which is why pkg-config was created). Anyway, there are plenty other examples out there.

[fingolfin]

The gap-config script would likely have the usual switches like --ldflags, --cppflags etc., but also a couple specific ones (reflecting what is in sysinfo.gap); and I would suggest we also have a --sysinfo switch which essentially prints out the same thing as we have in sysinfo.gap right now. That would make it rather easy for package build systems to adapt to it: In shell scripts, replace . "$GAPPATH/sysinfo.gap" by something roughly like this:

if [[ -x "$GAPPATH/gap-config" ]]; then
  eval $("$GAPPATH/gap-config" --sysinfo) 
else
  . "$GAPPATH/sysinfo.gap"
fi

And similar for Makefiles. I.e. we use gap-config if present and else fall back to sysinfo.gap.

The great advantage of doing it this way is that it is dead easy for us to make the switch. We can then worry about more fancy options for sysinfo.gap later on.

[dimpase]

This seems to come from pre-libgap times.

pkg-config's .pc file has an advantage of being more or less standard nowadays (e.g. GMP has it, MPFR has it), and it has reasonable autoconf support (macros for checking versions, getting values of variables, etc)

[antonio-rojas]

This is particularly important now that libgap's headers require a garbage collector to be specified. Reading GAP_CPPFLAGS from sysinfo.gap might be enough for gap packages, but a more standard solution is needed for other third party software (such as Sagemath) that wants to use libgap.

[fingolfin]

This is particularly important now that libgap's headers require a garbage collector to be specified.

That's not intentional, please open a bug report, then we can habe this fixed in 4.12.1 (it should be easy).

Reading GAP_CPPFLAGS from sysinfo.gap might be enough for gap packages, but a more standard solution is needed for other third party software (such as Sagemath) that wants to use libgap.

I agree it would be nicer (hence I opened this issue, and would welcome patches adding this). but claiming it is necessary seems like a stretch? I mean, sure, it would of course make life a little bit easier, but extracting the required data from sysinfo.gap is easy in most languages, including Python, shell scripts and Makefiles.

[antonio-rojas]

This is particularly important now that libgap's headers require a garbage collector to be specified.

That's not intentional, please open a bug report, then we can habe this fixed in 4.12.1 (it should be easy).

That's great to hear, filed https://github.com/gap-system/gap/issues/5075

[dimpase]

an advantage of pkg-config is that interfaces to it exist in autoconf, in python, etc. (besides the ability to call it from shell).

while one can replicate this functionality by parsing non-standard meta-data, and writing micro-parsers, it'd be much nicer if it's not needed.

[dimpase]

should we close this in view of #5080 done?

[fingolfin]

OK, fine by me. If someone still wants this, they can (ask to) reopen or file a new issue