-
Notifications
You must be signed in to change notification settings - Fork 186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Combine the tiledb_shared
and tiledb_static
CMake targets.
#4528
Conversation
This pull request has been linked to Shortcut Story #36838: Combine the tiledb_shared and tiledb_static CMake targets.. |
tiledb_shared
and tiledb_static
CMake targets.
We run out of disk or memory when statically linking the Core to the examples. 🥲 |
116afef
to
8b60957
Compare
047ad9b
to
b332b87
Compare
Fixes segfaults when running it with statically linking to TileDB.
Prevents out of disk errors on CI.
be2c71a
to
4a0ea34
Compare
This comment was marked as resolved.
This comment was marked as resolved.
When we initialize the AWS SDK on Linux, it also initializes s2n, which reads from `/dev/urandom` as part of it. However, the call to `read`, gets resolved to the `read()` function of our example. The example tries to recursively initialize the AWS SDK, but since `std::call_once` is not always reentrant, it deadlocks.
The timeout in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly good. Some documentation issues and user interface.
A couple of correctness issues:
- The default linkage needs to be explicitly set in
tiledb/CMakeLists.txt
if it's not set on the command line. The bootstrap scripts should still set the option explicitly for good auditability. Nevertheless, if the options on CMake command line aren't right, there needs to be a check and an informative error message. - What looks like an incorrect placement of a script status variable after adding an intervening line.
bootstrap
Outdated
--enable-static-tiledb enables building TileDB as a static library (this is the default) | ||
--enable-shared-tiledb enables building TileDB as a shared library |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a small point, but I would prefer this option as linkage=static
or linkage=shared
.
What you've got here is has no error checking (can't do both at once like the option structure might imply) and is overly verbose.
cmake/inputs/Config.cmake.in
Outdated
@@ -1,16 +1,17 @@ | |||
# | |||
# This file attempts to locate the TileDB library. If found, the following | |||
# imported targets are created: | |||
# - TileDB::tiledb_shared | |||
# - TileDB::tiledb_static | |||
# - TileDB::tiledb |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know what this target is from this documentation. Same, different, what?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added documentation that TileDB::tiledb
is present always.
examples/c_api/vfs.c
Outdated
// Should be static to avoid collision with the write syscall. | ||
static void write() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be clearer to rename the functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renamed.
scripts/run-nix-examples.sh
Outdated
$TestAppDir/$exampleexe; | ||
# Remove the executable after running it to prevent disk | ||
# space exhaustion when statically linking to tiledb. | ||
rm $TestAppDir/$exampleexe | ||
status=$? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't the status be checked before the added rm
command?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, reordered. Thanks!
cmake --build ${BaseDir}/tiledb --target ${exampleexe} | ||
echo $TestAppDir/$exampleexe | ||
$TestAppDir/$exampleexe; | ||
rm $TestAppDir/$exampleexe | ||
status=$? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also here
@@ -21,7 +21,7 @@ option(TILEDB_ASSERTIONS "Build with assertions enabled (default off for release | |||
option(TILEDB_CPP_API "Enables building of the TileDB C++ API." ON) | |||
option(TILEDB_CMAKE_IDE "(Used for CLion builds). Disables superbuild and sets the EP install dir." OFF) | |||
option(TILEDB_STATS "Enables internal TileDB statistics gathering." ON) | |||
option(TILEDB_STATIC "Enables building TileDB as a static library." OFF) | |||
option(BUILD_SHARED_LIBS "Enables building TileDB as a shared library." OFF) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just as in the bootstrap scripts, this would be better as a "static" or "shared" rather than boolean.
See https://stackoverflow.com/questions/8709877/cmake-string-options for how to do this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BUILD_SHARED_LIBS
is a standard CMake variable. I don't think it's a good idea to specify linkage in a different way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BUILD_SHARED_LIBS
is a standard CMake variable.
OK.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Restores default behavior to prior to #4528. Supersedes #4560. Fixes TileDB-Inc/TileDB-MariaDB#294 Fixes TileDB-Inc/TileDB-CSharp#339 Fixes TileDB-Inc/TileDB-CSharp#340 Fixes TileDB-Inc/TileDB-CSharp#341 --- TYPE: BUILD DESC: `BUILD_SHARED_LIBS` is enabled by default.
#4528 introduced a single `TileDB::tiledb`exported CMake target for TileDB with either static or dynamic linkage. For compatibility with previous versions, the targets `TileDB::tiledb_shared` or `TileDB::tiledb_static` were also defined depending on the linkage, as `ALIAS`es to `TileDB::tiledb`. As it turns out however, we cannot use `ALIAS` targets, because they are always declared in the global scope prior to CMake 3.18 and if `find_package(TileDB)` is not called in the top-level `CMakeLists.txt` file, it will fail with `add_library cannot create ALIAS target "TileDB::tiledb_shared" because target "TileDB::tiledb" is imported but not globally visible.`. Nor can we switch to using `IMPORTED INTERFACE` targets and linking them to `TileDB::tiledb`, because it would bring a minor breaking change[^1]. Because `TileDB::tiledb_shared` would become an `INTERFACE` library, it does not have an `IMPORTED_LOCATION` anymore, which would cause [calls to `install_target_libs(TileDB::tiledb_shared)`](https://github.com/TileDB-Inc/TileDB-VCF/blob/5bcc79b07935ac540c56bf6ed9ee0f5d60bf247e/libtiledbvcf/cmake/Modules/FindTileDB_EP.cmake#L121) to fail. Thankfully there is another solution. We set the [`EXPORT_NAME`](https://cmake.org/cmake/help/latest/prop_tgt/EXPORT_NAME.html) of the `tiledb` target to either `tiledb_shared` or `tiledb_static` depending on the linkage, and define `TileDB::tiledb` as an `IMPORTED INTERFACE` target[^2] to the linkage-specific target. This maintains full compatibility. [^1]: Something similar is the "breaking build system change" I talked about in #4408 (comment). After removing the `install_target_libs` calls from this repository, the change in Curl did not afffect us and we could update much more easily. [^2]: In this opposite case the unified target _must_ be an `IMPORTED INTERFACE`. We cannot get the `IMPORTED_LOCATION` of `TileDB::tiledb`, but since the target is new this is not a breaking change. --- TYPE: BUILD DESC: Fix importing TileDB in CMake versions prior to 3.18.
#4528 introduced a single `TileDB::tiledb`exported CMake target for TileDB with either static or dynamic linkage. For compatibility with previous versions, the targets `TileDB::tiledb_shared` or `TileDB::tiledb_static` were also defined depending on the linkage, as `ALIAS`es to `TileDB::tiledb`. As it turns out however, we cannot use `ALIAS` targets, because they are always declared in the global scope prior to CMake 3.18 and if `find_package(TileDB)` is not called in the top-level `CMakeLists.txt` file, it will fail with `add_library cannot create ALIAS target "TileDB::tiledb_shared" because target "TileDB::tiledb" is imported but not globally visible.`. Nor can we switch to using `IMPORTED INTERFACE` targets and linking them to `TileDB::tiledb`, because it would bring a minor breaking change[^1]. Because `TileDB::tiledb_shared` would become an `INTERFACE` library, it does not have an `IMPORTED_LOCATION` anymore, which would cause [calls to `install_target_libs(TileDB::tiledb_shared)`](https://github.com/TileDB-Inc/TileDB-VCF/blob/5bcc79b07935ac540c56bf6ed9ee0f5d60bf247e/libtiledbvcf/cmake/Modules/FindTileDB_EP.cmake#L121) to fail. Thankfully there is another solution. We set the [`EXPORT_NAME`](https://cmake.org/cmake/help/latest/prop_tgt/EXPORT_NAME.html) of the `tiledb` target to either `tiledb_shared` or `tiledb_static` depending on the linkage, and define `TileDB::tiledb` as an `IMPORTED INTERFACE` target[^2] to the linkage-specific target. This maintains full compatibility. [^1]: Something similar is the "breaking build system change" I talked about in #4408 (comment). After removing the `install_target_libs` calls from this repository, the change in Curl did not afffect us and we could update much more easily. [^2]: In this opposite case the unified target _must_ be an `IMPORTED INTERFACE`. We cannot get the `IMPORTED_LOCATION` of `TileDB::tiledb`, but since the target is new this is not a breaking change. --- TYPE: BUILD DESC: Fix importing TileDB in CMake versions prior to 3.18. (cherry picked from commit ad0371f)
#4528 introduced a single `TileDB::tiledb`exported CMake target for TileDB with either static or dynamic linkage. For compatibility with previous versions, the targets `TileDB::tiledb_shared` or `TileDB::tiledb_static` were also defined depending on the linkage, as `ALIAS`es to `TileDB::tiledb`. As it turns out however, we cannot use `ALIAS` targets, because they are always declared in the global scope prior to CMake 3.18 and if `find_package(TileDB)` is not called in the top-level `CMakeLists.txt` file, it will fail with `add_library cannot create ALIAS target "TileDB::tiledb_shared" because target "TileDB::tiledb" is imported but not globally visible.`. Nor can we switch to using `IMPORTED INTERFACE` targets and linking them to `TileDB::tiledb`, because it would bring a minor breaking change[^1]. Because `TileDB::tiledb_shared` would become an `INTERFACE` library, it does not have an `IMPORTED_LOCATION` anymore, which would cause [calls to `install_target_libs(TileDB::tiledb_shared)`](https://github.com/TileDB-Inc/TileDB-VCF/blob/5bcc79b07935ac540c56bf6ed9ee0f5d60bf247e/libtiledbvcf/cmake/Modules/FindTileDB_EP.cmake#L121) to fail. Thankfully there is another solution. We set the [`EXPORT_NAME`](https://cmake.org/cmake/help/latest/prop_tgt/EXPORT_NAME.html) of the `tiledb` target to either `tiledb_shared` or `tiledb_static` depending on the linkage, and define `TileDB::tiledb` as an `IMPORTED INTERFACE` target[^2] to the linkage-specific target. This maintains full compatibility. [^1]: Something similar is the "breaking build system change" I talked about in #4408 (comment). After removing the `install_target_libs` calls from this repository, the change in Curl did not afffect us and we could update much more easily. [^2]: In this opposite case the unified target _must_ be an `IMPORTED INTERFACE`. We cannot get the `IMPORTED_LOCATION` of `TileDB::tiledb`, but since the target is new this is not a breaking change. --- TYPE: BUILD DESC: Fix importing TileDB in CMake versions prior to 3.18. (cherry picked from commit ad0371f)
#4528 introduced a single `TileDB::tiledb`exported CMake target for TileDB with either static or dynamic linkage. For compatibility with previous versions, the targets `TileDB::tiledb_shared` or `TileDB::tiledb_static` were also defined depending on the linkage, as `ALIAS`es to `TileDB::tiledb`. As it turns out however, we cannot use `ALIAS` targets, because they are always declared in the global scope prior to CMake 3.18 and if `find_package(TileDB)` is not called in the top-level `CMakeLists.txt` file, it will fail with `add_library cannot create ALIAS target "TileDB::tiledb_shared" because target "TileDB::tiledb" is imported but not globally visible.`. Nor can we switch to using `IMPORTED INTERFACE` targets and linking them to `TileDB::tiledb`, because it would bring a minor breaking change[^1]. Because `TileDB::tiledb_shared` would become an `INTERFACE` library, it does not have an `IMPORTED_LOCATION` anymore, which would cause [calls to `install_target_libs(TileDB::tiledb_shared)`](https://github.com/TileDB-Inc/TileDB-VCF/blob/5bcc79b07935ac540c56bf6ed9ee0f5d60bf247e/libtiledbvcf/cmake/Modules/FindTileDB_EP.cmake#L121) to fail. Thankfully there is another solution. We set the [`EXPORT_NAME`](https://cmake.org/cmake/help/latest/prop_tgt/EXPORT_NAME.html) of the `tiledb` target to either `tiledb_shared` or `tiledb_static` depending on the linkage, and define `TileDB::tiledb` as an `IMPORTED INTERFACE` target[^2] to the linkage-specific target. This maintains full compatibility. [^1]: Something similar is the "breaking build system change" I talked about in #4408 (comment). After removing the `install_target_libs` calls from this repository, the change in Curl did not afffect us and we could update much more easily. [^2]: In this opposite case the unified target _must_ be an `IMPORTED INTERFACE`. We cannot get the `IMPORTED_LOCATION` of `TileDB::tiledb`, but since the target is new this is not a breaking change. --- TYPE: BUILD DESC: Fix importing TileDB in CMake versions prior to 3.18. (cherry picked from commit ad0371f)
SC-36838
This PR combines the
tiledb_shared
andtiledb_static
CMake targets into atiledb
target whose linkage is determined by theBUILD_SHARED_LIBS
variable. This approach has several advantages:TileDB::tiledb
CMake target that links to TileDB either statically or dynamically, depending on how TileDB was built.TileDB::tiledb_static
andTileDB::tiledb_shared
targets are retained for compatibility.The
TILEDB_STATIC
option was removed and replaced byBUILD_SHARED_LIBS
. The bootstrap scripts were updated accordingly.TYPE: IMPROVEMENT
DESC: Export a
TileDB::tiledb
CMake target regardless of static or dynamic linkage.TYPE: BUILD
DESC: Remove the
TILEDB_STATIC
option and replace it withBUILD_SHARED_LIBS
which is disabled by default.TYPE: BUILD
DESC: The build system supports building only a static or shared library from the same buildtree.