-
Notifications
You must be signed in to change notification settings - Fork 20
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
Extract occt-sys
crate (repository) out of opencascade-sys
#86
Conversation
Is the separate repository needed? It feels a little heavy-handed to be honest. If it's not too difficult I'd like to keep everything together in one repo. |
To be clear I'm all in favor of reducing build times and having the OCCT crate be separate and possibly versioned according to the underlying C++ project. I just don't know what's driving the decision to have a separate repo, and I don't know if it's easy or hard to accomplish what you want to do if we keep all the code in one repo. |
I guess the main advantage of it being a separate repo rather than another sub-crate is the CI caching? Otherwise the other benefits could be obtained by separating Initially I thought that the separate repo would add an extra overhead to adding API (of which a fair amount is missing so is in flux) but I see that is not the case, since the bindings remain in The versioning of |
Can we accomplish the same caching by keeping the crate in this repo, but not in the cargo workspace? I suppose that would feel a little weird too. If it's a huge pain to keep it in the same repo then ultimately I'm okay with splitting it out, I just thought it would be nice to keep all code/issues/PRs together in one place. |
Yeah the main reason for separating into own repo is the CI caching. https://github.com/Swatinem/rust-cache specifically disables caching of workspace dependencies [1], and defends the decision in Swatinem/rust-cache#37 (comment) Agreed that a separate repo is suboptimal, but I said to myself that But thinking about it, I wonder whether linking the system opencascade dynamically (#87) isn't a better solution for CI build times. In this case we could still do the I could as well look into doing manual caching for Yet another option is have [1] They talk about workspace dependencies, but according to my tests, they exclude all path dependencies. I tested putting |
Could we potentially do the first part ("extracting part 1. into a separate crate, named occt-sys") but continue using the generic github actions cache instead of swatinem's rust-cache? If we don't imagine |
Yeah, let me keep occt-sys in this repo, and figure out CI caching later.
The current naive caching does not really work (even if you re-run the very same job right after, it still takes 30 minutes): the keys conflict between the clippy and test jobs, there is no Cargo.lock after checkout, so the key collapses to e.g.
Probably not that bad, but there is some work that Swatinem/rust-cache does that we'd have to replicate (as said above)
|
Also use Swatinem/rust-cache action to do Rust dependency caching (that exludes occt-sys).
f85f2da
to
9768516
Compare
I've pushed a version that keeps I kept the "naive GitHub cache" -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Sorry for the pushback on the separate repo. With occt-sys being quite simple now, I'm hopeful we can come up with a good caching mechanism for faster CI builds.
The
opencascade-sys
crate currently does basically 2 things:cmake
cxx
magic (has the Rust and C++ generated parts)Step 1 takes 30 minutes on CI and 5 minutes on my laptop, step 2 takes less than a minute on CI and seconds on my laptop.
Whenever the bindings (Rust or .hpp file) change, whole
opencascade-sys
needs to be rebuilt. OpenCascade cmake build does support incremental compilation (cmake
is super quick if you run in the the same build directory second time), butcargo
likes to change the build directory (target/debug/build/occt-sys-<hash>
), so we end up recompiling OpenCascade more often than not.Resolve this by extracting part 1. into a separate crate, named
occt-sys
(OpenCascade Technology, after upstream repo name).occt-sys
does the static build of OpenCascade and nothing extra: no bindings, doesn't even tell cargo to link its libraries.This PR goes even one step further: it extractsocct-sys
into its own repository (not just another workspace crate).~The second part of this PR is therefore in tonarino/occt-sys#1 (let's keep the high-level discussion here). ~
This part is up for discussion. Rationale:(biggest and triggering reason): https://github.com/Swatinem/rust-cache only caches the dependencies. Withocct-sys
in a separate repo,opencascade-rs
CI runs now take a couple of minutes rather than half an hour.opencasdar-rs
would no longer have a git submodule, simplifying setup a tiny bit (cargo handles submodules well when fetching git dependencies)occt-sys
is very simple an unopinionated, shall be reusable as a dependency for other Rust projects that want static OpenCascade build.Whenocct-sys
has multiple versions (its versioning scheme could even track the upstream OCCT version),opencascade-rs
would be free to choose what version it wants.