-
Notifications
You must be signed in to change notification settings - Fork 48
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
Consider using build tags instead of a bash script #125
Comments
Thanks for suggestion. I was wondering how would it be in combination with libtorch installation for CPU and GPU or it just handles gotch installation only? Feel free to PR. Please update installation guide in |
Hi @sugarme . I've started on this. I got libtorch installed for CPU and exported all the env vars, etc. I see that you automatically generated many of the bindings but didn't see much info on how that was done. I think maybe they just need to be re-generated? There's actually quite a few more failures than this but this should give you the idea:
|
From the log, I think gotch had actually compiled. Some tests failed as result of API changes from Please stick to libtorch 2.1.0 as the latest. I created a branch https://github.com/sugarme/gotch/tree/buildtag that you can PR for tracking. Cheers, |
Just sent you a PR that fixes the unit tests. I'll work on the build tag thing tomorrow. |
Thanks for the fix. |
I very much agree with this user's suggestion to use Tag to replace script production code. I plan to use this library in the production environment, but because this code is generated, there is no way to execute the script to replace this code using the company's platform, so I can only fork it out. Force lib.go to be hardcoded for CPU use. |
This is a really helpful project! I'm trying to get this working with our build but the install is very non-standard so I can just
go get
it and be done. We'd need to have every developer run thehttps://github.com/sugarme/gotch/releases/download/v0.9.0/setup-gotch.sh
script in order to build the rest of our code base, even if they're not working with the PyTorch parts of it.I took a look at the script and it seems like the bulk of what it's doing is changing the cgo compiler flags depending on if it's GPU or CPU. It seems like it might be easier for end users if you had two versions of
lib.go
and used build tags to determine which one gets built as described here. That way users could use your library like any other (assuming they have libtorch installed) and then all they'd have to do is add a-tags
option to theirgo build
command. For example, thego-sqlite3
library uses this approach.If you like the idea I could send you a PR for it.
The text was updated successfully, but these errors were encountered: