-
I was trying to build allwpilib and robot code with CMake as an experiment, and while it mostly worked, there were some weird hiccups that I would like some help dealing with.
Looking at wpilibNewCommands' cmake-install.cmake file, I see this not far down:
Later on, I see a similar entry, but this time, it points to the build directory, not the source directory.
Since wpilibNewCommands has a
Which references the build directory, not the source directory. So that first snippet (the one that references the source directory) looks to be the problem. Something in wpilibNewCommands' CMake file is causing that rogue line which prevents an install. Note that when I'm not installing, and just building, there's no problem at all. I'm not familiar enough with CMake to figure out why wpilibNewCommands' cmake-install.cmake gets generated like that, and wpimath's is perfectly fine. My workaround was to drop the The next thing I ran into was that it seems like some of the libraries can't be used from an external CMake project. If you use the CMakeLists.txt from README-CMake and try to add Other than that, I love CMake builds! It builds so much faster than Gradle, so thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Yea, I noticed a few days ago that the wpilibNewCommands install was broken on Linux. Idk how to fix it. It doesn't seem to affect all of the targets though. wpiutil and wpimath install fine: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=wpimath |
Beta Was this translation helpful? Give feedback.
I think I fixed it. When I disabled Java, it worked fine, and so I compared the install command in the Java section to the one outside of it. The Java one currently is
install(FILES wpilibNewCommands-config.cmake DESTINATION ${wpilibNewCommands_config_dir})
while the other one isinstall(FILES ${WPILIB_BINARY_DIR}/wpilibNewCommands-config.cmake DESTINATION ${wpilibNewCommands_config_dir})
. I copied the non-Java install command and replaced the Java one, and it built from scratch with no problems. Looks like we really were telling CMake to use the source directory instead of the build directory. It should now refer to the build directory.