[Build] Consider breaking up wpimath / geometry classes about allwpilib HOT 5 OPEN

If a the geometry classes along with a small subset of other base utility classes could be pulled out into its own library, build times should decrease.

The geometry classes depend on more than a small subset of code: Eigen, gcem, units, and wpiutil (which itself also contains a JSON library the geometry classes use). Making and managing separate libraries for these would be painful because our Gradle build system does no dependency tracking whatsoever; we have to list all transitive dependencies everywhere they're used, in the proper order.

This concept could go "all the way" like python does and basically break all of the folders into their own library

Given what I've said above, this seems unrealistic without an actual C++ package manager.

from allwpilib.

For my experiment, I made a wpilibmath-core which had eigen, gcem, units, and compiled sleipnir (required by ellipse) as its own library, and then could make a wpilibmath-geometry which depended on that and wpiutil.

I'm not super familiar with gradlerio / native tools, but this seems to have some dependency resolution built in.

from allwpilib.

It actually doesn't. Notice how all the transitive dependencies (e.g., ni_libraries) are listed there, not just what it directly depends on.

If you look through allwpilib's build.gradles, you'll also notice when it lists the wpimath library target, it also lists wpiutil. wpiutil is a dependency of wpimath, so it shouldn't need to be listed if depedency resolution worked.

from allwpilib.

Well, in so much as photonvision can do a one liner to get wpilib for example.

Yes, it has to list out transitive things, but in this case those deps would be well defined and could be added to the appropriate lists there. It also seems like something that could be modified to only have direct dependencies, and then recursed on to get the whole list.

from allwpilib.

It also seems like something that could be modified to only have direct dependencies, and then recursed on to get the whole list.

Someone who actually knows Gradle would have to write that, and @ThadHouse is pretty much the only Gradle wizard we have. He had to write a custom native library handler because Gradle's built-in native support sucks. None of our Maven artifacts include dependency information either.

from allwpilib.