Add bazel build for libsbp c library #1224
Conversation
jungleraptor
changed the title
| @@ -13,4 +13,4 @@ swift_add_test(test-libsbp-cpp-legacy | |||
| swift_set_language_standards(test-libsbp-cpp-legacy) | |||
| swift_set_compile_options(test-libsbp-cpp-legacy ADD -Wno-error=array-bounds) | |||
|
|
|||
| file(COPY sbp_data/ DESTINATION ${CMAKE_CURRENT_BINARY_DIR}) | |||
| file(COPY sbp_data/ DESTINATION ${CMAKE_CURRENT_BINARY_DIR}/c/test/legacy/cpp/sbp_data/) | |||
There was a problem hiding this comment.
Bazel copies all files into a sandbox for building and execution. Data file dependencies are declared using the data attribute and are copied into the sandbox with the same path they have relative to the project root. This makes it so that the cmake version of the tests and the bazel version of the test have the files in the same place at runtime.
| @@ -97,11 +96,12 @@ class SbpStdioTest : public ::testing::Test { | |||
| }; | |||
|
|
|||
| TEST_F(SbpStdioTest, ReadsSbpFiles) { | |||
| EXPECT_EQ(num_entries_in_file("gnss_data.sbp"), 3); | |||
| EXPECT_EQ(num_entries_in_file("c/test/legacy/cpp/sbp_data/gnss_data.sbp"), 3); | |||
There was a problem hiding this comment.
Please replace magic number 3 or leave a comment describing why 3 entries in the file are expected.
Comments indicating what this test seeks to validate and documentation of num_entries_in_file would also be appreciated
There was a problem hiding this comment.
I'm just updating the path here. I don't know the context behind the magic numbers in these tests.
| } | ||
|
|
||
| TEST_F(SbpStdioTest, WritesToSbpFiles) { | ||
| write_to_file("gnss_data.sbp", "gnss_data_output.sbp"); | ||
| write_to_file("c/test/legacy/cpp/sbp_data/gnss_data.sbp", | ||
| "gnss_data_output.sbp"); | ||
| EXPECT_EQ(num_entries_in_file("gnss_data_output.sbp"), 9); |
There was a problem hiding this comment.
Ditto regarding magic numbers and documentation
Description
Adds support for building libsbp c library using bazel. Adds a submodules that contains common helper scritps.
@swift-nav/devinfra
API compatibility
Does this change introduce a API compatibility risk?
No API compatibility risks.