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.
User code:
- OpModeRobot used as the robot base class
- LinearOpMode and PeriodicOpMode are provided opmode base classes
- In Java, annotations can be used to automatically register opmode classes
Additional user code functionality:
- OpMode (string) is available in addition to the overall
auto/teleop/test robot mode
- OpMode does not indicate enable (enable/disable is still separate)
- The HAL API uses integer UIDs; these are exposed at the user API level
as well for faster checks
- User code creates opmodes on startup (these have name, category,
description, etc).
DS:
- DS will present opmode selection lists for auto and teleop for
match/practice. During a match, the DS will automatically activate the
selected opmode in the corresponding match period.
- For testing, an overall mode is selected (e.g. teleop/auto/test) and a
single opmode is selected
Future work:
- Command framework support/integration
- Python annotation support
- Unit tests (needs race-free DS sim updates)
- Porting of examples
Co-authored-by: Joseph Eng <91924258+KangarooKoala@users.noreply.github.com>
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
The deprecation message was:
```
The `archives` configuration added by the `base` plugin has been
deprecated and will be removed in Gradle 10.0.0. Adding artifacts to the
`archives` configuration will now result in a deprecation warning. If
you want the artifact built when running the `assemble` task, you should
add the artifact (or the task that produces it) as a dependency of the
`assemble` task directly.
val specialJar = tasks.register<Jar>("specialJar") {
archiveBaseName.set("special")
from("build/special")
}
tasks.named("assemble") {
dependsOn(specialJar)
}
```
I upgraded all plugins I could see except org.ysb33r.doxygen. 2.0 made
breaking changes, and I couldn't figure out how to migrate.
Most of the changes are for suppressing new linter purification rites.
```
> Task :wpilibcExamples:checkCommands
Script '/home/tav/frc/wpilib/allwpilib/shared/examplecheck.gradle': line 135
Invocation of Task.project at execution time has been deprecated. This will fail with an error in Gradle 10.0. This API is incompatible with the configuration cache, which will become the only mode supported by Gradle in a future release. Consult the upgrading guide for further information: https://docs.gradle.org/8.14.3/userguide/upgrading_version_7.html#task_project
at examplecheck_4wsg1s37eigy9vs5arzst20ga$_run_closure5$_closure16$_closure17.doCall$original(/home/tav/frc/wpilib/allwpilib/shared/examplecheck.gradle:135)
(Run with --stacktrace to get the full stack trace of this deprecation warning.)
```
Moving the project access outside the doLast block makes it occur at
confguration time instead.
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>
Gradle publishing does not capture all of the source files that are used during a build. This should get most of them, and get it equivalent to what bazel pushes out.
