Using MrcLib on the robot is going to be the plan for the future, to
make things easier.
MrcLib is how sim is supported going forward. The desktop version of
mrclib can act as a robot server.
This is set up where the mrclib interface is in shared code. On robot,
that is the only backend used. On desktop, a default sim backend is
used. However, the sim plugin can switch that to the real robot backend,
so the robot code will exactly look like a real robot.
This pulls in the `mrclib` maven repository as shared libraries, as a
prereq for #8858.
Alternative to #8869, which avoids the unnecessary lockfile entry. This
should be a one-to-one replacement for that PR.
Closes#8869
---------
Co-authored-by: PJ Reiniger <pj.reiniger@gmail.com>
The initial build file generation for robotpy projects was relatively
naive and purpose built to get `allwpilib` compiling, without supporting
all the available features.
This modifies the generation scripts to be able to support multiple
embedded libraries, which will be necessary for #8858, since `mrclib.so`
will need to be bundled along with the hal libraries. In addition some
cleanup was done to get the wheels looking more like what is in pypi.
I've been running my copybara syncs from this branch for a long time.
Finally deciding to PR it.
The biggest update was due to `mostrobotpy` absorbing the commands,
examples, and pyfrc libraries, but I also added in hooks to "enable" the
flakey `xfail` tests on the allwpilib side, and the ability to run
verbose or force push updates.
This lets us remove the unmaintained StackWalker library and its hacky
upstream_utils script.
@Gold856 reported that StackWalker gives blank stacktraces:
https://discord.com/channels/176186766946992128/368993897495527424/1261940029287301150.
They also reported an earlier version of this PR giving the following
stacktrace instead:
```
D:\allwpilib\developerRobot\src\main\native\cpp\Robot.cpp(18): developerRobotCpp!Robot::RobotInit+0xB6
D:\allwpilib\wpilibc\src\main\native\cpp\TimedRobot.cpp(22): wpilibcd!frc::TimedRobot::StartCompetition+0x4F
D:\allwpilib\wpilibc\src\main\native\include\frc\RobotBase.h(36): developerRobotCpp!frc::impl::RunRobot<Robot>+0xC8
D:\allwpilib\wpilibc\src\main\native\include\frc\RobotBase.h(106): developerRobotCpp!frc::StartRobot<Robot>+0x17E
D:\allwpilib\developerRobot\src\main\native\cpp\Robot.cpp(60): developerRobotCpp!main+0xB
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(79): developerRobotCpp!invoke_main+0x39
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288): developerRobotCpp!__scrt_common_main_seh+0x132
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(331): developerRobotCpp!__scrt_common_main+0xE
D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp(17): developerRobotCpp!mainCRTStartup+0xE
KERNEL32!BaseThreadInitThunk+0x1D
ntdll!RtlUserThreadStart+0x28
```
There were complaints about no patch files being created from CI when
the examples pre-gen fails for people who don't build with bazel. This
adds a new action step to run just the non-robotpy pregen.
I also added an argument to the diff tests to make it a unified diff,
which might make it easier to hand fix.
This hooks up the bazel build to the robotpyExamples. It can use the
(formly pyfrc or whatever) automatic unit tests for an example, as well
as exposing the ability to run the example in simulation, with or
without `halsim_gui` with a command such as `bazel run
//robotpyExamples:AddressableLED-sim`
This required building and using wheels instead of just a normal
`py_library`, so that things like `ENTRY_POINTS` can be used. I took a
bare bones approach to building and naming the wheels (for example the
native ones don't have the OS info or python version in them, so they
wouldn't be suitable publish to pypi, but that can always be updated
later.
This anecdotally fixes a problem that occurs when building with bzlmod.
At least for me this fixes the problem, and now that there is a function
for it it can be easier to deal with any other special casing that needs
to happen (windows, remote execution, etc). It is still a bit naive, but
should fix the major problem at the moment.
These are the scripts I've been using to sync between mostrobotpy and
here. I debated putting it in the "source of truth" that is
`mostrobotpy` , but I think it makes more sense here since it already
has bazel set up, and I've also recently added the ability to sync the
`commands-v2` repository, so having it all in one copybara script makes
sense.
This includes a helper python script to make it a little bit easier to
run.
Fixes#8386
Was already working on this when more people started hitting issues so I
prioritized getting this PR up. This updates the wrapper script to look
for the 3 biggest categories of "everything should be fine if you run
this step first" tool failures.
Co-authored-by: Gold856 <117957790+Gold856@users.noreply.github.com>
Co-authored-by: David Vo <auscompgeek@users.noreply.github.com>
* [bazel] Package headers in ntcoreffi correctly
The original package includes headers from ntcore and wpiutil, so
include those too.
* Merge in new 2027
This pulls down the prebuilt ceres libraries and uses them with Bazel to
build and test wpical.
Do note that bazel looks up artifacts used for testing differently than
the other build systems. It wants you to use its runfiles API to find
the dependencies reliably. Add a function to look up the paths for
files, and use runfiles only when building with Bazel to maintain
compatibility with other languages.
Signed-off-by: Austin Schuh <austin.linux@gmail.com>
I could have sworn that we were only splitting debug symbols on x86.
The most recent tests I have done suggest that is backwards. This is
easy to reconfigure later if needed.
Signed-off-by: Austin Schuh <austin.linux@gmail.com>
This adds shortcuts for static only, shared only, and binary projects.
The end result is that it is pretty easy from here to publish all the
arifacts needed.
This follows the gradle build accurately. Gradle copies debug symbols
into a second file (libfoo.so.debug) and links it back into the .so
file. Disable this behavior when gradle doesn't do it today.
Also, name everything correctly. When building debug builds, most
libraries get a 'd' at the end of them. Do that here too.
wpimath otherwise quickly gets too many symbols. Instead, gradle
exports only some of the symbols from protobuf files automatically, and
then manually exports the math operations. Do that here too.
Signed-off-by: Austin Schuh <austin.linux@gmail.com>
