Hi @adamjstewart! I noticed that the following package(s) don't yet have maintainers:

• brunsli

Are you interested in adopting any of these package(s)? If so, simply add the following to the package class:

    maintainers = ['adamjstewart']

If not, could you contact the developers of this package and see if they are interested? You can quickly see who has worked on a package with spack blame:

$ spack blame brunsli

Thank you for your help! Please don't add maintainers without their consent.

You don't have to be a Spack expert or package developer in order to be a "maintainer," it just gives us a list of users willing to review PRs or debug issues relating to this package. A package can have multiple maintainers; just add a list of GitHub handles of anyone who wants to volunteer.

Alright, this alternative PR is now ready for review!

Pinging the same folks as #30916: @Sinan81 @snehring @haralmha @rouault @amaji @payerle @michaelkuhn @iarspider @neilflood

This PR also adds GDAL 3.5.0 and CMake support, but does it in a completely different way. The biggest change is w.r.t. variants:

• GDAL: driver variants #30916: user specifies which drivers they need, dependencies are automatically added based on drivers
• GDAL: dependency variants #31197: user specifies which dependencies they want to build, drivers are automatically enabled based on dependencies

This is the same way the variants are in develop, and seems to be significantly easier to maintain. With #30916 we would probably still need to use the same flags for Autotools to tell the build system where to find the dependencies, and the exact driver -> CMake/Autotools flag is nonintuitive. For a comparison of the relative complexity, the build recipe in this PR is ~700 lines while the build recipe in #30916 is 1,000+ lines.

This PR also allows us to retain GDAL 2 support, which several packages still rely on. I also added a bunch of new variants for dependencies that happen to be in Spack. I might add more in the future once I package the dependencies.

Let me know if you prefer this PR or #30916. In terms of maintainability I think I'm definitely leaning towards this one.

"Easier to maintain" wins a lot of points, in my view. This does look better, and I am most impressed that you were able to include both the autotools and cmake builds in the one recipe, and hence keep all the older versions. Legend!

I confess I got a bit lost about where you are up to with the default set of drivers (as discussed in #30916). Could you clarify where you are aiming with that?

I am most impressed that you were able to include both the autotools and cmake builds in the one recipe, and hence keep all the older versions.

To clarify, both #30916 and #31197 include both Autotools and CMake build system support. The difference is that #30916 uses Autotools flags that weren't added until GDAL 3.0, so that PR only supports GDAL 3.0–3.4 (Autotools) and 3.5+ (CMake).

I confess I got a bit lost about where you are up to with the default set of drivers (as discussed in #30916). Could you clarify where you are aiming with that?

In the current recipe (develop), only required dependencies were added by default, you had to enable all variants yourself. In both #30916 and #31197, all required AND recommended dependencies are enabled by default. There are still several dozen optional dependencies that you have to manually enable if you want them. You can see the default=(True|False) in the variant definitions to see which are enabled by default. I think enabling recommended dependencies by default is a good compromise. We want to keep build times as short as possible and prevent issues where certain dependencies don't build on all systems, while still keeping the default build relevant to most users.

That all makes sense. Thank you for the clarifications. :-)

Is anyone else able to review this PR?