An MLIR equivalent to llvm-config would be useful.

[zvookin]

LLVM provides the llvm-config which is very useful for both humans and automated configuration systems to query the properties of an LLVM installation. The command helps to find compilation options, library and headers locations, as well as e.g. CMake module files. It would be useful if the functionality provided by llvm-config were provided for all tightly coupled projects in LLVM, such as clang and MLIR. The straightforward way to do this would be to clone llvm-config into mlir-config and make sure it is installed into the LLVM bin directory. As this applies to projects other than MLIR, it may be preferable to add the support to llvm-config itself, e.g. via a --project flag which makes all of the current command flags to the tool apply to a named project. E.g. --project=mlir.

[joker-eph]

Can you clarify what would an mlir-config provide on top of llvm-config?
My (naive) view is that LLVM projects comes with a fairly monolithic installation with LLVM and so the tool already provide compilation flags (options and paths) you need.

[joker-eph]

LLVM seems to also consider dropping llvm-config: https://lists.llvm.org/pipermail/llvm-dev/2019-October/136314.html

(I don't know how concrete is this thought)

[zvookin]

I'm looking to use MLIR in Halide and I need to find the libraries necessary to link it in. The llvm-config command has been a very productive way to do this for LLVM. At one point I looked at incorporating clang functionality in Halide and gave up because finding its libraries and compilation options was so fragile that it was unshippable.

Personally I find depending on cmake only to be a bad call. Something like llvm-config is useful in many environments, fairly simple to support, quite reliable, and useful for human debugging as well as build systems. That said, if you want MLIR to standardize on pkg-config and cmake, that's an alternative approach to address this issue. If it already exists, I missed such...

[joker-eph]

We will standardize on whatever mechanism LLVM would provide for its subprojects: if you saw things that made it harder to work with clang, that can make it a motivating case for improving LLVM (feel free to chime in the thread I linked above)