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

Please provide pkg-config file #1374

Open
dengelt opened this issue Dec 4, 2023 · 5 comments
Open

Please provide pkg-config file #1374

dengelt opened this issue Dec 4, 2023 · 5 comments
Assignees

Comments

@dengelt
Copy link

dengelt commented Dec 4, 2023

Issue Summary:

I would like to request the addition of pkg-config support in the project build system. Currently, the project relies on CMake for its build configuration, but having a pkg-config file would greatly enhance interoperability with other build systems and ease the integration process for downstream projects.

Description:

As an end-user, integrating projects into different build environments can sometimes be challenging. While CMake is a powerful and widely used build system, having a pkg-config file alongside it would facilitate seamless integration for developers using other build systems, such as Autotools or Meson or making FFI bindings to other languages such as Rust.

Benefits of Adding pkg-config Support:

  1. Interoperability: Developers using build systems other than CMake can easily incorporate the project into their workflows without additional manual configuration.

  2. Dependency Management: pkg-config simplifies the process of managing dependencies by providing a standardized way to query and retrieve information about installed libraries.

  3. Ease of Integration: Projects using pkg-config can be more easily integrated into various development environments, making it more accessible for a broader audience.

Suggested Implementation:

  1. Create a *.pc.in file that contains the necessary variables and information about the project.

  2. Configure the file during the build process using CMake variables to ensure dynamic values like installation paths are correctly handled.

  3. Install the generated *.pc file alongside other artifacts during the installation phase.

Example CMakeLists.txt Changes:

# ... existing CMake configuration ...

# Generate pkg-config file
configure_file(${CMAKE_SOURCE_DIR}/path/to/project.pc.in
               ${CMAKE_BINARY_DIR}/project.pc @ONLY)

# Install the generated pkg-config file
install(FILES ${CMAKE_BINARY_DIR}/project.pc
        DESTINATION ${CMAKE_INSTALL_LIBDIR}/pkgconfig)

Here's another example: https://www.scivision.dev/cmake-generate-pkg-config/

Additional Notes:

  • Please consider versioning the pkg-config file according to the project's version to avoid conflicts with multiple installed versions.

  • Ensure that the necessary variables in the *.pc.in file (e.g., Libs, Cflags) accurately reflect the project's configuration.

Thank you for considering this enhancement request. I believe that adding pkg-config support will contribute to the project's usability and ease of adoption across various development environments.

@pfultz2
Copy link
Contributor

pfultz2 commented Dec 4, 2023

We would need support for pkgconfig in hip first before it could be implemented in rocblas. Also, any generation of pkgconfig files needs to be done by rocm-cmake to ensure consistency across components.

@TorreZuk TorreZuk self-assigned this Dec 13, 2023
@TorreZuk
Copy link
Contributor

@dengelt thanks for your input. Have you created this as a general issue for ROCm ROCm ? Or do you only use rocBLAS and would benefit from a pkg-config for only the non ROCm depdencies of rocBLAS. As mentioned any movement for the entire ROCm stack to use pkgconfig will take some time as the overall dependency system needs to be analyzed.

@dengelt
Copy link
Author

dengelt commented Dec 13, 2023

I had originally thought the way to go would be to start from the bottom up, that's why I filed for rocBLAS and MIOpen first. The libraries I would directly use would be hip, hipBLAS, hipRAND and hipDNN. Should I file an issue for hip instead?

@TorreZuk
Copy link
Contributor

Well yes @dengelt good to raise it at the bottom of the stack, so hip or even an issue in ROCm/ROCm. Any new system will take a coordinated effort but maybe some experimental tests could happen in these hipXXX libraries. Will need to be reviewing other solutions as well so just collecting considerations and requests for now.

@dengelt
Copy link
Author

dengelt commented Dec 13, 2023

Ok I filed an issue in hip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants