Skip to content
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

Cmake module install prefix causes packaging headaches #844

Open
pwillis-els opened this issue Oct 1, 2021 · 1 comment · May be fixed by #850
Open

Cmake module install prefix causes packaging headaches #844

pwillis-els opened this issue Oct 1, 2021 · 1 comment · May be fixed by #850
Labels
Cmake feature-request A feature should be added or improved. needs-review This issue or pull request needs review from a core team member. p2 This is a standard priority issue

Comments

@pwillis-els
Copy link

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:

        cmake -B build \
                -DCMAKE_INSTALL_PREFIX=/usr \
                -DCMAKE_INSTALL_LIBDIR=share \
                "${pkgname}-${pkgver}"

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!

@r-burns
Copy link

r-burns commented Oct 8, 2021

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.

For example, see how catch2 does this: catchorg/Catch2@1af60ef

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.

@jmklix jmklix added feature-request A feature should be added or improved. p2 This is a standard priority issue needs-review This issue or pull request needs review from a core team member. labels Sep 21, 2023
@jmklix jmklix added the Cmake label May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Cmake feature-request A feature should be added or improved. needs-review This issue or pull request needs review from a core team member. p2 This is a standard priority issue
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants