More systematic compiler flags for CI; separate Conda-style builds

[RobertPincus]

This PR separates plain condo-style builds across many platforms into one workflow. More systematic debug and release testing with gfortran is done in continuous-integration.yml

"-march=native" flag is removed. Seems to resolve #358 and #318, making #359 obsolete.

[RobertPincus]

I don't understand why pre-commit is failing in the check-style action but not locally?!?

[RobertPincus]

@makepath-alex The conda-style-builds CI suggests you could remove all compiler flags from the conda recipe I think? Let me know if there are changes that will get this closer to what's executed by the condo-build

[RobertPincus]

Thanks for the suggestion @skosukhin; it worked perfectly . Any other thoughts?

[RobertPincus]

@makepath-alex Maybe you want to change the target of #361 to this branch? Then you could approve the PR if I've made things more clear.

[RobertPincus]

@skosukhin @makepath-alex To explain the logic: the idea is to test a range of options with gfortran on Ubuntu (different sets of kernels, single/double precisions, debugging and release builds with strict extra flags for the debugging)... and separately to test a conda-like build on all the platforms we might want to support.

[RobertPincus]

@makepath-alex @skosukhin I believe I've made the changes you wanted - one or both of you can look briefly and approve?

(It's nice to have multiple eyes on these changes, thanks.)

[skosukhin]

We test RelWithDebugInfo with no extra flags in conda-style-builds.yml. Instead of Debug with extra flags and RelWithDebugInfo without extra flags, I would test only RelWithDebugInfo with extra flags in this workflow.

[RobertPincus]

One minor(?) difference is that continuous-integration uses the system gfortran while conda-style-builds uses the conda-installed gfortran.

I was thinking of continuous-integration as a way to run the code with maximum debugging, which motivated Debug builds with extra flags. @skosukhin Do you think we'll be able to isolate any errors introduced with RelWithDebugInfo?

[skosukhin]

I don't see why we should not run this case.

[RobertPincus]

I thought to exclude this because it would never be used. Builds for use on CPU architectures will bundle the default kernels. I did want to test the accel kernels with max debugging in case we introduce coding errors.

[skosukhin]

Since there is only one value for the build-type in the matrix now, should we remove it and have the following here?

Suggested change

	-DCMAKE_BUILD_TYPE=${{ matrix.build-type}} \
	-DCMAKE_BUILD_TYPE=RelWithDebugInfo \