Open ian-h-chamberlain opened 1 year ago
Nice research! I really like the idea of the version number being related (we could specify this to the user in the README). I'm not an expert on GitHub CI, so I don't know the actual limitations, but retrieving libctru
's version number should be as easy as:
sudo dkp-pacman -Si libctru | grep "Version\s*:\s\K.*" -o
As mentioned in https://github.com/rust3ds/ctru-rs/pull/133#issuecomment-1666050929 it sounds like we will probably move to a different versioning scheme than we had before, since that PR is now generating bindings on the fly instead of checking them into the repo. With those changes, I guess we can reset the ctru-sys
version (maybe to 0.2.0?) and require a minimum libctru
version somewhere in its build script.
I guess in principle, ctru
depends on the libctru
version more than ctru-sys
does, so perhaps it makes more sense to have the minimum libctru
version check in ctru
? Otherwise, we'd probably have a kind of indirect relationship from ctru
-> ctru-sys
-> libctru
, which maybe is fine but perhaps a direct relationship would be better.
On a semi-related note, I was debating whether it might be worth it to wrap up the bindgen stuff that @FenrirWolf did into a separate crate so we could reuse it for citro3d-sys
(and possibly citro2d
in the future)? I have been thinking about creating a common tools
type of repo to put common stuff in, like reusable Github Actions, and maybe something like this would make sense to put in there too. The downside of an extra crate would be yet another package to put on https://crates.io which is kind of a pain and maybe not worth it. Thoughts?
Originally posted by @Meziu in https://github.com/rust3ds/ctru-rs/discussions/97#discussioncomment-5295698
This is an interesting idea I hadn't considered before! For inspiration I thought I'd look at some other
sys
crates, and I found this which looks kinda interesting: https://gitlab.com/taricorp/llvm-sys.rs#llvm-compatibilityBasically, we could have a
ctru-sys
version21.2.x
for the current release, and bump the minor version whenever we regenerate bindings for a new patch oflibctru
. This would also allow us to make docgen improvements, etc. as a patch version on the crate instead.In the case of
llvm-sys
, they have some checks in place to verify library versions at build time. It might be harder to do that withlibctru
, since it's just a static library, but I was thinking there might be some ways to check it withdkp-pacman
/pacman
, and spit out a build warning if the versions mismatch, which would be displayed if the build failed (link errors etc).Opening this issue to track + discuss the possibilities.