[bazel] Put eigen in an external repo like bzlmod #8169
Conversation
This sets us up to use AOS, which wants @eigen to resolve, without introducing a second version or copy of eigen.
Those are good questions. I'll defer to Tyler on what the preferred answer is here. I suspect we should minimize changes from gradle short term. My main goal is to make the BUILD file and targets exposed match bcr as close as possible to make it interoperate. |
|
We currently copy all the thirdparty licenses into https://github.com/wpilibsuite/allwpilib/blob/main/ThirdPartyNotices.txt, but I like the idea of upstream_utils copying the licenses into their respective thirdparty folders better though, because it's more automatable. The library header Gradle artifacts we publish should have included the relevant license files as well. The artifact .zips are usually folder-wide, so upstream_utils copying in the license file should be sufficient. We don't require all the Eigen licenses because we only use a subset of the source, but including them all doesn't cost much space and means we don't have to worry about it again. |
|
It feels weird to put them in the include/ folder instead of at the thirdparty top level? Is the reason to do this because only the include/ folder gets installed? |
That is because the whole repo gets put in the include folder since it is header only, and the README's are expected to be in a specific spot relative to the headers by the upstream BUILD files. It was easier to embrace it than be unique. |
|
Yep, the eigen BCR module just takes the git repo and overlays the |
| Subject: [PATCH 3/3] Add build files from bzlmod for eigen | ||
|
|
||
| This makes it so our vendored version of eigen matches the same API as | ||
| the upstream eigen in bcr. |
There was a problem hiding this comment.
non-blocking: Might be worth leaving a link to the BCR upstream here?
5 participants
This sets us up to use AOS, which wants
@eigento resolve, without introducing a second version or copy of eigen.