Avoid having to explicitly pass
-DAWS_CORE_HEADER_FILE=$AWS_CORE_HEADER_FILE
to cmake.
Details
Details
N/A, later tunnelbroker build should suffice
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
Is this really better than passing -DAWS_CORE_HEADER_FILE=$AWS_CORE_HEADER_FILE to CMake? Seems like we need some quirky customization either way, and this looks like a lot more code compared to just a single line -DAWS_CORE_HEADER_FILE=$AWS_CORE_HEADER_FILE...
Comment Actions
Yes, because I often clear the cache, and having to remember that a specific project needs to be treated special is often annoying.
The other option would be to forego the use of the AWSSDK helper, and just use the individual components that we need.
Comment Actions
I need more details! What cache? Why does a cache need to be cleared? What does this diff have to do with a cache? What is the AWSSDK helper?
Comment Actions
I need more details! What cache? Why does a cache need to be cleared? What does this diff have to do with a cache? What is the AWSSDK helper?
When you do mkdir build && cd build && cmake .. cmake caches a lot of cmake logic in the build directory. Since I've been rebasing a lot, I need to clear the caches as some of the cached logic might be stale. For normal development this isn't much of an issue as changes to .h and .ccp will be reflected in Make's build rules. But stuff like finding certain dependencies will not.
Comment Actions
At this rate the diff will take a while to get over the line. The more you can do to explain in detail, the faster we can get this shipped! Think about what it will take for somebody with no context to understand everything necessary to accept this diff.
This was never clarified.
I don't understand. Why does clearing the CMake cache cause issues if you specify -DAWS_CORE_HEADER_FILE=$AWS_CORE_HEADER_FILE in the CMake file?
Comment Actions
What is the AWSSDK helper?
An example can be found here where it will populate the linked libraries.
Instead of using the COMPONENTS, and having AWSSDK set a variable, you could also just find_package() aws-sdk-cpp-core and aws-sdk-cpp-dynamodb separately then add the individual apis/libraries to the build.
I don't understand. Why does clearing the CMake cache cause issues if you specify -DAWS_CORE_HEADER_FILE=$AWS_CORE_HEADER_FILE in the CMake file?
I think https://github.com/aws/aws-sdk-cpp/issues/2009 would give you the most context, I think I meant to link to this issue in the comment
Comment Actions
Still confused. It appears that we're getting nowhere on the diff, so let's talk through this in our 1:1 today
Comment Actions
@jon is going to try to clarify and answer my questions again and we'll see where we get
Comment Actions
So the entirety of the context is:
When using the aws-sdk-cpp package, they currently recommend using find_package(AWSSDK) to interface with the parts of the sdk that you want to use, the current sdk is quite massive (300+ apis), so limiting the scope to only what you need makes a lot of sense.
However, the logic to enable this find_package(AWSSDK COMPONENTS <components>) requires some cmake logic on their end to find the corresponding packages that you care about. However, nix invalidates some assumptions about how the headers and libraries are co-located so we need some way to tell aws-sdk-cpp how to find the headers with nix (the libraries are found in the default location on nix, so just the headers "out-of-place"). Generally, people pass -DAWS_ROOT_DIR to overwrite the aws-sdk-cpp location; however, this directory assumes that both headers and libraries are available from it, so it is also unable to be used.
There's two ways to get around this.
aws-sdk-cpp allows for you to pass a value (-DAWS_CORE_HEADER_FILE) to overwrite their logic. However, this needs to be passed on each command line invocation of cmake so that it's able to then find all of the corresponding aws headers; for example, if you were to delete a build directory, then call cmake .. again, you would need to call it with cmake .. -DAWS_CORE_HEADER_FILE=<something>. Further complicating this is that nix is able to move where aws-sdk-cpp is exactly located within the nix store, so initially I was setting a AWS_CORE_HEADER_FILE environment variable through nix develop so invocation looked like cmake .. -DAWS_CORE_HEADER_FILE=$AWS_CORE_HEADER_FILE. This is not a great experience. This pain could be mitigated by looking at the environment variables available inside of the CMakeLists.txt, but this would be a very nix-specific solution, which would not be reflected in something like a homebrew or vcpkg workflow. Furthermore, inspecting environment variables from a CMakeLists.txt about package information is an anti-pattern; cmake has many ways to communicate the whereabouts of files, and using environment variables is less preferred to something like find_package and using target information.
The other method is to patch aws-sdk-cpp within nix, and avoid having to pass anything on each command line invocation to cmake, as the nix version of aws-sdk-cpp will be nix compatible. This is the route I decided on after some more thinking. This work was upstreamed to nixpkgs here, and eventually we will not need to provide any special logic for aws-sdk-cpp to "just work" with nix. An upstream fix to aws-sdk-cpp would likely include very long review process as installation testing is notoriously difficult and prune to regressions.