Closed virtuald closed 1 year ago
I'm not sure how well this would work without breaking existing users. The FRCVision image builds all of WPILib from source, for example, so we'd need to be able to link to a system libwpiutil.
I don't see why there can't be two? It's not like they're in the same process.
In retrospect I'm not entirely sure what I was talking about.
As long as we continue to compile from source we'll probably be okay though. (Can't use the WPILib built libwpiutil since we need glibc 2.17 for conda-forge.)
I don't imagine robotpy-build would play well with conda's policy of not vendoring things, since we vendor pybind11 in robotpy-build (and have custom modifications at this time).
I just realised we deliberately exclude pyproject.toml from the sdist to avoid pip's build isolation behaviour in order to link against the system numpy. So unless we stop doing that we can't use robotpy-build here.
We could probably pin numpy to an old version at build time? That'd make building for the roboRIO even more annoying though.
Thinking more, that doesn't solve the problem of needing to import cv2 at build time on Windows to get the OpenCV version. In fact, that also doesn't sound like a nice problem to solve in robotpy-build either.
This will make it a lot more difficult for me to build this in WPILibPi (I compile it manually because builds within the VM are significantly slower, and it's not possible to cross-build with setup.py), but that's perhaps not a very compelling argument.
Fixed in #114
I don't see any downsides to this? Would make sense in the context of https://github.com/robotpy/robotpy-cscore/issues/86 also.