Closed cNoNim closed 7 months ago
Thanks for the all the work you and all the other people do for packaging glad.
Unfortunately I have pretty much no idea about cmake and it has always been a pain for me to keep it up to date and usable, I always relied on community help for that.
Is this change something you need in the repo to make the packaging possible? I would prefer if the packaging was as much as possible independent from the glad repo.
That being said, if you can keep the changes backwards compatible and it improves the overall experience I am thankful for any contribution.
@Dav1dde you can review PR https://github.com/Dav1dde/glad/pull/453 is it ready In reality, it's not necessary. I have already prepared a PR for conda-forge at https://github.com/conda-forge/glad-feedstock/pull/8.
But it seems to me that such a solution would simplify the overall experience.
After install python module and copy GladConfig.cmake u just need
find_package(Glad REQUIRED)
glad_add_library(glad_gl_core_33 REPRODUCIBLE API gl:core=3.3)
Actually, for packaging u just need
patch CMakeLists.txt -> cmake.patch
and
mkdir -p $PREFIX/lib/cmake/Glad && cp $SRC_DIR/cmake/CMakeLists.txt $PREFIX/lib/cmake/Glad/GladConfig.cmake
In PR I just maintain backward compability
@Dav1dde
Sorry I don't want to create a separate issue for a small question. It looks like there are some interesting CMake level improvements from the last release. When will 2.0.5 be released?
Thanks for your PR. Sorr been a bit busy/exhausted, I'll take a look on the weekend and make a new release for you.
It's not urgent. And thanks for your work. Maybe we need to look deeper into the cmake packages. For example, if you look at https://github.com/Tradias/asio-grpc/blob/master/cmake/asio-grpcConfig.cmake.in it looks more complicated, but I don't really understand what it's so complicated for.
Thanks for your work, merged and released 2.0.5!
Thanks!
Hello,
Maintaining conda-forge/glad-feedstock is my goal (https://github.com/conda-forge/glad-feedstock/issues/7).
But I have an idea how to improve CMake support in upstream. What do you think about translating cmake/CMakeLists.txt into GladConfig.cmake?
To ensure backward compatibility, we can set CMAKE_PREFIX_PATH to a new location of GladConfig.cmake and enable the use of python module from sources inside cmake/CMakeLists.txt.
If it's okay with you, I can provide PR.