Closed climbfuji closed 7 months ago
Better in that sense? Unarguably. I blame it on ignorance of my youth -- was only in my 40's when I started that package. I have a number of logical build switches that are similar throughout GFE. (This one is particularly interesting, because I had just learned about "mocking" and actually made it so the MPI logic can be tested without linking to MPI. That creates its own pain points it turns out.)
However, backward compatibility is also a cause unto itself. This has generally led me to leaving things as is. There are probably less than a handful of users of pflogger at this point, so I could probably be convinced to toggle this one. But similar switches in pFUnit would probably create some chaos in various dark corners around the planet.
Yeah, I suppose having something like an ENABLE_MPI
switch that defaults to ON
would be safe. Then past behavior is preserved.
That would work for us, thanks!
@mathomp4 Could you make the attempt, and I'll review?
@mathomp4 Could you make the attempt, and I'll review?
Okay. I'll give it a shot.
I've a PR in #107 which I think does this.
(Note that the CI might not quite work (old GCC?) so I've updated #94 to be like the CI in pFUnit develop. Hopefully this will work, but it might not as that has ifx...)
This question is related to issue https://github.com/spack/spack/issues/42137.
I think it is problematic if MPI is enabled silently if it's found somewhere in the search path. That MPI might not be compatible with the compiler/environment that the user is trying to build pflogger for. Wouldn't it be better to make this an option that is off by default and needs to be enabled explicitly, and then fail if enabled but no MPI can be found?