Account for change of name of CppInterOp target (clangCppInterOp to CppInterOp)

[mcbarton]

This PR is to stop compiler-research/CppInterOp#882 being a breaking change as far as xeus-cpp is concerned. The library is changing name. This PR intends to extract the target name from the library, and configure xeus-cpp accordingly.

There is probably be a better way to do this, but this is what I came up with.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.25%. Comparing base (88a82c5) to head (54c81a4).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #479   +/-   ##
=======================================
  Coverage   74.25%   74.25%           
=======================================
  Files          23       23           
  Lines        1301     1301           
  Branches      111      111           
=======================================
  Hits          966      966           
  Misses        335      335           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[anutosh491]

Wait i'm confused here.
We have this right now

xeus-cpp/CMakeLists.txt

Line 93 in 88a82c5

set(CppInterOp_REQUIRED_VERSION 1.9.0)

And cppinterop 2.0 would somehow be a breaking one I'm guessing and we would want to update the above in cmake to be 2.0 and hence that eliminates the chance of us using clangCppInterOp right ? (as we compulsarily require 2.0)

Once we move to 2, we would anyways have to change to libCppInterOp.so... so I'm not sure why we simply don't just that ?

[mcbarton]

Wait i'm confused here. We have this right now

xeus-cpp/CMakeLists.txt

Line 93 in 88a82c5

set(CppInterOp_REQUIRED_VERSION 1.9.0)

And cppinterop 2.0 would somehow be a breaking one I'm guessing and we would want to update the above in cmake to be 2.0 and hence that eliminates the chance of us using clangCppInterOp right ? (as we compulsarily require 2.0)

Once we move to 2, we would anyways have to change to libCppInterOp.so... so I'm not sure why we simply don't just that ?

This is one way to do it, and one way I suggested tackling this problem in the CppInterOp PR (e.g. let CppInterOps depoyment be broken for a commit, and then do a change to the library name in xeus-cpp after release, breaking compatibility with previous cppinterop versions). The method in this PR makes it so the name change is not a breaking change. CppInterOp 2.0 is not necessarily breaking despite the major version change. Vassil chose to be 2.0 as the root cppyy migration may require breaking changes (so far no changes other than this name change would be breaking for xeus-cpp)

[anutosh491]

I think if we would make the cmake change, we won't need this I think !

And I guess we should just do it like we do the update everytime there is a cppinterop release.