Team2890/allwpilib
4
0
Fork 0
mirror of https://github.com/wpilibsuite/allwpilib synced 2026-06-30 02:31:44 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
3f0d7bc2c495bdf2a42e8d49e4ebb92c6fea18ce
allwpilib/wpimath/CMakeLists.txt

228 lines
7.6 KiB
CMake
Raw Normal View History

[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
project(wpimath)
include(SubDirList)
include(CompileWarnings)
include(AddTest)
[build] Add error message when downloading files in CMake (#5593) CMake's file(DOWNLOAD) function fails silently, leading to an error occurring due to a missing file later in the build. This fails quickly and produces a better error message.
2023-08-31 00:16:48 -04:00
include(DownloadAndCheck)
[wpiutil, ntcore] Add structured data support (#5391) This adds support for two serialization formats for complex data types: - Protobuf for complex objects with variable length internals that need forward and backward wire compatibility (lower speed, more flexible) - Raw struct (ByteBuffer-style) for fixed-length objects (higher speed, less flexible) Deserialization can be done either by creating a new object (for immutable objects) or overwriting the contents of an existing object (for mutable objects). Implementing classes should provide inner classes that implement the Protobuf or Struct interface (in Java) or specialize the wpi::Protobuf or wpi::Struct struct (in C++). It is possible for classes to implement both. If the class itself does not implement serialization, it's possible for third parties/users to provide an implementation instead. Uses the Google protobuf implementation for C++ and the QuickBuffers alternative protobuf implementation for Java.
2023-10-19 21:41:47 -07:00
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
file(
GLOB wpimath_jni_src
[wpimath] Disambiguate wpimath JNI functions (#6695) Each collection of JNI functions now has its own class.
2024-06-05 12:26:58 -07:00
src/main/native/cpp/jni/DAREJNI.cpp
src/main/native/cpp/jni/EigenJNI.cpp
src/main/native/cpp/jni/Exceptions.cpp
[wpimath] Refactor StateSpaceUtil into separate files (#8421) * Moved makeWhiteNoiseVector() to random.Normal.normal() * Moved isControllable() and isDetectable() to system.LinearSystemUtil * Renamed makeCostMatrix() to costMatrix() (Java) * Renamed makeCovarianceMatrix() to covarianceMatrix() (Java) * Renamed MakeCostMatrix() to CostMatrix() (C++) * Renamed MakeCovMatrix() to CovarianceMatrix() (C++) * Removed deprecated poseTo3dVector(), poseTo4dVector(), poseToVector() * Removed clampInputMaxMagnitude() * We don't use it, and Eigen has this functionality built in via `u = u.array().min(u_max.array()).max(u_min.array());` * Simplified implementation of desaturateInputVector()
2025-11-29 10:28:38 -08:00
src/main/native/cpp/jni/LinearSystemUtilJNI.cpp
[wpimath] Replace Pose2/3d.exp(Twist2/3d) with Pose2/3d.plus(Twist2/3d.exp()) (#8188) This better matches math notation.
2025-08-30 11:37:09 -07:00
src/main/native/cpp/jni/Transform3dJNI.cpp
src/main/native/cpp/jni/Twist3dJNI.cpp
[wpimath] Add Sleipnir Java bindings (#8236) The wrapper includes reverse mode autodiff, the Problem DSL, and the optimal control problem API. I wrote it by directly translating the upstream [API](https://github.com/SleipnirGroup/Sleipnir/tree/main/include/sleipnir) and [tests](https://github.com/SleipnirGroup/Sleipnir/tree/main/test) to Java (i.e., copy-paste-modify). I replaced the ArmFeedforward and Ellipse2d JNIs with implementations using the Sleipnir Java bindings. Switching dev binary JNIs to release by default sped up wpimath test runs from several minutes to 7 seconds.
2026-03-29 22:34:21 -07:00
src/main/native/cpp/jni/autodiff/GradientJNI.cpp
src/main/native/cpp/jni/autodiff/HessianJNI.cpp
src/main/native/cpp/jni/autodiff/JacobianJNI.cpp
src/main/native/cpp/jni/autodiff/VariableJNI.cpp
src/main/native/cpp/jni/autodiff/VariableMatrixJNI.cpp
src/main/native/cpp/jni/optimization/ProblemJNI.cpp
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
)
[wpiutil, ntcore] Add structured data support (#5391) This adds support for two serialization formats for complex data types: - Protobuf for complex objects with variable length internals that need forward and backward wire compatibility (lower speed, more flexible) - Raw struct (ByteBuffer-style) for fixed-length objects (higher speed, less flexible) Deserialization can be done either by creating a new object (for immutable objects) or overwriting the contents of an existing object (for mutable objects). Implementing classes should provide inner classes that implement the Protobuf or Struct interface (in Java) or specialize the wpi::Protobuf or wpi::Struct struct (in C++). It is possible for classes to implement both. If the class itself does not implement serialization, it's possible for third parties/users to provide an implementation instead. Uses the Google protobuf implementation for C++ and the QuickBuffers alternative protobuf implementation for Java.
2023-10-19 21:41:47 -07:00
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
# Java bindings
if(WITH_JAVA)
include(UseJava)
[build] Upgrade Maven dependencies (#8173)
2025-09-01 08:13:46 -07:00
if(NOT EXISTS "${WPILIB_BINARY_DIR}/wpimath/thirdparty/ejml/ejml-simple-0.44.0.jar")
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
set(BASE_URL "https://search.maven.org/remotecontent?filepath=")
set(JAR_ROOT "${WPILIB_BINARY_DIR}/wpimath/thirdparty/ejml")
message(STATUS "Downloading EJML jarfiles...")
[build] Organize cmake files (#6617)
2024-05-24 13:48:05 -04:00
download_and_check(
[build] Upgrade Maven dependencies (#8173)
2025-09-01 08:13:46 -07:00
"${BASE_URL}org/ejml/ejml-cdense/0.44.0/ejml-cdense-0.44.0.jar"
"${JAR_ROOT}/ejml-cdense-0.44.0.jar"
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
)
[build] Organize cmake files (#6617)
2024-05-24 13:48:05 -04:00
download_and_check(
[build] Upgrade Maven dependencies (#8173)
2025-09-01 08:13:46 -07:00
"${BASE_URL}org/ejml/ejml-core/0.44.0/ejml-core-0.44.0.jar"
"${JAR_ROOT}/ejml-core-0.44.0.jar"
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
)
[build] Organize cmake files (#6617)
2024-05-24 13:48:05 -04:00
download_and_check(
[build] Upgrade Maven dependencies (#8173)
2025-09-01 08:13:46 -07:00
"${BASE_URL}org/ejml/ejml-ddense/0.44.0/ejml-ddense-0.44.0.jar"
"${JAR_ROOT}/ejml-ddense-0.44.0.jar"
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
)
[build] Organize cmake files (#6617)
2024-05-24 13:48:05 -04:00
download_and_check(
[build] Upgrade Maven dependencies (#8173)
2025-09-01 08:13:46 -07:00
"${BASE_URL}org/ejml/ejml-dsparse/0.44.0/ejml-dsparse-0.44.0.jar"
"${JAR_ROOT}/ejml-dsparse-0.44.0.jar"
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
)
[build] Organize cmake files (#6617)
2024-05-24 13:48:05 -04:00
download_and_check(
[build] Upgrade Maven dependencies (#8173)
2025-09-01 08:13:46 -07:00
"${BASE_URL}org/ejml/ejml-fdense/0.44.0/ejml-fdense-0.44.0.jar"
"${JAR_ROOT}/ejml-fdense-0.44.0.jar"
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
)
[build] Organize cmake files (#6617)
2024-05-24 13:48:05 -04:00
download_and_check(
[build] Upgrade Maven dependencies (#8173)
2025-09-01 08:13:46 -07:00
"${BASE_URL}org/ejml/ejml-simple/0.44.0/ejml-simple-0.44.0.jar"
"${JAR_ROOT}/ejml-simple-0.44.0.jar"
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
)
[build] Organize cmake files (#6617)
2024-05-24 13:48:05 -04:00
download_and_check(
[build] Upgrade Maven dependencies (#8173)
2025-09-01 08:13:46 -07:00
"${BASE_URL}org/ejml/ejml-zdense/0.44.0/ejml-zdense-0.44.0.jar"
"${JAR_ROOT}/ejml-zdense-0.44.0.jar"
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
)
message(STATUS "All files downloaded.")
endif()
[wpiutil, ntcore] Add structured data support (#5391) This adds support for two serialization formats for complex data types: - Protobuf for complex objects with variable length internals that need forward and backward wire compatibility (lower speed, more flexible) - Raw struct (ByteBuffer-style) for fixed-length objects (higher speed, less flexible) Deserialization can be done either by creating a new object (for immutable objects) or overwriting the contents of an existing object (for mutable objects). Implementing classes should provide inner classes that implement the Protobuf or Struct interface (in Java) or specialize the wpi::Protobuf or wpi::Struct struct (in C++). It is possible for classes to implement both. If the class itself does not implement serialization, it's possible for third parties/users to provide an implementation instead. Uses the Google protobuf implementation for C++ and the QuickBuffers alternative protobuf implementation for Java.
2023-10-19 21:41:47 -07:00
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
file(GLOB EJML_JARS "${WPILIB_BINARY_DIR}/wpimath/thirdparty/ejml/*.jar")
Change Java JSON to Avaje Jsonb (#8721) Jackson is a very heavy library; it supports loads of features that we don't need, and historically has caused issues due to long class loading times (a little over 2 seconds to load AprilTagFieldLayout). This often manifests as a help request in the form of "my robot disables when I do X, but doesn't disable when doing X in subsequent attempts until code restart." While SC has brought down Jackson loading times significantly, with AprilTagFieldLayout loads taking only 330 milliseconds, that's still a rather long delay, and while libraries should handle any JSON loading ahead of time to prevent delays in auto/teleop, it would still be good to make the worst case better to reduce user frustration. Benchmarks indicate using [Avaje Jsonb](https://github.com/avaje/avaje-jsonb) to load AprilTagFieldLayout only takes ~70 ms, a fair chunk of which isn't actually in Avaje Jsonb (~4 ms is spent on using getResourceAsStream to retrieve the JSON file, ~8 ms is spent on just loading the AprilTag class and its dependencies). Note that all times listed are end-to-end, meaning nothing else was done except for the operation being benchmarked, and doing arithmetic on them can be flawed due to some classes being loaded twice, i.e., getResourceAsStream and `new AprilTag()` likely load some of the same JDK classes and so subtracting both from the Avaje Jsonb load time is likely slightly incorrect because class loading is being double counted. For our purposes, it's likely accurate enough and is mostly just for contextualization. Benchmarks were run on a Raspberry Pi CM5 with 2 GB of RAM. Source code for the [results](https://github.com/user-attachments/files/26471452/benchmark.txt) can be found in the "Fastjson2" commit (2456d15ca8ebd17635e607cd40bf8816e77869a1). Avaje Jsonb uses code generation via annotation processors to generate the classes needed to do JSON serde and uses service providers to find them, which will require downstream changes in robot projects, as the different service providers in each library must be merged together for Avaje Jsonb to function. We will use the Gradle shadow plugin, as its already used by the installer and therefore adds zero additional dependencies.
2026-04-11 02:21:00 -04:00
file(GLOB AVAJE_JARS "${WPILIB_BINARY_DIR}/wpiutil/thirdparty/avaje/*.jar")
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
file(GLOB QUICKBUF_JAR ${WPILIB_BINARY_DIR}/wpiutil/thirdparty/quickbuf/*.jar)
[wpiutil, ntcore] Add structured data support (#5391) This adds support for two serialization formats for complex data types: - Protobuf for complex objects with variable length internals that need forward and backward wire compatibility (lower speed, more flexible) - Raw struct (ByteBuffer-style) for fixed-length objects (higher speed, less flexible) Deserialization can be done either by creating a new object (for immutable objects) or overwriting the contents of an existing object (for mutable objects). Implementing classes should provide inner classes that implement the Protobuf or Struct interface (in Java) or specialize the wpi::Protobuf or wpi::Struct struct (in C++). It is possible for classes to implement both. If the class itself does not implement serialization, it's possible for third parties/users to provide an implementation instead. Uses the Google protobuf implementation for C++ and the QuickBuffers alternative protobuf implementation for Java.
2023-10-19 21:41:47 -07:00
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
set(CMAKE_JNI_TARGET true)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
[wpimath] Commit generated files (#5986)
2023-12-01 23:52:38 -05:00
file(GLOB_RECURSE JAVA_SOURCES src/main/java/*.java src/generated/main/java/*.java)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
add_jar(
wpimath_jar
${JAVA_SOURCES}
[wpimath] Make swerve and differential kinematics functions immutable (#8274) Originally started with just swerve, but expanded to diff and mecanum (docs only) for parity across the drivetrains. Return value checks are applied when possible to make migration easier and to error loudly if people forget. --------- Co-authored-by: Joseph Eng <91924258+KangarooKoala@users.noreply.github.com>
2026-04-17 00:23:32 -04:00
INCLUDE_JARS
wpiutil_jar
wpiunits_jar
wpiannotations_jar
${EJML_JARS}
${AVAJE_JARS}
${QUICKBUF_JAR}
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
OUTPUT_NAME wpimath
[build] Clean up CMake files (#6802) Explicitly list required components when using FindJava and FindJNI Consolidate find_package calls for Java, JNI, and OpenCV into the root CMakeLists.txt file Remove references to main_lib_dest Install missing generated headers Flatten some if statements Use LinkMacOSGUI macro instead of hand rolling it Stop installing OpenCV libraries and an extra ntcorejni library; OpenCV JAR will still be installed to make it easy to use Only print platform version on Windows Prevent GUI modules from being built when wpimath is off, which would otherwise cause a build failure Simplify build configuration checks Clean up fieldImages JAR creation Place built JARs in the same subdir as installed JARs Remove unnecessary JAR includes Remove extra directories in target_include_directories Improve CMake docs
2024-07-11 18:01:05 -04:00
OUTPUT_DIR ${WPILIB_BINARY_DIR}/${java_lib_dest}
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
GENERATE_NATIVE_HEADERS wpimath_jni_headers
)
[build] Organize cmake files (#6617)
2024-05-24 13:48:05 -04:00
set_property(TARGET wpimath_jar PROPERTY FOLDER "java")
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
[build] cmake: Export jars and clean up jar installs (#6014)
2023-12-06 21:28:38 -05:00
install_jar(wpimath_jar DESTINATION ${java_lib_dest})
install_jar_exports(TARGETS wpimath_jar FILE wpimath_jar.cmake DESTINATION share/wpimath)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
add_library(wpimathjni ${wpimath_jni_src})
wpilib_target_warnings(wpimathjni)
target_link_libraries(wpimathjni PUBLIC wpimath)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
set_property(TARGET wpimathjni PROPERTY FOLDER "libraries")
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
target_link_libraries(wpimathjni PRIVATE wpimath_jni_headers)
add_dependencies(wpimathjni wpimath_jar)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
install(TARGETS wpimathjni EXPORT wpimathjni)
[build] Add exports to CMake subprojects (#6505) This allows consuming allwpilib via FetchContent.
2024-04-10 22:04:22 -07:00
export(TARGETS wpimathjni FILE wpimathjni.cmake NAMESPACE wpimathjni::)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
endif()
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
if(WITH_JAVA_SOURCE)
include(UseJava)
[build] CMake: simplify source JAR creation and install (#6831) Bump required minimum CMake version to 3.21.
2024-07-15 18:12:41 -04:00
include(CreateSourceJar)
add_source_jar(
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
wpimath_src_jar
[build] CMake: simplify source JAR creation and install (#6831) Bump required minimum CMake version to 3.21.
2024-07-15 18:12:41 -04:00
BASE_DIRECTORIES
${CMAKE_CURRENT_SOURCE_DIR}/src/main/java
${CMAKE_CURRENT_SOURCE_DIR}/src/generated/main/java
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
OUTPUT_NAME wpimath-sources
[build] Clean up CMake files (#6802) Explicitly list required components when using FindJava and FindJNI Consolidate find_package calls for Java, JNI, and OpenCV into the root CMakeLists.txt file Remove references to main_lib_dest Install missing generated headers Flatten some if statements Use LinkMacOSGUI macro instead of hand rolling it Stop installing OpenCV libraries and an extra ntcorejni library; OpenCV JAR will still be installed to make it easy to use Only print platform version on Windows Prevent GUI modules from being built when wpimath is off, which would otherwise cause a build failure Simplify build configuration checks Clean up fieldImages JAR creation Place built JARs in the same subdir as installed JARs Remove unnecessary JAR includes Remove extra directories in target_include_directories Improve CMake docs
2024-07-11 18:01:05 -04:00
OUTPUT_DIR ${WPILIB_BINARY_DIR}/${java_lib_dest}
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
)
set_property(TARGET wpimath_src_jar PROPERTY FOLDER "java")
[build] CMake: simplify source JAR creation and install (#6831) Bump required minimum CMake version to 3.21.
2024-07-15 18:12:41 -04:00
install_jar(wpimath_src_jar DESTINATION ${java_lib_dest})
[build] Add CMake option to build Java sources jars (#5768)
2023-10-30 12:57:28 -04:00
endif()
[wpimath] Add Sleipnir (#6541) This is useful for solving quadratic programs.
2024-04-27 22:42:42 -07:00
file(
GLOB_RECURSE wpimath_native_src
src/main/native/cpp/*.cpp
src/main/native/thirdparty/sleipnir/src/*.cpp
)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
list(REMOVE_ITEM wpimath_native_src ${wpimath_jni_src})
[wpimath] Explicitly export wpimath symbols Co-authored-by: Tyler Veness <calcmogul@gmail.com>
2021-08-20 09:02:01 -07:00
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS FALSE)
Don't read protobuf static data across shared library lines directly (#6979) Reading exported data from shared objects on windows is broken. It requires __declspec(dllimport). However, this is problematic, as we use the same static libraries both from a shared and static context. So we can't just blindly apply dllimport. The linker should have caught this, as data members are exported in a different way. However, due to a bug in native-utils, data member symbols were exposed directly. However, interacting with those data member was completely broken. The only way we can really solve this is to just not use static data members. We're pretty good about this in WPILib itself. However, protobuf is absolutely terrible at this. There are a ton of inline functions that access global data. For the protobuf library itself, we can solve this easily enough. However, for the generated protobuf code, this is much more problematic. The member needed to bypass the global data is private. This means using just the stock protobuf code, this problem is not solvable. But, protobuf generated code has insertion points. Those insertion points let us add our own code into the generated code via a protoc plugin. And it just so happens that an insertion point exists to add extra public methodsto the generated protobuf header. There is also an insertion point to let us add to the cpp file. The methods we need are the getters, for unpacking protobufs. For any protobuf that has a message as a member, we generate a new wpi_x() getter (the existing one is just x(), where x is the field name). We then implement this in the cpp file. A trick we can use is in the cpp file, we can safely call the x() function, as the cpp file is in the same library as the global. Thus we can call that inline method, and not actually need to directly access any internal private state of the protobuf object. TL;DR, all protobuf classes that have messages as fields now have a wpi_x() accessor that must be used instead of x() if you want the code to work on windows. After wpilibsuite/native-utils#212, the bad code will fail to link, rather then just fail at runtime.
2024-08-21 07:53:20 -07:00
[wpiutil] Change C++ protobuf to nanopb (#7309) The Google C++ protobuf implementation has issues with dynamic linkage across DLL boundaries because it uses global variables. It also has a compile-time dependency because the protoc version must exactly match the libprotobuf version. Using nanopb with a customized generator fixes both of these issues. Co-authored-by: Gold856 <117957790+Gold856@users.noreply.github.com>
2024-11-07 22:42:50 -08:00
file(GLOB_RECURSE wpimath_protobuf_native_src src/generated/main/native/cpp/wpimath/protobuf/*.cpp)
Don't read protobuf static data across shared library lines directly (#6979) Reading exported data from shared objects on windows is broken. It requires __declspec(dllimport). However, this is problematic, as we use the same static libraries both from a shared and static context. So we can't just blindly apply dllimport. The linker should have caught this, as data members are exported in a different way. However, due to a bug in native-utils, data member symbols were exposed directly. However, interacting with those data member was completely broken. The only way we can really solve this is to just not use static data members. We're pretty good about this in WPILib itself. However, protobuf is absolutely terrible at this. There are a ton of inline functions that access global data. For the protobuf library itself, we can solve this easily enough. However, for the generated protobuf code, this is much more problematic. The member needed to bypass the global data is private. This means using just the stock protobuf code, this problem is not solvable. But, protobuf generated code has insertion points. Those insertion points let us add our own code into the generated code via a protoc plugin. And it just so happens that an insertion point exists to add extra public methodsto the generated protobuf header. There is also an insertion point to let us add to the cpp file. The methods we need are the getters, for unpacking protobufs. For any protobuf that has a message as a member, we generate a new wpi_x() getter (the existing one is just x(), where x is the field name). We then implement this in the cpp file. A trick we can use is in the cpp file, we can safely call the x() function, as the cpp file is in the same library as the global. Thus we can call that inline method, and not actually need to directly access any internal private state of the protobuf object. TL;DR, all protobuf classes that have messages as fields now have a wpi_x() accessor that must be used instead of x() if you want the code to work on windows. After wpilibsuite/native-utils#212, the bad code will fail to link, rather then just fail at runtime.
2024-08-21 07:53:20 -07:00
[wpiutil] Change C++ protobuf to nanopb (#7309) The Google C++ protobuf implementation has issues with dynamic linkage across DLL boundaries because it uses global variables. It also has a compile-time dependency because the protoc version must exactly match the libprotobuf version. Using nanopb with a customized generator fixes both of these issues. Co-authored-by: Gold856 <117957790+Gold856@users.noreply.github.com>
2024-11-07 22:42:50 -08:00
add_library(protobuf OBJECT ${wpimath_protobuf_native_src})
target_link_libraries(protobuf wpiutil)
Don't read protobuf static data across shared library lines directly (#6979) Reading exported data from shared objects on windows is broken. It requires __declspec(dllimport). However, this is problematic, as we use the same static libraries both from a shared and static context. So we can't just blindly apply dllimport. The linker should have caught this, as data members are exported in a different way. However, due to a bug in native-utils, data member symbols were exposed directly. However, interacting with those data member was completely broken. The only way we can really solve this is to just not use static data members. We're pretty good about this in WPILib itself. However, protobuf is absolutely terrible at this. There are a ton of inline functions that access global data. For the protobuf library itself, we can solve this easily enough. However, for the generated protobuf code, this is much more problematic. The member needed to bypass the global data is private. This means using just the stock protobuf code, this problem is not solvable. But, protobuf generated code has insertion points. Those insertion points let us add our own code into the generated code via a protoc plugin. And it just so happens that an insertion point exists to add extra public methodsto the generated protobuf header. There is also an insertion point to let us add to the cpp file. The methods we need are the getters, for unpacking protobufs. For any protobuf that has a message as a member, we generate a new wpi_x() getter (the existing one is just x(), where x is the field name). We then implement this in the cpp file. A trick we can use is in the cpp file, we can safely call the x() function, as the cpp file is in the same library as the global. Thus we can call that inline method, and not actually need to directly access any internal private state of the protobuf object. TL;DR, all protobuf classes that have messages as fields now have a wpi_x() accessor that must be used instead of x() if you want the code to work on windows. After wpilibsuite/native-utils#212, the bad code will fail to link, rather then just fail at runtime.
2024-08-21 07:53:20 -07:00
[wpiutil] Change C++ protobuf to nanopb (#7309) The Google C++ protobuf implementation has issues with dynamic linkage across DLL boundaries because it uses global variables. It also has a compile-time dependency because the protoc version must exactly match the libprotobuf version. Using nanopb with a customized generator fixes both of these issues. Co-authored-by: Gold856 <117957790+Gold856@users.noreply.github.com>
2024-11-07 22:42:50 -08:00
add_library(wpimath ${wpimath_native_src} $<TARGET_OBJECTS:protobuf>)
if(MSVC)
get_property(IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
set(CONFIG_SUFFIX "$<$<BOOL:${IS_MULTI_CONFIG}>:_$<CONFIG>>")
file(
[ci] Upgrade to wpiformat 2026.56 (#8666)
2026-03-13 13:15:01 -07:00
GENERATE OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/protobuf_objects${CONFIG_SUFFIX}.txt
[wpiutil] Change C++ protobuf to nanopb (#7309) The Google C++ protobuf implementation has issues with dynamic linkage across DLL boundaries because it uses global variables. It also has a compile-time dependency because the protoc version must exactly match the libprotobuf version. Using nanopb with a customized generator fixes both of these issues. Co-authored-by: Gold856 <117957790+Gold856@users.noreply.github.com>
2024-11-07 22:42:50 -08:00
CONTENT $<LIST:JOIN,$<TARGET_OBJECTS:protobuf>,\n>
[build] Make Protobuf optional in CMake build (#7061)
2024-09-12 23:44:19 -07:00
)
[wpiutil] Change C++ protobuf to nanopb (#7309) The Google C++ protobuf implementation has issues with dynamic linkage across DLL boundaries because it uses global variables. It also has a compile-time dependency because the protoc version must exactly match the libprotobuf version. Using nanopb with a customized generator fixes both of these issues. Co-authored-by: Gold856 <117957790+Gold856@users.noreply.github.com>
2024-11-07 22:42:50 -08:00
add_custom_command(
TARGET wpimath
PRE_LINK
COMMAND
cmake -E __create_def ${CMAKE_CURRENT_BINARY_DIR}/protobuf_exports${CONFIG_SUFFIX}.def
[build] CMake: fix Windows build when WITH_PROTOBUF is false (#7147)
2024-10-02 12:20:43 -04:00
${CMAKE_CURRENT_BINARY_DIR}/protobuf_objects${CONFIG_SUFFIX}.txt
[wpiutil] Change C++ protobuf to nanopb (#7309) The Google C++ protobuf implementation has issues with dynamic linkage across DLL boundaries because it uses global variables. It also has a compile-time dependency because the protoc version must exactly match the libprotobuf version. Using nanopb with a customized generator fixes both of these issues. Co-authored-by: Gold856 <117957790+Gold856@users.noreply.github.com>
2024-11-07 22:42:50 -08:00
)
target_link_options(
wpimath
PRIVATE
/DEF:$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/protobuf_exports${CONFIG_SUFFIX}.def>
)
[build] Make Protobuf optional in CMake build (#7061)
2024-09-12 23:44:19 -07:00
endif()
Don't read protobuf static data across shared library lines directly (#6979) Reading exported data from shared objects on windows is broken. It requires __declspec(dllimport). However, this is problematic, as we use the same static libraries both from a shared and static context. So we can't just blindly apply dllimport. The linker should have caught this, as data members are exported in a different way. However, due to a bug in native-utils, data member symbols were exposed directly. However, interacting with those data member was completely broken. The only way we can really solve this is to just not use static data members. We're pretty good about this in WPILib itself. However, protobuf is absolutely terrible at this. There are a ton of inline functions that access global data. For the protobuf library itself, we can solve this easily enough. However, for the generated protobuf code, this is much more problematic. The member needed to bypass the global data is private. This means using just the stock protobuf code, this problem is not solvable. But, protobuf generated code has insertion points. Those insertion points let us add our own code into the generated code via a protoc plugin. And it just so happens that an insertion point exists to add extra public methodsto the generated protobuf header. There is also an insertion point to let us add to the cpp file. The methods we need are the getters, for unpacking protobufs. For any protobuf that has a message as a member, we generate a new wpi_x() getter (the existing one is just x(), where x is the field name). We then implement this in the cpp file. A trick we can use is in the cpp file, we can safely call the x() function, as the cpp file is in the same library as the global. Thus we can call that inline method, and not actually need to directly access any internal private state of the protobuf object. TL;DR, all protobuf classes that have messages as fields now have a wpi_x() accessor that must be used instead of x() if you want the code to work on windows. After wpilibsuite/native-utils#212, the bad code will fail to link, rather then just fail at runtime.
2024-08-21 07:53:20 -07:00
[wpimath] Explicitly export wpimath symbols Co-authored-by: Tyler Veness <calcmogul@gmail.com>
2021-08-20 09:02:01 -07:00
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS TRUE)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
set_target_properties(wpimath PROPERTIES DEBUG_POSTFIX "d")
set_property(TARGET wpimath PROPERTY FOLDER "libraries")
[wpimath] Add Sleipnir (#6541) This is useful for solving quadratic programs.
2024-04-27 22:42:42 -07:00
target_compile_definitions(wpimath PRIVATE WPILIB_EXPORTS SLEIPNIR_EXPORTS)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
[wpiutil] Use C++23 stacktrace library on Windows (#6839) This lets us remove the unmaintained StackWalker library and its hacky upstream_utils script. @Gold856 reported that StackWalker gives blank stacktraces: https://discord.com/channels/176186766946992128/368993897495527424/1261940029287301150. They also reported an earlier version of this PR giving the following stacktrace instead: ``` D:\allwpilib\developerRobot\src\main\native\cpp\Robot.cpp(18): developerRobotCpp!Robot::RobotInit+0xB6 D:\allwpilib\wpilibc\src\main\native\cpp\TimedRobot.cpp(22): wpilibcd!frc::TimedRobot::StartCompetition+0x4F D:\allwpilib\wpilibc\src\main\native\include\frc\RobotBase.h(36): developerRobotCpp!frc::impl::RunRobot<Robot>+0xC8 D:\allwpilib\wpilibc\src\main\native\include\frc\RobotBase.h(106): developerRobotCpp!frc::StartRobot<Robot>+0x17E D:\allwpilib\developerRobot\src\main\native\cpp\Robot.cpp(60): developerRobotCpp!main+0xB D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(79): developerRobotCpp!invoke_main+0x39 D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288): developerRobotCpp!__scrt_common_main_seh+0x132 D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(331): developerRobotCpp!__scrt_common_main+0xE D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp(17): developerRobotCpp!mainCRTStartup+0xE KERNEL32!BaseThreadInitThunk+0x1D ntdll!RtlUserThreadStart+0x28 ```
2026-04-26 00:15:39 -07:00
target_compile_features(wpimath PUBLIC cxx_std_23)
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
if(MSVC)
[wpimath] Compile with UTF-8 encoding (#6111) This allows using Greek letters in variable names, which is helpful to make implemented equations follow their source paper more closely.
2023-12-29 21:56:06 -08:00
target_compile_options(wpimath PUBLIC /utf-8 /bigobj)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
endif()
wpilib_target_warnings(wpimath)
target_link_libraries(wpimath wpiutil)
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
if(NOT USE_SYSTEM_EIGEN)
install(
DIRECTORY src/main/native/thirdparty/eigen/include/
DESTINATION "${include_dest}/wpimath"
)
target_include_directories(
wpimath
SYSTEM
PUBLIC
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/src/main/native/thirdparty/eigen/include>
)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
else()
find_package(Eigen3 CONFIG REQUIRED)
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
target_link_libraries(wpimath Eigen3::Eigen)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
endif()
[wpimath] Add Sleipnir (#6541) This is useful for solving quadratic programs.
2024-04-27 22:42:42 -07:00
install(
[build] CMake: consolidate and clean up include dirs (#6927) Also remove the thirdparty AprilTag source directory from both CMake and Gradle header setup.
2024-08-11 02:39:17 -04:00
DIRECTORY src/main/native/thirdparty/gcem/include/ src/main/native/thirdparty/sleipnir/include/
[wpimath] Add Sleipnir (#6541) This is useful for solving quadratic programs.
2024-04-27 22:42:42 -07:00
DESTINATION "${include_dest}/wpimath"
)
target_include_directories(
wpimath
SYSTEM
PUBLIC
[build] CMake: consolidate and clean up include dirs (#6927) Also remove the thirdparty AprilTag source directory from both CMake and Gradle header setup.
2024-08-11 02:39:17 -04:00
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/src/main/native/thirdparty/gcem/include>
[wpimath] Add Sleipnir (#6541) This is useful for solving quadratic programs.
2024-04-27 22:42:42 -07:00
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/src/main/native/thirdparty/sleipnir/include>
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/src/main/native/thirdparty/sleipnir/src>
)
[build] cmake: Install wpimath nanopb headers (#7731)
2025-01-25 02:26:09 -05:00
install(
DIRECTORY src/generated/main/native/cpp/
DESTINATION "${include_dest}/wpimath"
FILES_MATCHING
PATTERN "*.h"
)
[build] Fix cmake install of thirdparty includes (#4741)
2022-11-29 21:58:38 -08:00
install(DIRECTORY src/main/native/include/ DESTINATION "${include_dest}/wpimath")
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
target_include_directories(
wpimath
PUBLIC
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/src/main/native/include>
[wpiutil] Change C++ protobuf to nanopb (#7309) The Google C++ protobuf implementation has issues with dynamic linkage across DLL boundaries because it uses global variables. It also has a compile-time dependency because the protoc version must exactly match the libprotobuf version. Using nanopb with a customized generator fixes both of these issues. Co-authored-by: Gold856 <117957790+Gold856@users.noreply.github.com>
2024-11-07 22:42:50 -08:00
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/src/generated/main/native/cpp>
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
$<INSTALL_INTERFACE:${include_dest}/wpimath>
)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
[build] cmake: Use default install location on windows for dlls (#5580)
2023-09-18 01:17:32 +02:00
install(TARGETS wpimath EXPORT wpimath)
[build] Add exports to CMake subprojects (#6505) This allows consuming allwpilib via FetchContent.
2024-04-10 22:04:22 -07:00
export(TARGETS wpimath FILE wpimath.cmake NAMESPACE wpimath::)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
configure_file(wpimath-config.cmake.in ${WPILIB_BINARY_DIR}/wpimath-config.cmake)
[build] Remove CMake flat install option (#5944)
2023-11-21 14:48:32 -05:00
install(FILES ${WPILIB_BINARY_DIR}/wpimath-config.cmake DESTINATION share/wpimath)
install(EXPORT wpimath DESTINATION share/wpimath)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
[build] Apply a formatter for CMake files (#5973)
2023-11-30 19:52:21 -05:00
if(WITH_TESTS)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
wpilib_add_test(wpimath src/test/native/cpp)
target_include_directories(wpimath_test PRIVATE src/test/native/include)
[upstream_utils] Add googletest (#6820)
2024-07-19 00:10:26 -04:00
target_link_libraries(wpimath_test wpimath googletest)
[wpimath] Move math functionality into new wpimath library (#2629) The wpimath library is a new library designed to separate the reusable math functionality from the common utility library (wpiutil) and the hardware-dependent library (wpilibc/j). Package names / include file names were NOT changed to minimize breakage. In a future year it would be good to revamp these for a more uniform user experience and to reduce the risk of accidental naming conflicts. While theoretically all of this functionality could be placed into wpiutil, several pieces of this library (e.g. DARE) are very time-consuming to compile, so it's nice to avoid this expense for users who only want cscore or ntcore. It also allows for easy future separation of build tasks vs number of workers on memory-constrained machines. This moves the following functionality from wpiutil into wpimath: - Eigen - ejml - Drake - DARE - wpiutil.math package (Matrix etc) - units And the following functionality from wpilibc/j into wpimath: - Geometry - Kinematics - Spline - Trajectory - LinearFilter - MedianFilter - Feed-forward controllers
2020-08-06 23:57:39 -07:00
endif()
Reference in New Issue Copy Permalink