update SCR_ASYNC_API in spack package

[adammoody]

Starting with v3.0rc2, SCR_ASYNC_API has been dropped and replaced with SCR_ENABLE_IBM_BBAPI, SCR_ENABLE_INTEL_CPPR, and SCR_ENABLE_CRAY_DW.

https://github.com/LLNL/scr/blob/6ea7cdcd791c7c2b4cbb05840978ca50b9609712/cmake/SCR_OPTIONS.cmake#L43-L50

In theory, this change allows one to select multiple vendor options to be enabled in the same SCR build, though we can't really test CPPR and DW right now.

For v3.0rc2, we'll need to drop SCR_ASYNC_API from our Spack package: https://github.com/spack/spack/blob/47ef59c8855f05a437e238f379b34143b98be1c0/var/spack/repos/builtin/packages/scr/package.py#L158-L160

[adammoody]

@CamStan , there are other new SCR cmake options coming with v3.0rc2. We may add, change, and remove some between now and then. Let's wait until we're close to the release to worry about Spack, but it'd help if you can help me keep an eye out for any problems we might introduce.

[adammoody]

Many SCR options are now defined in here:

https://github.com/LLNL/scr/blob/develop/cmake/SCR_OPTIONS.cmake

Other options that may be new or may have changed:

BUILD_SHARED_LIBS
ENABLE_IBM_BBAPI
ENABLE_CRAY_DW
ENABLE_INTEL_CPPR
ENABLE_YOGRT
ENABLE_MYSQL
ENABLE_PDSH
ENABLE_TESTS
ENABLE_EXAMPLES

Since it's related, let's use this issue to double check that we have documented CMake options here:

https://scr.readthedocs.io/en/latest/users/build.html#cmake

And any Spack package options that we want users to be aware of:

https://scr.readthedocs.io/en/latest/users/build.html#spack

The components also offer some new options that we might check. In particular, the BUILD_SHARED_LIBS option exists everywhere, which is useful to force static builds of libs.

[CamStan]

Thanks for the heads up @adammoody! I haven't dove into looking at all the option changes yet, but I was expecting some significant differences. Hopefully it won't be too complicated to keep Spack happy on both release candidates. I'll keep an eye out for anything that looks weird.

For SCR_ASYNC_API, we went into the first release candidate with the assumption it would be getting automated, so those lines you linked:

if spec.satisfies('@:2.999'):
    args.append('-DSCR_ASYNC_API={0}'.format(
        spec.variants['async_api'].value.upper()))

already do nothing with that variant for [email protected]. It's just there to allow the deprecated versions to still work.

[CamStan]

In particular, the BUILD_SHARED_LIBS option exists everywhere, which is useful to force static builds of libs.

For this, I'm assuming we just have scr+shared depend on all the components having +shared? Or have the static version, scr~shared, depend on all the components having ~shared?

Maybe an ignorant question, but is there a use case where someone might want a static scr build but use shared versions of the components (e.g., spack install scr~shared ^axl+shared)? Or vice-versa?

[adammoody]

For SCR_ASYNC_API, we went into the first release candidate with the assumption it would be getting automated

Ah, yes. Great. I should have actually paused to read the code.

[adammoody]

In particular, the BUILD_SHARED_LIBS option exists everywhere, which is useful to force static builds of libs.

For this, I'm assuming we just have scr+shared depend on all the components having +shared? Or have the static version, scr~shared, depend on all the components having ~shared?

Maybe an ignorant question, but is there a use case where someone might want a static scr build but use shared versions of the components (e.g., spack install scr~shared ^axl+shared)? Or vice-versa?

I'm not that clear on things myself at this point.

Generally, people like shared libs, so defaulting to shared libs would be good. Though we might want to expose a way for spack users to force a static build of everything. In that case, I think we'd want the static-only option to trickle down to the components.

Of course, we may opt to not bother providing a static option at all. Like the logging options, we don't have to expose all SCR CMake options. I'm not sure what would be useful or not, but I figured we can use this issue to keep a running list of changes to think about later. We can chat about it on a future call or when we get closer to the release.