Enable Windows package building with Azure

[raimis]

Description

This is part of Psi4 porting to Windows (#933).

Enable conda package building for Windows with Azure.

Todos

Notable points (developer or user-interest) that this PR has or will accomplish.

• Enable package building
  • Add conda recipe
• Add an option to trigger package building
  • https://dev.azure.com/psi4/psi4 pipeline have to be configured to provide the following variables:
    • conda.build with default false (settable at queuing time)

Questions

• Currently, the conda recipe is in conda/win. Maybe it should be somewhere in https://github.com/psi4/psi4meta/? --> Recipe will stay in conda/win, for now.

Checklist

• Tests added for any new features
• All or relevant fraction of full tests run

Status

• Ready for review
• Ready for merge

[raimis]

@loriab could you add a pipeline variable, please.

[loriab]

I've added the var on Azure (several hours ago now, sorry). Also sent invite for write access to psi4meta. There's no PRs there -- just free pushing to master. I'm expecting the diffs btwn Win and Linux/Mac recipes to be significant, so feel free to make a separate win conda dir or win recipe dirs, if you like. Or, if it's more convenient with Azure to keep the recipes w/i the p4 repo, the conda/ dir is fine. I'm the only one who looks in there.

[raimis]

Now Azure can build an optimized Psi4, run all the tests, and make a conda package: https://dev.azure.com/raimisg/psi4/_build/results?buildId=569

Queue time variables:

cmake.build_type= Release
conda.build=true
ctest.type=full
pytest.type=full
python.version=3.6

The built package is on Anaconda: https://anaconda.org/raimis/psi4/files

You can install and try:

conda install -c raimis -c conda-forge psi4

[raimis]

@loriab I see you have already created, 1.3.x branch. This PR effectively have to be merged to both 1.3.x and master.

[loriab]

Wonderful news! And got it -- will figure out the two way merge. Now to find someone with a Windows box to try this out ...

[loriab]

hooray, lgtm

[loriab]

Ultimately, I think we'll want to break out separate packages for deps and to use run_exports and pin_compatible for version constraints, but great for now.

[raimis]

Yes, I agree! Currently, libxc and libinit are statically linked. So the dependency shouldn't be a problem.

[loriab]

Completely agree -- can't cause trouble as-is.

[raimis]

OK! So this PR goes to master. After it is merged, I will cherry pick and make a PR to 1.3.x.

[loriab]

OK! So this PR goes to master. After it is merged, I will cherry pick and make a PR to 1.3.x.

Sounds good. Slight complication is that when I wrote the versioner.py script that computes our version (and integrates w/cmake), I had the misguided notion that all commits on a release branch were version increments (that is, your PR would turn into v1.3.1 or .2), so I'll have to unwind that scheme before any proper tag of a v1.3.1 w/your PR. Just FYI.

[andysim]

This is great! Thank you for figuring this out. LGTM