418 pkg confg

[hiker]

Adds a simple interface to pkg-config and nf-config.

[hiker]

@yaswant , ready for review. Not urgent for the release, it's just makes site-configs more convenient to write.

[MatthewHambley]

I'm not sure this is a problem which needs an object solution. In particular an object per library seems a bit odd since that obvious is immediately thrown away after the library has been interrogated.

It may be helpful to look at https://github.com/MetOffice/lfric_core/blob/main/lfric_build/pkg_config.py for an alternative approach. Although this is not necessarily the best solution either.

Also, the shell command seems like a different change. Can it be moved to its own pull request?

[MatthewHambley]

A test is needed that pkg_config is honouring the PKG_CONFIG_LIBDIR and PKG_CONFIG_PATH environment variables. Particularly that last one as it is how new package collections are added to the system.

[hiker]

I don't think we should assume that pkg-config is installed on the system (while we control gitlab ci, and many other systems, so we can ensure it is available, in general I don't think we shouldThat's also the reason why I tried to clean up tests that relied on gcc or so being available).

Then, how should I test that the environment variable are passed on? Creating a shell script that echo's the environment? Seems a bit odd - if this is to be tested, it should be done with the base class to verify it does not add/remove anything from the environment instead? Should I do that?

[hiker]

I'm not sure this is a problem which needs an object solution. In particular an object per library seems a bit odd since that obvious is immediately thrown away after the library has been interrogated.

That is the first time that I got a comment to remove OO ;) The classes here inherit from the Tool class the handling of availability, version number, and code execution and error handling. Why would we want to remove this feature of OO, and potentially duplicate the code here?

It may be helpful to look at https://github.com/MetOffice/lfric_core/blob/main/lfric_build/pkg_config.py for an alternative approach. Although this is not necessarily the best solution either.

I had a quick look, and while it supports version handling and better shared/static support, it's otherwise pretty much the same - one class per package? I don't see the real difference to the way this implementation is handling this.

Also, after looking at the code, it appears that it combined -L, -I etc and the path into a single argument. I am not really familiar with pkg-config, why is that required?

But the support for version specification and better static/shared handling would actually be good to add imho.

Also, the shell command seems like a different change. Can it be moved to its own pull request?

I added a new section to the documentation to document the new tools, and then added a paragraph of explicit documentation for the existing shell tool to this new section to complete it. Should I really pull out one paragraph of documentation to a separate PR?

I wonder if perhaps the previous PR wasn't clean or so, and showed some other changes? I've just updated this PR to latest main version (and added the two new tools to fab.api), and it now does not show any changes to shell.py.

TBH, since your implementation has already support for version specifications and static/shared linking, I am also happy to close this PR, so you can add your version instead.