I think it should look more like this:

requirements:
  build:
   # TODO : default clang compiler on osx has link error, so gcc is forced
    - {{ compiler('c') }}       # [not osx]
    - gcc                       # [osx]
    - {{ compiler('fortran') }} # [linux]
    - scikit-build >=0.8.0

  host:
    - python {{ PY_VER }}
    - flang                     # [win]
    - numpy x.x
    - openblas >=0.3.0
    - libgfortran-ng # [not-win]
    - libgcc-ng      # [linux]
    - scikit-build >=0.8.0
   # on Windows, this relies on having visual studio CE 2015
   # this link needed quite some searching, please do not delete!
   # https://go.microsoft.com/fwlink/?LinkId=532606&clcid=0x409
   
  run:
    - python {{ PY_VER }}
    - numpy x.x

But I'm not quite sure if the shared libs need to be in the run section.

I'm struggling a bit to get this working. Is it worth fussing over the meta.yaml here? Aren't you going to use an entirely different meta.yaml over at conda-forge anyway?

It looks like this does not get fixed with meta.yaml.

Statespace code uses the numpy.block function, apparently introduced in numpy 1.13, so this fails with numpy 1.11. In control/statesp.py. So if we want numpy 1.11, this should be marked as a bug on python-control.

Using NumPy 1.11 to compile against provides the larger set of ABI compatibilities. You can then use Slycot compiled with 1.11 with any NumPy 1.11 to present versions. It is the oldest ABI compatible version on linux/osx/windows (as far as I understand, can go back to 1.9 on linux/osx). The nice thing is that you don't have to compile against every version of NumPy. You can bump it up to NumPy 1.13, we should just note in the readme or something about the ABI compatibility range.

Hm. OK.

This conversation on conda-forge suggests using pin_compatible.
Here in a continuum forum more details on pinning are given. So I don't get the impression that pin_compatible is conda-forge specific.

The latest travis build seems to build with 1.16.2, both python 2.7 and python 3, thanks to not pinning the numpy versions to old ones that give problems on python-control.

Strictly speaking, if we want to test with the python-control code, then currently the build requirement should be numpy >= 1.13

Assuming the binary compatibility information is correct, Slycot should be OK with numpy >=1.11 respectively >=1.9. So rather than giving specific numpy ranges, we could use the following for the run requirement:

- {{ pin_compatible('numpy', min_pin=1.9) }}   #  [unix]
- {{ pin_compatible('numpy', min_pin=1.11) }}   #  [win]

(The current meta.yaml lists [unix] twice)
Also, I think flang should be in the build requirement, and libflang in the run requirement, for windows builds.

OK, thanks. I'll revert back to the pin_compatible() variant, though as I understand, what I've currently commited (4de751) is essentially the same as pin_compatible('numpy').

I think the compiler('c') and compiler('fortran') might mean the libgcc-ng, libfortran-ng, requirements aren't needed. It looks like flang needs special treatment, which is a pity. I'm not going to change any of those settings, though.

I'll change back to pin_compatible, squash the commits, and rerun the builds on Windows. If there are no other objections, I think we can then tag for 0.3.4?

So I don't get the impression that pin_compatible is conda-forge specific.

You are right, that was my mistake. I couldn't find it in the conda docs and the main pages of the conda docs seem to recommend numpy x.x. Here is the relevant doc page: https://docs.conda.io/projects/conda-build/en/latest/resources/variants.html#extra-jinja2