You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As mentioned here awslabs/aws-c-event-stream#15 , the current aws-c-common cmake module paths cause the packages to install and load from non-standard paths on distributions. As a result, the packagers are having to include hacks after building to move the files into the correct paths, so other packages will pick up where the files are.
I am building the AWS package stack for AWS CLI in Alpine right now, and though I'm a total cmake newb, that issue seems to confirm the problem I'm seeing now, which is that I can't force the modules to install to the correct paths, nor include them from the correct paths, without patching the CMakeLists.txt for all the AWS packages.
Maybe I'm wrong and I missed some cmake option that will fix this? In the case of Alpine, the system's modules are installed to /usr/share/cmake/Modules, and AWS tools want to install / load from /usr/lib/cmake. I can use the following arguments:
To get the files into /usr/share/cmake, but I have to move them into /usr/share/cmake/Modules before the installed files are packaged. Otherwise you'd have to patch every single app that tried to find them to use the non-standard /usr/share/cmake path.
The issue linked at the top explains how to modify CMakeLists.txt to install into a package-specific directory, and also how to specify aws-specific package directories. So, unless you can find a backwards-compatible workaround, this might mean breaking your previous build instructions for your whole stack of tools. But they would install and load according to standard convention...
Anyway, I'm gonna hack around them for now like the other distros, but I'm curious what your thoughts are, or if there's a simpler fix for all this. Thanks!
The text was updated successfully, but these errors were encountered:
The current cmake module approach is honestly incorrect anyway. Package scripts installed to /usr/lib/cmake are supposed to be cmake package config files of the form /usr/lib/cmake/{package-name}/{package-name}Config.cmake.
Following that approach, consumers of aws-c-common would simply need to find_package(aws-c-common) before include(AwsCFlags) etc. I imagine symlinking the include files to the old location would provide suitable backward compatibility during the transition period.
As mentioned here awslabs/aws-c-event-stream#15 , the current aws-c-common cmake module paths cause the packages to install and load from non-standard paths on distributions. As a result, the packagers are having to include hacks after building to move the files into the correct paths, so other packages will pick up where the files are.
I am building the AWS package stack for AWS CLI in Alpine right now, and though I'm a total cmake newb, that issue seems to confirm the problem I'm seeing now, which is that I can't force the modules to install to the correct paths, nor include them from the correct paths, without patching the CMakeLists.txt for all the AWS packages.
Maybe I'm wrong and I missed some cmake option that will fix this? In the case of Alpine, the system's modules are installed to
/usr/share/cmake/Modules
, and AWS tools want to install / load from/usr/lib/cmake
. I can use the following arguments:To get the files into
/usr/share/cmake
, but I have to move them into/usr/share/cmake/Modules
before the installed files are packaged. Otherwise you'd have to patch every single app that tried to find them to use the non-standard/usr/share/cmake
path.The issue linked at the top explains how to modify CMakeLists.txt to install into a package-specific directory, and also how to specify aws-specific package directories. So, unless you can find a backwards-compatible workaround, this might mean breaking your previous build instructions for your whole stack of tools. But they would install and load according to standard convention...
Anyway, I'm gonna hack around them for now like the other distros, but I'm curious what your thoughts are, or if there's a simpler fix for all this. Thanks!
The text was updated successfully, but these errors were encountered: