2020-08-06 23:57:39 -07:00
|
|
|
project(wpimath)
|
|
|
|
|
|
|
|
|
|
include(SubDirList)
|
|
|
|
|
include(CompileWarnings)
|
|
|
|
|
include(AddTest)
|
2023-10-19 21:41:47 -07:00
|
|
|
|
2023-11-30 19:52:21 -05:00
|
|
|
file(
|
|
|
|
|
GLOB wpimath_jni_src
|
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
|
2025-11-29 10:28:38 -08:00
|
|
|
src/main/native/cpp/jni/LinearSystemUtilJNI.cpp
|
2025-08-30 11:37:09 -07:00
|
|
|
src/main/native/cpp/jni/Transform3dJNI.cpp
|
|
|
|
|
src/main/native/cpp/jni/Twist3dJNI.cpp
|
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
|
2023-11-30 19:52:21 -05:00
|
|
|
)
|
2023-10-19 21:41:47 -07:00
|
|
|
|
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
|
|
|
|
|
)
|
2020-08-06 23:57:39 -07:00
|
|
|
list(REMOVE_ITEM wpimath_native_src ${wpimath_jni_src})
|
|
|
|
|
|
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
|
|
|
|
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
|
|
|
|
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
|
|
|
|
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(
|
2026-03-13 13:15:01 -07:00
|
|
|
GENERATE OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/protobuf_objects${CONFIG_SUFFIX}.txt
|
2024-11-07 22:42:50 -08:00
|
|
|
CONTENT $<LIST:JOIN,$<TARGET_OBJECTS:protobuf>,\n>
|
2024-09-12 23:44:19 -07:00
|
|
|
)
|
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
|
2024-10-02 12:20:43 -04:00
|
|
|
${CMAKE_CURRENT_BINARY_DIR}/protobuf_objects${CONFIG_SUFFIX}.txt
|
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>
|
|
|
|
|
)
|
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
|
|
|
|
2021-08-20 09:02:01 -07:00
|
|
|
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS TRUE)
|
2020-08-06 23:57:39 -07:00
|
|
|
set_target_properties(wpimath PROPERTIES DEBUG_POSTFIX "d")
|
|
|
|
|
|
|
|
|
|
set_property(TARGET wpimath PROPERTY FOLDER "libraries")
|
2024-04-27 22:42:42 -07:00
|
|
|
target_compile_definitions(wpimath PRIVATE WPILIB_EXPORTS SLEIPNIR_EXPORTS)
|
2020-08-06 23:57:39 -07:00
|
|
|
|
2026-04-26 00:15:39 -07:00
|
|
|
target_compile_features(wpimath PUBLIC cxx_std_23)
|
2023-11-30 19:52:21 -05:00
|
|
|
if(MSVC)
|
2023-12-29 21:56:06 -08:00
|
|
|
target_compile_options(wpimath PUBLIC /utf-8 /bigobj)
|
2020-08-06 23:57:39 -07:00
|
|
|
endif()
|
|
|
|
|
wpilib_target_warnings(wpimath)
|
|
|
|
|
target_link_libraries(wpimath wpiutil)
|
|
|
|
|
|
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>
|
|
|
|
|
)
|
2020-08-06 23:57:39 -07:00
|
|
|
else()
|
|
|
|
|
find_package(Eigen3 CONFIG REQUIRED)
|
2023-11-30 19:52:21 -05:00
|
|
|
target_link_libraries(wpimath Eigen3::Eigen)
|
2020-08-06 23:57:39 -07:00
|
|
|
endif()
|
|
|
|
|
|
2024-04-27 22:42:42 -07:00
|
|
|
install(
|
2024-08-11 02:39:17 -04:00
|
|
|
DIRECTORY src/main/native/thirdparty/gcem/include/ src/main/native/thirdparty/sleipnir/include/
|
2024-04-27 22:42:42 -07:00
|
|
|
DESTINATION "${include_dest}/wpimath"
|
|
|
|
|
)
|
|
|
|
|
target_include_directories(
|
|
|
|
|
wpimath
|
|
|
|
|
SYSTEM
|
|
|
|
|
PUBLIC
|
2024-08-11 02:39:17 -04:00
|
|
|
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/src/main/native/thirdparty/gcem/include>
|
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>
|
|
|
|
|
)
|
|
|
|
|
|
2025-01-25 02:26:09 -05:00
|
|
|
install(
|
|
|
|
|
DIRECTORY src/generated/main/native/cpp/
|
|
|
|
|
DESTINATION "${include_dest}/wpimath"
|
|
|
|
|
FILES_MATCHING
|
|
|
|
|
PATTERN "*.h"
|
|
|
|
|
)
|
2022-11-29 21:58:38 -08:00
|
|
|
install(DIRECTORY src/main/native/include/ DESTINATION "${include_dest}/wpimath")
|
2023-11-30 19:52:21 -05:00
|
|
|
target_include_directories(
|
|
|
|
|
wpimath
|
|
|
|
|
PUBLIC
|
|
|
|
|
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/src/main/native/include>
|
2024-11-07 22:42:50 -08:00
|
|
|
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/src/generated/main/native/cpp>
|
2023-11-30 19:52:21 -05:00
|
|
|
$<INSTALL_INTERFACE:${include_dest}/wpimath>
|
|
|
|
|
)
|
2020-08-06 23:57:39 -07:00
|
|
|
|
2023-09-18 01:17:32 +02:00
|
|
|
install(TARGETS wpimath EXPORT wpimath)
|
2024-04-10 22:04:22 -07:00
|
|
|
export(TARGETS wpimath FILE wpimath.cmake NAMESPACE wpimath::)
|
2020-08-06 23:57:39 -07:00
|
|
|
|
2023-11-30 19:52:21 -05:00
|
|
|
configure_file(wpimath-config.cmake.in ${WPILIB_BINARY_DIR}/wpimath-config.cmake)
|
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)
|
2020-08-06 23:57:39 -07:00
|
|
|
|
2023-11-30 19:52:21 -05:00
|
|
|
if(WITH_TESTS)
|
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)
|
2024-07-19 00:10:26 -04:00
|
|
|
target_link_libraries(wpimath_test wpimath googletest)
|
2020-08-06 23:57:39 -07:00
|
|
|
endif()
|