Hi,
I’m trying to port over the CommandScheduler from WPILib to use in a different project. This project will be likely running on a Raspberry PI, or some other ARM based SBC. The underlying framework will be using ROS, and therefore I’m using C++ or Python for most of the packages (I’m aware of third party support for Java in ROS, but I require the speed and the native ability of C++).
I’m running into some annoyances when moving over the CommandScheduler, namely, the dependencies that are required. I see in the source code that it utilizes LLVM for some utils, like hashmaps and vectors. I tried manually copying over the requisite files for specifically the command scheduler, but it’s pretty cumbersome when refactoring to fit my project. I’m assuming there’s an LLVM installer of some sort (though I haven’t been able to locate one, only the entire package with Clang included). If there is, where is it located, and what are the specific config options that I would need to use. If there isn’t, any suggestions?
Mentioning @Peter_Johnson as they may be the best person to answer this question.
While that’s doable, the command-based implementation effectively depends on the entirety of WPILib (e.g. it sits at the top of the entire library stack) and they probably don’t want to pull in everything.
That’s actually an idea I didn’t think of, thanks for the suggestion. I think I’ll likely stick with C++ as the CommandScheduler will still require pretty much every WPILib dependency regardless, and I’d rather have the execution speed of C++.
I see… is it manually refactored to work with the WPILib code structure? Not sure why but my VSCode editor isn’t offering any refactoring options, though C++ is known to not have the best options for that.
I’m not sure what you mean by refactored. We have a script (in upstream_utils) that copies the pieces we want from LLVM upstream and applies a bunch of patches, including changing the namespace from llvm to wpi. We didn’t want LLVM as a full dependency, we need it to compile cleanly with all of our warning flags etc, and we need to change the namespace to avoid runtime ABI conflicts, particularly on Linux where it’s possible for Mesa to pull in LLVM libraries.
oh, that makes a lot of sense. I’m entirely new to C++ (learning it specifically for this project), so I’m new to the concept of namespaces. Or, I guess more accurately, not the concept so much as the terminology. From my understanding, it’s essentially the same as packages in Java.
There is a Python script in upstream_utils that applies other changes in addition to the patches. You should not need to run it yourself, the resulting files are in git (which I linked previously).