Task/all of us/basic blt testing

[white238]

No description provided.

[kennyweiss]

Is this waiting on anything before merging? Or can we merge sooner and update/patch as needed?

[kennyweiss]

One thing I've been wondering is how we can support multiple specs within an environment, e.g. when we add more compilers.

Would we do something like:

spack:
  concretization: separately
  specs:
  - blttest%clang@10.0.0
  - blttest%gcc@8.3.1

Or would we have one environment per compiler/spec ?

[tldahlgren]

One thing I've been wondering is how we can support multiple specs within an environment, e.g. when we add more compilers.

Would we do something like:

spack:
  concretization: separately
  specs:
  - blttest%clang@10.0.0
  - blttest%gcc@8.3.1

Or would we have one environment per compiler/spec ?

You could use Spack stacks (https://spack-tutorial.readthedocs.io/en/latest/tutorial_stacks.html), where you'd define specs and define compilers and Spack would build each spec with each compiler.

[tldahlgren]

You can see a relatively simple example at https://github.com/LLNL/radiuss-spack-testing/blob/dahlgren1/add-care-env/spack-environments/care/spack.yaml. Specifically the definitions starting at line 29/30 and matrix at lines 46-48.

[cyrush]

I think there is value in testing individual spack envs - since that is most likely how users will build when developing. But again, that is tied to my deployment model where I use a config to dial everything in to deploy with a specific set of features on a specific platform, and then I use multiple configs when I need more than one deployments (for example, cuda only, vs openmp only). Maybe thats not an important goal for the blt testing.

[tldahlgren]

You can also specify multiple matrixs. There's a somewhat simple example at https://github.com/mpbelhorn/olcf-spack-environments/blob/develop/hosts/lyra/envs/base/spack.yaml.

[tldahlgren]

FWIW. Just a few suggestions.

[tldahlgren]

Spack folks prefer using join_path provided by Spack instead of os.path.join.

[tldahlgren]

Same join_path suggestion as above.

[tldahlgren]

There's another at line 225.

[tldahlgren]

Could you not simply:

Suggested change

	if self.run_tests is False:
	options.append('-DENABLE_TESTS=OFF')
	else:
	options.append('-DENABLE_TESTS=ON')
	options.append(self.define('ENABLE_TESTS', self.run_tests))

[tldahlgren]

Could you not just override the check method (and skip the directives) since Spack automatically calls check after the build phase when inheriting from CMakePackage (unless you override build_time_test_callbacks)?

[tldahlgren]

Why not use join_path here instead of explicitly entering / in the paths?

[tldahlgren]

I realize using spec.satisfies() for this check is common for RADIUSS packages, but I believe you could do something like the following:

Suggested change

	if not spec.satisfies('cuda_arch=none'):
	cuda_arch = spec.variants['cuda_arch'].value[0]
	entries.append(cmake_cache_string(
	"CMAKE_CUDA_ARCHITECTURES",
	cuda_arch))
	cuda_arch = spec.variants['cuda_arch'].value
	if cuda_arch != 'none':
	entries.append(cmake_cache_string(
	"CMAKE_CUDA_ARCHITECTURES",
	cuda_arch[0]))