pkg confg

[Joerg Henrichs (hiker)]

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

Closes #418

[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.

[Joerg Henrichs (hiker)]

I had to merge #569 in (since pkg config used the MISC category. Given that #569 is tiny, I think that's ok, and I'll close the separate PR.

[Joerg Henrichs (hiker)]

Sam Clarke-Green (@t00sa) , this PR is now required for current lfric_core (while we don't need pkg_config support necessarily, this PR re-adds Category.MISC, and several tools in lfric needs this). So, I am marking this as high priority. Not sure what milestone to assign, but it would be great to have this for the next lfric release.

[Matthew Hambley (MatthewHambley)]

Lets get this change on.