Dear all,
While I like the thought of clear and general <feature>_<backend> naming layout introduced in #7236, I would like to argue that I'm not fully convinced that it is sustainable in the long term:
- The feature names cover only part of the build configuration.
basic, std, ml, and max are determined mainly by LibRI and ML support, while many other independent optional features are not represented.
max may become increasingly misleading. As new optional components are added, a build named max may no longer correspond to the most feature-complete configuration.- The backend suffixes are not fully descriptive.
ser, para, and gpu do not clearly distinguish OpenMP, CUDA, ROCm, and potentially other execution backends. Most importantly, the case USE_CUDA=ON, ENABLE_MPI=OFF doesn't return a valid ABACUS_BIN_NAME, which will cause a false target-name error.
- Extending the scheme may introduce combinatorial complexity. We may eventually have to choose between inaccurate executable names and an increasingly complicated naming matrix.
Dear all,
While I like the thought of clear and general
<feature>_<backend>naming layout introduced in #7236, I would like to argue that I'm not fully convinced that it is sustainable in the long term:basic,std,ml, andmaxare determined mainly by LibRI and ML support, while many other independent optional features are not represented.maxmay become increasingly misleading. As new optional components are added, a build namedmaxmay no longer correspond to the most feature-complete configuration.ser,para, andgpudo not clearly distinguish OpenMP, CUDA, ROCm, and potentially other execution backends. Most importantly, the caseUSE_CUDA=ON, ENABLE_MPI=OFFdoesn't return a validABACUS_BIN_NAME, which will cause a false target-name error.