Open al42and opened 1 month ago
Thanks for the RFC, I agree this would be nicer. I would suggest using ONEAPI_ONEMKL_
for now. Is this blocking you? We may have the bandwidth to work on this but contributions are welcome if anyone needs this soon.
Is this blocking you?
Not blocking, just wanted to raise a concern since it's part of public API (I don't have a link at hand, but it was suggested in one of the examples to check these variables).
We may have the bandwidth to work on this but contributions are welcome if anyone needs this soon.
Ok! :wink:
Summary
To prevent potential macro naming conflicts between oneMKL and client applications, this RFC proposes adding a unique prefix (such as
ONEMKL_
orONEAPI_ONEMKL_
) to all macros defined in oneMKL's public API.Problem statement
oneMKL defines a bunch of configuration macros in
config.hpp
, which is transitively included in the<oneapi/mkl.hpp>
file.Those are
ENABLE_<backend>_BACKEND
for each enabled backend,BUILD_SHARED_LIBS
andREF_(BLAS|CBLAS)_LIBNAME
.As a consequence, the client application that tries to use oneMKL will also have them all defined. This could be useful, but, since macros don't obey any scope rules, they can also easily cause confusion if the client application itself uses, e.g.,
ENABLE_CUFFT_BACKEND
orBUILD_SHARED_LIBS
.ES.33 in C++ Core Guidelines recommends adding supposedly unique prefixes (e.g., your organization’s name) to the macro names.
As such, I suggest adding
ONEMKL_
orONEAPI_ONEMKL_
prefix to all the macros defined in the public API.Details