Add generic config-tool support

[virtuald]

There are a number of frameworks/libraries/etc that export their build settings via a config-tool style of interface, as evidenced by meson having builtin support for a number of them (cups, hdf5, llvm, ... seems like quite a few).

It seems that meson's philosophy is to make it easy for users to use external dependencies that have weird requirements by building support for them out of the box. This is effective for anything that is popular enough to merit special handling, but for things that aren't particularly popular it probably doesn't make a bunch of sense to build custom support for that library in meson.

My proposal would be to allow the following sort of thing to work:

custom_config_tool = find_program('custom-config-tool')

mydep = dependency('mydep', method: custom_config_tool)

The executable program passed as the method would be required to support some standard as documented in the meson manual. Probably this standard would look very similar to how the other config tools work -- or maybe it would be something completely different like output json to reduce the number of calls needed to the executable. In any case, having a way to interface with other configuration tools would make it easier to integrate with other dependency systems without needing to modify the meson core.

In theory, the custom config tool could download a dependency when it gets executed, but that would probably be abusing this feature. If that sort of thing was desirable then we'd probably want to write it into the spec up front.

[eli-schwartz]

The executable program passed as the method would be required to support some standard as documented in the meson manual. Probably this standard would look very similar to how the other config tools work -- or maybe it would be something completely different like output json to reduce the number of calls needed to the executable. In any case, having a way to interface with other configuration tools would make it easier to integrate with other dependency systems without needing to modify the meson core.

It is best when the config-tool supports --version, --cflags, --libs as it can be supported as a drop-in. That's the only one I can really see being allowed as a user-defined config-tool.

Some of them are cursed and want --ldflags, --cppflags... Some of them are cursed and don't support a --version flag so we have to guess by using the --cflags value to figure out where the header is to extract a version from the header using cc.get_define or worse.

MPI uses --showme:compile, even.

hdf5 uses -showconfig to get the version, and -show to get compile/link flags. If you use -show -c you get the compile args, and if you exclude the -c you get the link args.

llvm uses --cppflags, but also needs --components to handle the modules: kwarg.

Qt invented their own config-tool called qmake, and you run it as qmake -query QT_INSTALL_HEADERS and qmake -query QT_INSTALL_LIBS, then manually search in the LIBS directory to see if you can find lib${NAME}.so for each qt modules: you want to find.

JSON is completely out of the question. No known config tools emit that and we don't want people to write any -- people should be distributing pkg-config files instead, which are already a well-defined interface.

[virtuald]

It is best when the config-tool supports --version, --cflags, --libs as it can be supported as a drop-in. That's the only one I can really see being allowed as a user-defined config-tool.

That seems reasonable enough.

JSON is completely out of the question. No known config tools emit that and we don't want people to write any

My thought with JSON was that someone could use that to write a wrapper around whatever the cursed config tool was, but if the above minimal interface was available then you could do it with that too.

people should be distributing pkg-config files instead, which are already a well-defined interface.

pkg-config is fine for things that support pkg-config, and if it's installed. If it's not installed, that can be annoying to deal with. It also isn't capable of wrapping any of these other cursed config-tools.

[virtuald]

I made a PR for this at #13660, for further discussion.