Add more tests to make sure the package does not regress.

[vgvassilev]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[vgvassilev]

@mcbarton, @fsfod, we seem to have a similar problem to the one we fixed in compiler-research/CppInterOp#196. I see that some of the exports are dependent on the MSVC version and I was wondering if we can carry these exports somehow in the CppInterOpConfig.cmake. Alternatively, we could use a sledgehammer like CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS but I am not sure if that's a good idea. Any thoughts?

[vgvassilev]

@conda-forge-admin, please rerender

[mcbarton]

@mcbarton, @fsfod, we seem to have a similar problem to the one we fixed in compiler-research/CppInterOp#196. I see that some of the exports are dependent on the MSVC version and I was wondering if we can carry these exports somehow in the CppInterOpConfig.cmake. Alternatively, we could use a sledgehammer like CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS but I am not sure if that's a good idea. Any thoughts?

@vgvassilev The export symbols method is known to be brittle to the version of MSVC used compiler-research/CppInterOp#188 (comment) . @fstod discusses his opinion on WINDOWS_EXPORT_ALL_SYMBOLS in this message, suggestion he doesn't think it will work. He also suggests a longer term solution than these methods.

[vgvassilev]

@mcbarton, @fsfod, we seem to have a similar problem to the one we fixed in compiler-research/CppInterOp#196. I see that some of the exports are dependent on the MSVC version and I was wondering if we can carry these exports somehow in the CppInterOpConfig.cmake. Alternatively, we could use a sledgehammer like CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS but I am not sure if that's a good idea. Any thoughts?

@vgvassilev The export symbols method is known to be brittle to the version of MSVC used compiler-research/CppInterOp#188 (comment) . @fstod discusses his opinion on WINDOWS_EXPORT_ALL_SYMBOLS in this message, suggestion he doesn't think it will work. He also suggests a longer term solution than these methods.

Yes. Understood. I believe compiler-research/CppInterOp#213 fixes my problem for now...

[vgvassilev]

@conda-forge-admin, please rerender