Skip to content
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

Open
lohedges opened this issue Feb 23, 2021 · 6 comments
Open

conda-forge package #149

lohedges opened this issue Feb 23, 2021 · 6 comments

Comments

@lohedges
Copy link

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.

@anrieff
Copy link
Owner

anrieff commented Feb 24, 2021

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.

@lohedges
Copy link
Author

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

I think you may want to evaluate a build-process that downloads the libcpuid code from Github and build it directly.

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)

@chryswoods
Copy link

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.

@lohedges
Copy link
Author

lohedges commented Mar 9, 2021

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.

@lohedges
Copy link
Author

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.

@TheTumultuousUnicornOfDarkness
Copy link
Collaborator

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.
If you want to maintain this package on conda-forge, I can add a link on the README page (like the vcpkg package).

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.

ARM CPUs support is work in progress. It will be part of the next libcpuid release (e.g. v0.7.0).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants