Support for pkg-config

[Uberoverlord]

On Linux, there is not really a standard location for libraries and headers to be. Due to this and gprbuild's apparent inability to dynamically locate these resources, properly packaging software to be compiled with gprbuild often requires hard coding paths (which may be incorrect on many systems, damaging portability) or using a secondary build tool to template in this information before gprbuild (which complicates the build process, hinting at a flaw in gprbuild)

The more or less standard solution to this issue, at least on Linux, is to use pkg-config which can find where these resources for any given library are. I've been unable to find any way that gprbuild is able to use this vital tool however, and it seems much of the ecosystem built atop of gprbuild has been unable to use pkg-config as well (some example packages showing this is an issue within alire would be: tash, gtkada, adasdl). This has lead to the aforementioned problems of damaged portability and over-complicated build processes being common whenever third party libraries are required.

If using pkg-config to dynamically locate these resources is an existing capability, it needs to be documented better so that developers may be able to use it. If it is not, then I would like to have a discussion about how it could be brought into gprbuild because it would greatly improve the quality and experience of using of gprbuild.

[briot]

On 2023-05-11 21:56, Uberoverlord wrote:

The more or less standard solution to this issue, at least on Linux, is to use pkg-config which can find where these resources for any given library are. I've been unable to find any way that gprbuild is able to use this vital tool however, and it seems much of the

It might be possible to extend gprconfig's knowledge base so that it knows how to call pkg-config. This tool is meant to generate a configuration file (.cgpr), which is then parsed by gprbuild. This is how language-specific settings are setup in gprbuild, like what compiler to use, what switches, and so on.

One difficulty with this scheme is how gprbuild/gprconfig would know to include that part of the knowledge base (which are XML files).  This is currently based on target, language, ... but not on what libraries to use.  It would be possible to invent a "virtual language" (say "gtkada") set in the project file.  Then gprconfig gets calls with this language on the command line, and executes the relevant command specified in XML (e.g. pkg-config). This is quite artificial though and a better approach might be possible.

I think I would personally go with generating your project file on the fly. So before you run gprbuild, you actually generate the .gpr file from various pieces of information, including the output of pkg-config. This is not the best integration since it requires two separate steps.  On the other hand, that means you do not need to regenerate every time you want to compile since your machine doesn't often change the libraries.

Emmanuel

[Uberoverlord]

I think I would personally go with generating your project file on the fly. So before you run gprbuild, you actually generate the .gpr file from various pieces of information, including the output of pkg-config.

This is a solution I am meaning to avoid as then any projects wanting to import the library as a dependency would need to complicate their build process as well to handle the 2 step processes of their dependencies and the complexity only ever bubbles up in this way.
Ideally, libraries should be more "plug and play" than this and one should be able to "with" a library as a dependency to their project and use gprbuild without also writing a makefile or what-have-you because why would they not then just use make or some other alternative given it would reduce dependencies and overall simplify the build process.

[Fabien-Chouteau]

@Uberoverlord there are plans for pkg-config support in Alire itself, as part of the "external dependency" system.

[carloxff]

I had to takle this very same problem, reaching to the following solution. Before calling to gprbuild, I source a bash script that exports an env variable APPINCLUDES containing all necessary include switches extracted from pkg-config. That way, I just had to retrieve and use that information in the compiler section of the gpr file, using external_as_list(APPINCLUDES, " "). That worked fine for me, but I still look forward to getting a native solution from gnat team.