-
-
Notifications
You must be signed in to change notification settings - Fork 282
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Policy: how to compile c libs #27
Comments
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 |
@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 |
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. |
So the right way to compile c libs:
|
No, you probably do not want track_features. Pretty much only Python has that. You do need
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. |
Thanks for the explanation @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. |
Is there more to handle in here or is this a fait accompli? |
The work on the |
From conda/conda-build#779 (comment)
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...)
The text was updated successfully, but these errors were encountered: