[DO NOT MERGE] Testing a switch to Cmake

[gonuke]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• 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.

Attempting to switch to CMake build instead of autotools.

[conda-forge-linter]

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.

[gonuke]

@conda-forge-admin, please rerender

[xylar]

@gonuke, did you want to switch to cmake before we merge #55 ?

[gonuke]

@gonuke, did you want to switch to cmake before we merge #55 ?

Thanks for checking in. I lost track of what was failing here, so I've relaunched the tests to see if I can take another shot at this

[xylar]

#55 got merged so you should probably rebase and test on that version instead.

[gonuke]

Yeah - just did that

[vijaysm]

Quick question @gonuke. Is this to get conda working on Windows?

[gonuke]

That's definitely a primary motivation

[gonuke]

@conda-forge-admin, please rerender

[vijaysm]

It may be best to have the CMake workflow script side by side rather than replacing the workflow that has been verified for the entire build matrix. Especially if the main motivation is to get the build working on Windows first.

[xylar]

I would be more inclined to switch over to use only cmake if possible.

[gonuke]

Fair enough. I'm going to continue testing with the CMake alone, however.

(Our full software stack prefers to build with CMake on all platforms.)

[gonuke]

I would be more inclined to switch over to use only cmake if possible.

That would also be my preference, but I don't think that CMake gets "first class" support with limited resources available on the team. I've tried to keep it up-to-date for our limited use case, but it relies on a lot of (at-times-fragile) customization of package finding.

[vijaysm]

Yeah thanks to Paul for keeping us focused on the CMake workflow even when we have been lagging support. I think it is in a decent enough state to replace autotools. I have my qualms about both workflows for configuration, but we will probably drop support for one of them soon (probably autotools). @gonuke I'll initiate a conversation in the mailing list this week.

The reason why I suggested having both workflows side by side is so that you can still get CMake working on Windows while keeping the rest of the platforms reliant on autotools for now since it's tested and verified already. And then we can make the transition along with MOAB when we deprecate autotools in the next major release.

@iulian787 Thoughts ?

[xylar]

@vijaysm and @gonuke, thank you both for clarifying.

[gonuke]

Building w/ LAPACK gets complicated on Windows, and therefore it's an obstacle for including tempest

[shimwell]

Would it be acceptable to include tempest and continue the move to cmake but just not build for windows (yet)? This would appear to still be a step on a good direction to me as we would still get cmake 🎉 .

Then the complicated LAPACK and windows building can be addressed at another time in another PR

[gonuke]

@conda-forge-admin, please rerender

[gonuke]

@conda-forge-admin, please rerender

[gonuke]

@conda-forge-admin, please rerender

[gonuke]

@conda-forge-admin, please rerender

[gonuke]

@conda-forge-admin, please rerender

[shimwell]

I see this PR has a few conflicts that I can't resolve as write access to the branch is needed. I was interested in seeing if the ever changing eco system has made the cmake build more possible since this PR was started. So I made an updated version of this PR over on #92 .