418 pkg confg

[Joerg Henrichs (hiker)]

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

[Joerg Henrichs (hiker)]

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

[Matthew Hambley (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?

[Joerg Henrichs (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.

[Matthew Hambley (MatthewHambley)]

One minor issue of location.

[Matthew Hambley (MatthewHambley)]

nfconfig is a very specific implementation detail which doesn't feel like it belongs in the build framework. This feels much more like an odd-ball quirk of a particular project. So lets move it to lfric_core where it seems like a better fit. You will probably want to delete the pkg_config library which is already there, since this replaces it.

By contrast, pkg_config is a standardised tool, much more appropriate across projects.