-
Notifications
You must be signed in to change notification settings - Fork 108
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
conda-forge package #149
Comments
Yes, I think I can do this. Correct me if I'm mistaken, I think I will need to also update libcpuid's readmes (for maintainers), to add the additional step when doing a release - AFAIK conda-forge needs to be manually updated about new releases. As a small heads-up, libcpuid releases aren't frequent, as we believe the "build from master" model to better suit libcpuid's usage. Most commits are incremental updates to add detection and data for new CPUs as they come out. Making a new release for each new CPU is a bit of an overkill, and we also have CI. The Github's source code releases system is not heavily relied on. If you rely on that, you'll potentially get a package that might be several months old. Let me know if this would be an issue for Sire. I think you may want to evaluate a build-process that downloads the libcpuid code from Github and build it directly. |
Thanks for the reply. Yes, I believe the conda-forge update is a manual step, although you will get write access to the feedstock repository so could probably perform the update as part of your CI using an access token if required. (Not 100% sure on this.)
Thanks for the info regarding your releases. The approach that you suggest is actually what we do at present, only using a specific release rather than master. This isn't allowed by conda-forge and all dependencies must be within their ecosystem. (Unless there are exceptional circumstances.) We use libcpuid within our own cpuid.cpp. I think it would be okay to just make use of your releases (rather than master) and simply rebuild our conda package as new releases come out. @chryswoods would be able to comment if we do need to track changes more frequently than this. (It looks like we are still using v0.4.1) |
Thanks Lester - no, we don't need to track changes that quickly. CPUID is just used to give some extra metadata to the binary saved files. It is a "nice to have" that could be dropped if it was problematic. The only reason to keep updated is so that the processor name can be recognised (otherwise it is "unknown" I think). Also I don't know how libcpuid will behave on, e.g. the Apple M1. Not a problem now, but something to check in the future. |
I have a dummy recipe here that I'm using to test my build of Sire. This works on the conda-forge platform and I'll be happy to transfer ownership once our build is working and approved. |
Our conda-forge build of Sire is now working, linking against the bundled libcpuid recipe. Does this look okay to you? I've just used CMake to execute a release build on all platforms, rather than using the provided VS solution file on Windows. |
Hello @lohedges, sorry for the late answer. CMake usage in the recipe looks good to me.
ARM CPUs support is work in progress. It will be part of the next libcpuid release (e.g. v0.7.0). |
Many thanks for this excellent package. We make use of libcpuid within our package Sire, a multiscale molecular-simulation framework. We are currently in the process of porting our build to the conda-forge ecosystem and are running into issues since we currently vendor your package. (We bundle a copy of libcpuid that is compiled during our build, along with an appropriate attribution and thirdparty license file.)
Would you be willing to create and maintain a conda-forge package for libcpuid? This would remove the undesirable vendoring issue, and allow us to directly list libcpuid as a host requirement for the conda build process. (The package would then be pulled from conda-forge.)
Since your package is self-contained and easy to build, I don't think this would be too much work. Although I could create a package myself, I think it's better if it comes from the original developers since they are better aware of build issues on different platforms and maintenance is generally easier. That said, I'd be happy to help if you have questions or issues.
Here is a link to the the conda-forge staged recipes repository, which describes how to write and submit a build recipe. Our pull-request to this repository can be found here.
Cheers.
The text was updated successfully, but these errors were encountered: