Multiple Gradle projects with the new WPILib version

wpilib
#1

During the 2018 offseason we moved our codebase from the old Ant build system to GradleRIO because we heard it’s becoming the new official build system. We use a two-project configuration (one for the main robot code and another one for utilities, configurations and other stuff), and after updating the build.gradle and settings.gradle files to the new plugin the vendor libraries won’t load. The installation works for new projects created with the wpilib project wizard, but not for our custom configuration.

The directory structure looks something like this:

<master>
-> settings.gradle
-> build.gradle
-> robot-code/
---> src/main/java/<...>
---> build.gradle
-> robot-config/
---> src/main/java/<...>
---> build.gradle

The settings.gradle file in the main folder matches the one in the wpilib template (with the addition of project definitions, aka include ':robot-code', ':robot-config'), as is the build.gradle file in the robot-code directory. The main build.gradle file just includes some maven repositories (JitPack, maven central, maven local) and some plugins (java, idea, eclipse) that both of the projects share.

Is there a problem with multiple Gradle projects when using wpilib nowadays?

#2

There isn’t a problem with multi-project Gradle. We do that with our code. Jaci also mentioned a way to manage vendordeps using the GradleRIO API.

#3

Gradlerio definitely supports multiple projects. The link above to Jaci has some info, and we have some fixes in the next release to fix a few issues we found.

Vscode I would have to go check. It definitely supports multiple projects, but I think the actual robot executable needs to be the root project. I can look into if this is still the case, and potentially look at fixing it. But editing and at least the deploy button would work just fine. Debugging might not, which is what I would need to look at.

#4

Just took a peek at your configuration - I’ll look into it! Thanks!

#5

@Thad_House so after looking in 1885’s configuration and the WPI plugin’s actions, I figured the problem out - the WPI plugin always uses the top project and not the “currently open” (meaning the project that holds the current open file) project. While this may be intended, I think there should be an option to specify in which projects the plugin should install vendor libraries, possibly in the build.gradle files or something like that.

#6

A change like that is possible, but is likely a bigger change then we would be comfortably doing during the season. If you can create an issue on the vscode-wpilib repo on our GitHub, I’ll definitely remember to look at it for next season.

#8

Sounds reasonable, will do

#9

The json files can be manually added, so it will still work, just require a bit manual work. Which since you’re doing multiproject anyway, you should be comfortable doing. If anything is completely broken in that scenario we’d like to know, but the vendor thing is easy enough to work around.

#10

Yea, VSCode makes some assumptions about the project in order to make it easier to use in most cases.

My team uses multiproject builds also (see: https://github.com/CurtinFRC/2019-DeepSpace ). On the 2019.2.1 release of GradleRIO and the VSCode Extension (out for release next week), simulation and debugging will properly support multiproject configurations.

For building, the WPILib VSCode build command works just fine, but will build all projects. For deploying, it will also work fine, but if you have multiple projects deploying you may be better served by popping open a terminal in vscode and running ./gradlew :project:deploy, which will only trigger on one project.

You can set GradleRIO to inherit vendor dependencies from the root project (wpi.deps.vendor.loadFrom(project(':'))), or you can manually copy them to the appropriate subproject.

#11

I’ve gotten multi-project build and deploy working great. I logged into ChiefDelphi to ask about debug configuration for a multi-project java system - glad to hear it’s being fixed!

The problem that the extension reported was that it couldn’t find the debuginfo.json file where it was looking (within the build folder under the master project root instead of under the appropriate sub-project). I couldn’t find a way to change the directory (e.g. “cwd”) for that debug configuration in launch.json. But I guess you know that already. :slight_smile: