Barry, Satish, and others, In MKL 2018 update 2, the old, non-inspector executor sparse BLAS interfaces were deprecated in favor of the newer, inspector-executor versions. To keep lots of warnings from being generated, I put in some preprocessor code to avoid using these interfaces in AIJMKL, and the hack-y way I did this was simply based on whether PETSC_HAVE_MKL_SPARSE_SP2M is defined, since mkl_sparse_sp2m() was introduced in this same update and I needed a configure test for the presence of this function anyway.
I now want to change the mkl_sparse_sp2m.py test to not define PETSC_HAVE_MKL_SPARSE_SP2M for versions of MKL prior to 2019, because I determined that the way I am using mkl_sparse_sp2m() is unsafe prior to this version. Since this will break my current logic for determining which MKL routines are deprecated, this seems like a good time to handle the deprecation in a better way. I did some cursory grepping through the BuildSystem packages files, and it looks (?) like we don't have some examples to follow on how to handle deprecated library functions. What I'd like to do is compile a test that calls one of the deprecated functions and then checks for warning messages from the compiler, but I don't know the variants of all of the warning messages that compilers might emit, and I think some compilers won't give any. If there isn't a good way to do such a test, I could * Rely on the version information in mkl_version.h, OR * (The easiest solution) Check to see if MKL_DEPRECATED is defined. (This was introduced when the old sparse BLAS interfaces were deprecated.) Is there a "best practice" for how we should handle such things in PETSc? --Richard
