referring AWSSDK targets in cmake

[crusader-mike]

I am updating our codebase to use cmake and having difficulty with linking with AWS SDK (and learning cmake as I go). Apparently there are two ways to reference SDK:

old one (apparently it is deprecated?):

find_package(aws-cpp-sdk-core REQUIRED)
target_link_libraries(mylib PUBLIC aws-cpp-sdk-core)

related find module creates imported target aws-cpp-sdk-core that drags in required dependencies removing some of my headaches (selecting correct ssl library, etc). CMake guidelines suggest using "namespaces" (i.e. target should be named aws-cpp-sdk-core::<smth>), but it is not fatal...

new one:

find_package(AWSSDK REQUIRED)

set(SERVICE s3)
AWSSDK_DETERMINE_LIBS_TO_LINK(SERVICE OUTPUT)
target_link_libraries(mylib PUBLIC ${OUTPUT})

unfortunately it doesn't seem to follow ideas introduced by "modern cmake" -- it doesn't create imported targets, thus forcing me to take care of aws-cpp-sdk-core dependencies (like ssl libs, etc).

I have two questions:

• what is the officially approved way to go when using AWS SDK from my application CMakeLists.txt?
• is there any way to find out what given cmake find module does (besides reading it's source code)? (As in "which targets it is going to create?" and "what variables will affect it's behaviour?")

[marcomagdy]

I recommend using the first method.
We're working on improving the CMake experience.
Ideally, it should be something like:
find_package(AWSSDK COMPONENTS core s3 dynamodb ...)

[crusader-mike]

Thank you, Marco. Any comments on question #2? (apologies, I am learning cmake right now, watched "modern cmake" videos literally yesterday :) )

[marcomagdy]

reading the source obviously is the ultimate truth. But, idiomatically, <package>_INCLUDE_DIR and <package>_LIB_DIR should be defined. CMake does not enforce that, so it's up to the author to define those in the <package>-config.cmake or <package>Config.cmake

[crusader-mike]

... but "modern cmake" outlaws usage of <package>_INCLUDE_DIR (and other variables) -- the idea is to define targets (that drag in all required dependencies). Idea looks quite compelling, but it looks like it is "too fresh" -- I constantly bump into find modules that don't follow it yet.

Looks like there is no way to discover imported targets given find module introduces... well, besides reading source code.

Thank you!

[marcomagdy]

wait, I might have misunderstood your question then.
Pulling in the deps of a package should be transparent to the package consumer. So, I'm not sure why you want to know what packages they pull in?
You should say find_package(Foo) and then use Foo in your add_library|executable( Foo)

[crusader-mike]

find_package(Foo ...) is supposed to create one or more (imported) targets in Foo namespace and I am supposed to use them as target_link_libraries(myexe Foo::<target>). Problem is that it is impossible to discover which targets given find module will create. In case of modules deployed with cmake -- I could go to online docs. In case of 3rd party libs (like AWS SDK) there seem to be no way to do it besides reading source code.

Another problem is that find module behaviour is often controlled by variables set externally (fundamentally flawed idea -- they should be passed as arguments to find_package). again -- no way to find out which variables given find module uses.

[crusader-mike]

Example: after find_package(AWSSDK) I tried AWSDSDK::core, then AWSDSDK::aws-sdk-core, then AWSSDK::AWSSDK before giving up and starting digging in /usr/local/lib64/cmake/AWSSDK directory just to discover that this module doesn't create any targets at all :)

[marcomagdy]

ah! I think you mean components when you say imported targets.

In general, a package that does not have components (like curl), should drag in its deps as targets, but in most cases, you wouldn't need to know about those targets/deps.

In the AWSSDK case, we have many components and like I said in my first comment, we have some work to do there to make our build story more modern.

[crusader-mike]

I may be misusing terminology here. In case of single library (e.g. find_package(curl)) it is simple -- I expect related find module to define a new target for me to use (named curl::curl). Because conventions... Of course this target will have it's own dependencies I want to not care about.

In case if I import more complex package -- there in no way to discover which targets (if any) it will create for me... because cmake find modules are effectively black boxes and there is no way to "probe" it dynamically -- you just "have to know" that find_package(Boost) will create Boost::system target (if boost_system library is installed). I hoped there is a way and I am just ignorant of it. Apparently not.

[singku]

@crusader-mike
With our latest commit, you can use

find_package(AWSSDK REQUIRED COMPONENTS transfer s3-encryption)
target_link_libraries(YOUR_TARGET ${AWSSDK_LINK_LIBRARIES})

Without worrying about that transfer depends on s3 and core, s3-encryption depends on kms, s3 and core.

[crusader-mike]

@singku, thank you.