Policy: how to compile c libs

[jankatins]

From conda/conda-build#779 (comment)

For C dlls and such, yes, I always put in a python build dependency (and often a note saying "HACK: this is how we get the correct compiler" and then pass --python command line args (or have conda-build-all pass those args for me).

Should probably get a selector to only apply to windows: - python x.x [win]

The joys of windows...

Also something about the features and when what should be enabled (haven't looked into this...)

[ocefpaf]

I guess that is the same trick that @pelson already does in his recipes:

https://github.com/SciTools/conda-recipes-scitools/blob/master/proj.4/meta.yaml#L16-L19

[jankatins]

@ocefpaf Yep.

What I'm not certain is whether these should also get a "track this feature" (or how that is actually enabled). The end result should be a version string like vc9_2, not py27. Not sure how this works, haven't tried to compile complete native package...

[msarahan]

Strange that he has that only as a runtime dependency. I don't fully understand all this machinery, but yes, sadly it is how compiler gets specified for now.

The feature string gets added if you have that in your build section, as I specified in my comment in the conda-build thread.

py27 only gets added to the build string if python is a runtime dependency.

[jankatins]

So the right way to compile c libs:

build:
  track_features:
    - vc9  # [py27 and win]
    - ...

requirements:
    build:
        # To get the right compiler on windows ->not a runtime dep!
        - python x.x  # [win]
        - ... other deps...
...

[msarahan]

No, you probably do not want track_features. Pretty much only Python has that.

You do need

build:
  features:
    - vc9  [win]

because you will be providing different featured builds. Consumers of your libraries may need to track features. For python-based libraries, it is sufficient to just have the python dependency, and have its track feature figure things out. If you have another situation, for example a C++ Qt program consuming HDF5, then you need to have the C++ Qt program track a feature (just one of the vc ones, but can track other features) so that it gets the correct HDF5 library.

Make sense?

I don't generally use python x.x. It's just not necessary. x.x means "pin this version, so that I have the same version at runtime that I have at build time." When python is a build dependency, this really doesn't matter. It also doesn't matter because packages are tied to specific python versions when Python is a runtime dependency anyway. I don't actually know when you would use python x.x - only numpy x.x.

[ocefpaf]

Thanks for the explanation @msarahan!

[msarahan]

One important detail I forgot to mention: avoid features of a similar kind in the same environment. For example, of you had python that activated vc9 and some unrelated program that activated vc 14, conda would get confused and give unsatisfiable dependency errors.

We need to formalize something to prevent this.

Note, however, that installing more than one version of the visual studio runtimes is totally fine. If you have a self-contained exe that does not need compiler-matched libraries (or if those libraries are exe-specific and can be limited to one compiler), then you can specify msvc_compiler in the build flags, and add a dependency to vs20??_runtime in the runtime dependencies. Those are new packages, soon to replace the msvc_runtime package. Unfortunately the PR is in our private repo. I'll duplicate it in conda-recipes and post a link here.

[jakirkham]

Is there more to handle in here or is this a fait accompli?

[pelson]

Is there more to handle in here or is this a fait accompli?

The work on the vc package has moved the suggestion forward somewhat, but we aren't quite finished with it. https://github.com/conda-forge/vc-feedstock and conda-forge/glpk-feedstock#10 relate