pin-compatible, use boost-cpp instead of boost

[djsutherland]

About boost:

• The naming is confusing, but the boost package includes boost::python; you should only need boost-cpp here.

• The boost-cpp (and boost) recipes don't have a pin_run_as_build entry (yet – pin_run_as_build for boost, boost-cpp conda-forge-pinning-feedstock#58), and so you need to explicitly pin_compatible to ensure that a compatible version of the library is used at runtime as at build time.

• I removed the skip for py!=36; as-is, I think it would have been impossible to install on python2.7 on Linux, for example. I'm allowing a vc9 build here, but if that fails we can skip it with skip: true  # [vc9].

cc @scopatz, FYI.

[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.

[chambbj]

@dougalsutherland The py!=36 skip was I'm sure a holdover from earlier fumbling with PDAL. No need to limit here IMO. vc9 however does appear to be an issue. As for Travis, the PCL builds do tend to timeout from time to time, not sure what to do about that here.

[scopatz]

Yeah, this naming scheme always gets me. Thanks for the reminder @dougalsutherland!

[djsutherland]

We can avoid Travis timeouts by using Circle for OSX, which has a longer timeout. :)

Also skipped VC9 since that seems to not work. I guess the AppVeyor build for VC14 also timed out, though; not sure if there's anything we can do about that....

[jakirkham]

Could use jom or ninja instead of nmake to get parallel builds on Windows.

[jakirkham]

FYI - CircleCI macOS builds are slowed.

ref: https://fleep.io/chat?cid=Bzl9QQa9T0q3jFeLMwdvtQ

[chambbj]

I must be missing something. Looks like Appveyor is still trying to build vc9. 🤔

[djsutherland]

Huh, I thought that worked but obviously didn't check properly. This will.

Also switching to ninja install to try to speed up Windows build.

[msarahan]

vc9 doesn't work because that's a variable that isn't defined. vc is defined, because it is part of conda_build_config.yaml.

py35 and such were hard-coded. https://github.com/conda/conda-build/blob/master/conda_build/metadata.py#L99

I probably won't maintain the hardcoded crap going forward.

[jakirkham]

That or we could do this...

It would be nice if things like np110 were interpreted as np==110 as might be reasonably expected.

xref: conda/conda-build#1202