llvm: add llvm_config helper

[trws]

Add a helper as a base to build better libs etc. methods. This should help with #28621 @glennpj.

As @haampie pointed out, llvm-config does not get along very well with libllvm.so, it's supposed to (it even has an option specifically for that case) but it doesn't. If someone needs that, they should use libdir then libnames to get the appropriate setup then build the path themself. For anything else though, shared-libs, static-libs, paths, flags, it works reliably in my experience.

The imports are not really related, but reduce the number of error prompts on this file by an immense amount when linting.

[adamjstewart]

The imports are not really related, but reduce the number of error prompts on this file by an immense amount when linting.

I think we should remove these. This isn't related to this PR and the same problem occurs for all files in Spack. At one point I think we tried making the import system less hacky to fix this, didn't we? Like use from spack.pkgkit import * instead?

[adamjstewart]

Are there other executables that get installed with LLVM or just llvm-config? We could override command to point to this exe.

[trws]

The imports are not really related, but reduce the number of error prompts on this file by an immense amount when linting.

I think we should remove these. This isn't related to this PR and the same problem occurs for all files in Spack. At one point I think we tried making the import system less hacky to fix this, didn't we? Like use from spack.pkgkit import * instead?

Yeah, I had a big PR that tried to straighten out a bunch of that, but it rotted when I lost time to keep updating it. I can pull it out, but figuring out something for this would be nice. It’s kinda painful to work on package files as it is.

[trws]

Are there other executables that get installed with LLVM or just llvm-config? We could override command to point to this exe.

There are others, lots actually including replacements for most of binutils and the bytecode interpreter, but I’m not sure all of them are necessarily always installed. The llvm-config binary I don’t think can be turned off though, it’s pretty much the only stable way to use llvm components over time. Perhaps the cmake targets too I suppose, but this is easier for us to get ahold of.

[trws]

I don’t want to do it in this PR, but you make we think we should rework the external detection logic @adamjstewart. As it stands, it will only work for externals that include clang or lldb or similar, but nothing in that list is installed if you have an llvm-only build. The closest is probably lld, but even that isn’t necessarily going to be there. What do you think @haampie?

[glennpj]

For the specific case that I am looking for in #28621 I need the library directory, which should be provided by llvm-config --libdir. Would there be a specific property for that defined in the llvm package file, using the llvm_config method?

[adamjstewart]

Yeah, I had a big PR that tried to straighten out a bunch of that, but it rotted when I lost time to keep updating it. I can pull it out, but figuring out something for this would be nice. It’s kinda painful to work on package files as it is.

I would love to see this. Our important system is a bit too magical at the moment. Maybe after @tgamblin finishes blackening Spack?

[adamjstewart]

For the specific case that I am looking for in #28621 I need the library directory, which should be provided by llvm-config --libdir. Would there be a specific property for that defined in the llvm package file, using the llvm_config method?

I don't think we need properties for each and every flag, let's just have a single llvm_config method and call it when we need it.

Now that I think about it, this reminds me of the problem we had with Python packages. When we recursively load Python libs, we set PYTHONPATH for all of them. At one time, this involved calling the Python executable and querying a bunch of properties, and we were doing this for every package. Now we cache it the first time and it's much faster. Not sure if that will be an issue for LLVM since it won't appear in the DAG more than once.

[trws]

That’s a fair point. I seriously considered caching it, but figured it would be better to leave it simple and see if the need appears. My intuition is that there will usually only be one or a very few packages calling this, but if I go and break the llvm package back apart into all of its components then it might be worth it.

[trws]

Any further changes you want @adamjstewart? Thoghts @haampie?

[adamjstewart]

I don't think we need properties for each and every flag, let's just have a single llvm_config method and call it when we need it.

This is my only remaining comment, since we also need to access the libdir I think it makes more sense to only have llvm_config instead of having llvm_config, llvm_libs, llvm_libdir, etc.

[trws]

Makes sense, removed the llvm_libs helper.