PSA: Do not attempt to just change GradleRIO version in project file to update to 2020

I’ve seen a few cases of this already, so I just wanted to put this out there. There were some internal changes in the GradleRIO configuration in C++ and Java for 2020. What this means is that you cannot just update a project to 2020 by changing the GradleRIO version number in the project file and expect it to work.

The only supported methods of upgrading are either creating a new project and copying the source files you want to keep over, or running through the 2020 VS Code Project Importer (It literally does a new project and copy internally anyway, in place upgrades are not supported).

If you attempt to manually upgrade, in C++ you will get failures in the build script, and in Java you’ll get failures at runtime because native dependencies will be missing.

Thanks!

4 Likes

Is there any way to rectify this without installing VSCode? Does every programmer on my team need to run the WPILib installer even though we predominantly code through IntelliJ?

Once the project is updated you can use it in IntelliJ. So assuming you have a common project you all are sharing, technically only one programmer needs to install the installer and do the project upgrade in vscode. Note the 2020 installer also installs all the dependencies you’ll need and updated tools/dashboards, so it’s good to install it anyway.

Just like last year, we still recommend at least having 1 system with VS Code in order to keep projects and dependencies up to date. You’re welcome to use alternate IDE’s, but the manual update steps would be confusing and very easy to screw up, so we do not publish manual updating instructions. The project importer only only needs to be ran once, and then the imported project can be shared among everyone else as said above.

Thanks for the replies guys. Are there any plans to modularize things so we’re not be forced to configure a system with unused dependencies?

We ran into a random thing where the NavX dependency searched for an opencv dependency. From the Kuailabs NavX page it seems like opencv is expected to be installed with WPILib. To me, that particular NavX issue is a vendor’s dependency creep issue - yet it brought to my attention a potential concern we’ve hit in the past related to multiple opencv installs.

This should have been fixed with NavX’s 2020 libraries. We noticed this with some 2019 libraries, and worked with vendors to fix this issue so they don’t have direct dependencies on anything included with WPILib.

For the unneeded dependencies thing, what do you mean? We have no plans to enable more granular installation, as we’ve seen in the past people will think they know what they want and that they don’t need something, when they do. Its much easier from a debugger perspective to take that out of the equation.

Does WPILib install opencv on my laptop as part of the install? I need a specific OpenCV version installed on my laptop for an unrelated project, and OpenCV on Windows has burned me in the past with specific environment configs being overwritten by later installs.

It installs OpenCV as a maven artifact, completely separate and undetectable from other installs. A WPILib build will only ever look there, and will never look at a system installed OpenCV.

We also explicitly make the maven coordinates be FRC specific in order to not interfere with anyone attempting to use some of the other opencv builds available on maven.

1 Like

I appreciate the effort that went into isolating opencv - I’ll keep working on this in a bit. Thanks!

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.