Carry C_FLAGS / CXX_FLAGS into the aws-c-* libs

[kmaragon]

Issue #, if available:
#1086

Description of changes:
Moving the project declaration up was for good form and it enables tools like conan to know what language they are running in so they can inject library search paths and compilation flags before running the execute_process subprocess builds for the aws-c-* libs.

The rest was to ensure that at least C_FLAGS and CXX_FLAGS are carried into the separate child cmake processes that are executed first with execute_process and then later via ExternalProject. Without this, building an x86 build on an x86-64 machine would succeed but would produce an unusable set of libs where the aws-c-* libs were all 64 bit and the main aws-sdk-cpp libs were all 32 bit as requested.

This doesn't fix an outstanding issue though. When using /MT on Windows the same kind of problem as above occurs. The aws-c-* libs all link against the shared multi-threaded runtime - /MD. But the aws-sdk-cpp libs do as requested and use the static runtime. And again, these build correctly but they are unusable because of the conflicting runtimes.

It's not enough to carry the CMAKE_C_FLAGS that contain /MT. There seems to be some mechanism (maybe in the way the child cmake runs or in the aws-c-* libs themselves) that clobbers the /MT and converts it to /MD. So it is not possible to build a usable aws-sdk-cpp statically on Windows using the static runtime. And this PR won't fix that. But it will at least enable building x86 libraries on an x86-64 machine for Linux and Windows.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[singku]

awslabs/aws-c-common@8e36c09

I think this is the place that switches between /MT and /MD

[marcomagdy]

project() defines the INSTALL_PREFIX which we test for later.
The call is intentionally placed after the cmake commands to build the third-party libs.
We should have documented that better.

[marcomagdy]

ping!
any chance of updating this PR?

[kmaragon]

awslabs/aws-c-common@8e36c09

I think this is the place that switches between /MT and /MD

This code isn't in the commit that is being checked out with the ExternalProject. So that's probably not butchering it. But for what it's worth, BUILD_SHARED_LIBS is OFF in this case - at least at the top level.

[ihnorton]

One problem I've encountered with static builds on Windows is that CMake ExternalProject_Add does not pass the CMAKE_GENERATOR_PLATFORM explicitly down to sub-builds unless the generator was explicitly set in the top level CMake invocation. So even though cmake is running in the correct x64 vcvars environment and chooses the correct generator at the top level with -A x64, EP sub-builds don't get the -A x64 and fall back to x86. This was a headache because even though I was passing -A x64 in my superbuild ExternalProject_Add for AWS SDK, the EP_Add calls inside of AWS SDK itself (for c-common etc.) did not thread the -A x64 down, causing linkage failures. I've ended up using -GVisual Studio 15 2017 Win64, although I believe -GVisual Studio 15 2017 -A x64 would also work.

Aha, now I see that this is not a cmake issue, but rather that the SDK is not using ExternalProject_Add but instead calling execute_process directly, and not passing the target platform there.

[github-actions]

Greetings! Sorry to say but this is a very old issue that is probably not getting as much attention as it deservers. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to open a new one.