-
Notifications
You must be signed in to change notification settings - Fork 455
CDRIVER-4637 Remove ENABLE_SRV=AUTO, clean up SRV URI support #1301
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
CDRIVER-4637 Remove ENABLE_SRV=AUTO, clean up SRV URI support #1301
Conversation
56cbbd2
to
bf343ec
Compare
This AUTO wasn't doing anything, and behaved very similar to plain ON. Now we define an interface library that provides the resolving library. Some cleanup to the ResSearch lookup module.
This change uses target properties to fill in the slots in the generated pkg-config files. Previously this was unstructured strings and flag juggling.
bf343ec
to
ea2ef8a
Compare
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.
Only some comments and suggested changes so far. I'll take another look at this later, after I've had a chance to take it all in.
src/libmongoc/CMakeLists.txt
Outdated
# Delete "#~" comments: | ||
string(REGEX REPLACE "#~[^\n]*" "" content "${content}") | ||
# Replace our simple "%define <name> <value>" macros: | ||
while(content MATCHES "(.*)\n *%define *([a-zA-Z_\\$<>:-]+) *([^\n]*)\n(.*)") |
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.
while(content MATCHES "(.*)\n *%define *([a-zA-Z_\\$<>:-]+) *([^\n]*)\n(.*)") | |
while(content MATCHES "(.*)\n *%define\s+([a-zA-Z_\\$<>:-]+)\s+([^\n]*)\n(.*)") |
What do you think about a more permissive notion of whitespace and also making it 1..* rather than 0..*?
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.
CMake's regex engine doesn't support shorthand character classes, unfortunately. Yes on the first +
, but for the second I had an impulse to may %define nothing
replace "nothing
" with nothing a-la #define nothing
.
@@ -101,7 +101,11 @@ _mongoc_client_killcursors_command (mongoc_cluster_t *cluster, | |||
} while (0) | |||
|
|||
|
|||
#ifdef MONGOC_HAVE_DNSAPI | |||
#if MONGOC_ENABLE_SRV == 0 // ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ ENABLE_SRV disabled |
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'm assuming that you have to use == 0
rather than !defined
because if it is assigned a value of 0 it is treated as being defined. Is that right?
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.
// Given:
#define FOO 0
#define BAR 1
// All the following conditions evaluate to true:
// #ifdef FOO
// #ifdef BAR
// #ifndef BAZ
// #if FOO == 0
// #if BAR != 0
// #if BAZ == 0
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 feel like I knew that, yet I also feel like I would have overlooked it had I been implementing it. Perhaps I've been spending too much time on Python.
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.
Aside: The "best" way to do boolean macros, imo: https://godbolt.org/z/zdsT77fTP
- If the macro is undefined, you get a compilation error
- If the macro is defined to any value other than those permitted, you get a compilation error.
IS_ON
/IS_OFF
is usable in both preprocessor directives as well as C conditionals
Co-authored-by: Roberto C. Sánchez <[email protected]>
Co-authored-by: Roberto C. Sánchez <[email protected]>
src/libmongoc/CMakeLists.txt
Outdated
set_target_properties (mongoc_static PROPERTIES | ||
VERSION 0.0.0 | ||
OUTPUT_NAME "${MONGOC_OUTPUT_BASENAME}-static-${MONGOC_API_VERSION}" | ||
pc_REQUIRES "libbson-static-1.0" |
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.
Consider PKG_CONFIG_
as prefix for pkg-config properties instead of pc_
.
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 can rename it to pkgconfig_
or pkg_config_
, but I'll still keep it lowercase, because that's the under-documented way to "correctly" name custom properties. CMake arcana:
CMake won't let you use arbitrary properties on INTERFACE
libraries. CMake will yell at you if you even look for a property that isn't "allowed" on an INTERFACE library. I think this restriction is obnoxious and pointless, and even if they remove(d?) it then there are still CMake executables out there that will yell at you.
Of the properties permitted: anything that starts with an underscore or a lowercase letter. I'm still scratching my head about it. Oh well.
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.
Perhaps the property must be prefixed with INTERFACE_
? From https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#compatible-interface-properties:
Some target properties are required to be compatible between a target and the interface of each dependency. For example, the
POSITION_INDEPENDENT_CODE
target property may specify a boolean value [...] To be "compatible", thePOSITION_INDEPENDENT_CODE
property, if set must be either the same, in a boolean sense, as theINTERFACE_POSITION_INDEPENDENT_CODE
property of all transitively specified dependencies on which that property is set. This property of "compatible interface requirement" may be extended to other properties by specifying the property in the content of theCOMPATIBLE_INTERFACE_BOOL
target property. Each specified property must be compatible between the consuming target and the corresponding property with anINTERFACE_
prefix from each dependency: [...]
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.
This is confusing (I know it comes from the documentation):
if set must be either the same, in a boolean sense, as the INTERFACE_POSITION_INDEPENDENT_CODE property of all transitively specified dependencies on which that property is set
They used "either" but there is no corresponding "or". I wonder if this is a result of a change where an "or" had been present, but removed, and the structure of the rest of the sentence wasn't updated.
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.
The INTERFACE_
target properties are "whitelisted" for INTERFACE
libraries, as well as the COMPATIBLE_INTERFACE_
properties, but those are to deal with transitive usage requirements when linking targets together, not per-target custom properties.
@@ -101,7 +101,11 @@ _mongoc_client_killcursors_command (mongoc_cluster_t *cluster, | |||
} while (0) | |||
|
|||
|
|||
#ifdef MONGOC_HAVE_DNSAPI | |||
#if MONGOC_ENABLE_SRV == 0 // ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ ENABLE_SRV disabled |
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.
// Given:
#define FOO 0
#define BAR 1
// All the following conditions evaluate to true:
// #ifdef FOO
// #ifdef BAR
// #ifndef BAZ
// #if FOO == 0
// #if BAR != 0
// #if BAZ == 0
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. The improved accuracy to handshake metadata is appreciated.
This pull request removes libmongoc-1.0.pc, but I couldn't find the reasoning. Does this mean that using libmongoc-ssl-1.0.pc is the only supported way? Thanks for clarification. (I'm working on build system integration tasks right now, so I don't know much about the details of all this; however, this looks like using mongo-c-driver without ssl is deprecated, which seems reasonable to me; is my understanding correct?) |
Forget my last comment, I tried 1.25.0 now and it properly generates a libmongoc-1.0.pc file. |
Refer: CDRIVER-4637
This changeset builds upon #1289, so it will look messy with those additional changes.
Removing the
AUTO
value ofENABLE_SRV
was relatively simple, but required some changes to the way we discover the DNS resolver, and it also led to adding a new feature bit to the handshake (that may be an excessive change...).Changes in this PR
Bits and Flags
FindResSearch.cmake
was renamed toResSearch.cmake
. TheFind
prefix is reserved for find-modules, to be used with thefind_package()
command. Based on the way we use it, I decided it would be simpler to rename the file than to make it into a find-module.mongoc-config.h
file.ENABLE_SRV
. Previously, code was conditionally compiled based onMONGOC_HAVE_RES_[N]SEARCH
andMONGOC_HAVE_DNSAPI
. Since disablingENABLE_SRV
implicitly set these to zero, the code for SRV URIs was omitted.MONGOC_SRV_ENABLED
/MONGOC_ENABLE_SRV
are defined inmongoc-config.h
. These reflect the user's choice ofENABLE_SRV
, regardless of the features available on the platform.ENABLE_SRV
, a new bit is added to the handshake to represent the value of this setting.Targets and CMake
RESOLV_LIBRARIES
variable with the library name. This variable was implicitly used all over the code. Sad.mongo::detail::c_resolve
that exposes the usage requirements of the underlying name resolution system.mongo::detail::c_dependencies
. This library is meant to capture the usage requirements of the platform and optional features going forward.ENABLE_SRV
is true, thenmongo::detail::c_dependencies
usesmongo::detail::c_resolve
.RESOLVE_LIBRARIES
variable is gone. Instead,mongoc_shared
andmongoc_static
now link tomongo::detail::c_dependencies
. Now all downstream users will receive the usage requirements ofmongo::detail::c_dependencies
, which will includemongo::detail::c_resolve
ifENABLE_SRV
is true.pkg-config Changes
This aspect of the changeset was unexpected and may be excessively engineered. Oh well. If we don't like this one, we can seek another way.
.pc
file generation relied heavily on spooky-action-at-a-distance variables propagating across the build tree. before landing aroundconfigure_file
.RESOLVE_LIBRARIES
) would be picked up beforeconfigure_file()
and shuffled about into the set ofLibs:
andCflags:
values to be inserted..pc
files are generated using a combination of target properties,configure_file
, CMake generator expressions, and a sequence of REGEX REPLACE..pc.in
file for both the static and shared libraries, and it is used to generate two distinct.pc
files for each..pc
file for each target:pc_INCLUDE_DIRECTORIES
adds-I
flags. Relative paths are prepended by${prefix}
.pc_REQUIRES
addsRequires:
linespc_LIBS
is an array that buildsLibs
.INTERFACE_LINK_OPTIONS
will also be added toLibs
.pc_NAME
,pc_VERSION
, andpc_DESCRIPTION
set the Name, Version, and Description values.INTERFACE_COMPILE_DEFINITIONS
andINTERFACE_COMPILE_OPTIONS
are added toCflags
automatically.MONGOC_LIBRARIES
variable is gone. This was used solely for the generation of the pkg-config file for the static library. Thepc_LIBS
target property takes its place.MONGOC_LIBRARIES
was rewritten to append them topc_LIBS
onmongoc_static