Add official MKL cmake finder.

[john-michaelburke]

• Adds a stripped-down version of the official ${MKLROOT}/lib/cmake/mkl/MKLConfig.cmake.
• Attempts to find three static libraries off of known path MKLROOT

-- Found MKL: /opt/intel/oneapi/mkl/latest  
-- Found MKL: /opt/intel/oneapi/mkl/latest/lib/intel64/libmkl_intel_lp64.a  
-- Found MKL: /opt/intel/oneapi/mkl/latest/lib/intel64/libmkl_gnu_thread.a  
-- Found MKL: /opt/intel/oneapi/mkl/latest/lib/intel64/libmkl_core.a

• If MKL_ROOT it will first check to see if MKLROOT is defined, then try to fall back on a known location before failing.
• Using MKLROOT we deduce the include folder.
• Here is an example of how this would be called in orion-engine:

if(ENABLE_MKL)
  find_package(MKL)
  if (MKL_FOUND)
    foreach(TARGET IN LISTS TESTS-OE EXE-OE LIBS-OE)
      target_link_libraries(${TARGET} PRIVATE MKL::MKL)
    endforeach()
  endif()
endif()

[jungleraptor]

So the good thing about this version is they're using modern cmake conventions.

I do want to ask however, is the version we worked on not working?

This script is almost 900 lines of really complicated configurations. The goal of it is to "just work" for a huge number of potential target platforms.

However, for our needs, we probably only need to target one or two platforms and compilers. So I'd prefer if we checked in a simpler script that only targets our use cases.

We'll need to eventually port this to bazel and it'll go much smoother if we know exactly what options and settings we're building this library with, instead of having to filter through all this noise.

[john-michaelburke]

So the good thing about this version is they're using modern cmake conventions.

I do want to ask however, is the version we worked on not working?

This script is almost 900 lines of really complicated configurations. The goal of it is to "just work" for a huge number of potential target platforms.

However, for our needs, we probably only need to target one or two platforms and compilers. So I'd prefer if we checked in a simpler script that only targets our use cases.

We'll need to eventually port this to bazel and it'll go much smoother if we know exactly what options and settings we're building this library with, instead of having to filter through all this noise.

What we had was working in CI for orion-engine but not for orion (although it seemed like they were using the same Dockerfile which is puzzling). I was hoping this could also be more friendly for local development than what we spun up. As for porting to bazel, I see that Tensorflow supports mkl in their bazel builds so hopefully, we can reuse if not just copy their implementation for our usecase. In the meantime, I can take a stab at gutting some of this config.

[jungleraptor]

My suggestions would be to capture whatever these lines end up expanding to for our target and hardcoding that.

[john-michaelburke]

Sorry just saw this now. I'll add that after the hackathon.

[john-michaelburke]

@isaactorz I have addressed your concerns and hardcoded these blocks.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[jungleraptor]

Just one small nit otherwise this is a lot clearer as to what options we're actually setting up in our build 👍🏼 .

[jungleraptor]

Consider getting rid of these variables and just adding them directly to MKL_LINK_LINE below. Having them more localized to where they're actually used will make this a bit more readable.

[john-michaelburke]

Done. Fair enough.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information