New glm version in recipes/glm/all/conandata.yml #11452

joaotavora · 2022-06-30T13:24:21Z

Thanks Paul Harris for the hand-holding and bug hunting.

recipes/glm/all/conandata.yml (sources): Add a source for the latest
commit of 20220420.
recipes/glm/config.yml: Also mention new version here.
recipes/glm/all/conanfile.py (GlmConan.package): Tweak for
"cci.*" versions.

Specify library name and version: glm/cci.20220420 built from GitHub's on-demand per-commit zip service.

This is also a good place to share with all of us why you are submitting this PR

Oh, just because the latest tagged verion 0.9.9.8 is from ~~2018~~2020 but it has a nagging warning (which converts to error with -Werror with C++20 that has been fixed 2 years ago. They should really make a new version tag.

I'm afraid I didn't do any of the below items 👇 😬 I'm very new to conan and I also don't have much time.

I've read the guidelines for contributing.
I've followed the PEP8 style guides for Python code in the recipes.
I've used the latest Conan client version.
I've tried at least one configuration locally with the conan-center hook activated.

Thanks Paul Harris for the hand-holding and bug hunting. * recipes/glm/all/conandata.yml (sources): Add a source for the latest commit of 20220420. * recipes/glm/config.yml: Also mention new version here. * recipes/glm/all/conanfile.py (GlmConan.package): Tweak for "cci.*" versions.

CLAassistant · 2022-06-30T13:24:32Z

All committers have signed the CLA.

SpaceIm · 2022-06-30T13:51:04Z

0.9.9.8 is from April 2020, not 2018. Could you ask upstream to release a new version instead? cci versions can be confusing when there are also proper releases, and here I'm not sure that fixing a warning is good reason to package a cci version.

joaotavora · 2022-06-30T14:00:11Z

that issue already exists. g-truc/glm#1108 by @paulharris

cci versions can be confusing when there are also proper releases, and here I'm not sure that fixing a warning is good reason to package a cci version.

I guess, but it's better than the current situation? The warning is annoying enough to break anyone who has -Werror in the CMake CXXFLAGS 🤷 Not sure I can/should turn off warnings for a particular header (unless maybe I precompile it).

joaotavora · 2022-06-30T14:07:03Z

0.9.9.8 is from April 2020, not 2018.

You're right, sorry. I was looking at the last commit of the 0.9.9.8 branch, that does seem to be from 2018. https://github.com/g-truc/glm/tree/0.9.8. I guess I don't understand how they do versioning around those parts. Pretty good library though.

paulharris · 2022-06-30T15:00:38Z

0.9.9.8 is from April 2020, not 2018. Could you ask upstream to release a new version instead? cci versions can be confusing when there are also proper releases, and here I'm not sure that fixing a warning is good reason to package a cci version.

I was wondering how best to handle an "intermediate" version number.
I don't think it is reasonable to have to wait for upstream to tag a release, especially in this situation where the library is stable and the users probably just use origin/master anyway.

Perhaps instead, we do 0.9.9.8-cci.date

So at least conan users can see the version ordering.
It breaks (?) semver, but still at least the human can tell the ordering when 0.10.0.0 or 0.9.9.9 comes along.

Debian do this a lot with their ~version suffixes.

SpaceIm · 2022-06-30T15:01:08Z

I guess, but it's better than the current situation? The warning is annoying enough to break anyone who has -Werror in the CMake CXXFLAGS

How do you consume glm? You should use -isystem to avoid warnings from headers of your dependencies. When your link imported targets, CMake generates build files with isystem.

joaotavora · 2022-06-30T15:16:00Z

How do you consume glm?

It's header only. I simply #include <glm/glm.hpp> it. I don't have any special CMakeLists.txt code for it. Here's my full CMakeLists.txt:

cmake_minimum_required(VERSION 3.9)
project(hello CXX) # PROJECT_NAME is now "hello"
set(CMAKE_CXX_STANDARD 20)

# This will come in handy for LSP servers such as clangd
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

# Decent compile options
add_compile_options(-Wall -Wextra -Werror -pedantic)

# Conan is important
include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()

# Make the "hello" executable target. Use globbing for src
file(GLOB_RECURSE src_cpp CONFIGURE_DEPENDS "src/*.cpp")
add_executable(${PROJECT_NAME} ${src_cpp})

joaotavora · 2022-06-30T15:21:00Z

Seems Conan's Cmake integration doesn't use -isystem. This is what it plugs in for me:

-I$HOME/.conan/data/glm/cci.20220420/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include

SpaceIm · 2022-06-30T15:33:14Z

Add cmake_find_package generator, find_package(glm REQUIRED) and target_link_libraries(myapp PRIVATE glm::glm). Eventually replace conan_basic_setup() by conan_basic_setup(TARGETS).

prince-chrismc

Barely maintained projects are a pain... this matches with our policy https://github.com/conan-io/conan-center-index/blob/master/docs/faqs.md#what-version-should-packages-use-for-libraries-without-official-releases

So it's fine... there's lost of other fixes and improvements that are going to be added which is good

prince-chrismc · 2022-06-30T16:21:54Z

@paulharris thanks for help @joaotavora, was reading the slack convo 🤗

joaotavora · 2022-06-30T16:31:28Z

Add cmake_find_package generator, find_package(glm REQUIRED) and target_link_libraries(myapp PRIVATE glm::glm). Eventually replace conan_basic_setup() by conan_basic_setup(TARGETS).

Isn't there an alternative that doesn't involve me adding "package-x"-specific stuff to my CMakeLists.txt? Maybe some option in conanfile.txt? Or tell conan to use -isystem instead of -I?

Because avoiding solutions like yours is kind of the reason I started using Conan in the first place: to separate concerns. I might as well go back to vendor/ or external/ schemes, otherwise.

Just speaking as a beginner Conan user, but I've experience with other package repositories. I don't understand why given a half-decent way to deal with a library that hasn't gotten a new version in 2+ years, there's resistance to this.

I don't understand what can possibly be confusing about having cci.* versions vs tagged releases. The latter are probably more stable, the former less so but sometimes more useful. It could other things other than warning avoidance, like features or the bugfixes that happened in these 2 years.

Anyway, I leave this here in good faith. My problem is solved for the moment, and I can always host my own artifact repository I guess.

SpaceIm · 2022-07-01T19:09:01Z

Add cmake_find_package generator, find_package(glm REQUIRED) and target_link_libraries(myapp PRIVATE glm::glm). Eventually replace conan_basic_setup() by conan_basic_setup(TARGETS).

Isn't there an alternative that doesn't involve me adding "package-x"-specific stuff to my CMakeLists.txt? Maybe some option in conanfile.txt? Or tell conan to use -isystem instead of -I?

Because avoiding solutions like yours is kind of the reason I started using Conan in the first place: to separate concerns. I might as well go back to vendor/ or external/ schemes, otherwise.

Just speaking as a beginner Conan user, but I've experience with other package repositories. I don't understand why given a half-decent way to deal with a library that hasn't gotten a new version in 2+ years, there's resistance to this.

I don't understand what can possibly be confusing about having cci.* versions vs tagged releases. The latter are probably more stable, the former less so but sometimes more useful. It could other things other than warning avoidance, like features or the bugfixes that happened in these 2 years.

Anyway, I leave this here in good faith. My problem is solved for the moment, and I can always host my own artifact repository I guess.

Your way to inject libraries with cmake generator will be removed in conan v2 anyway, so I advice to use CMakeToolchain & CMakeDeps, rely on imported targets, and write an agnostic CMakeLists. I don't understand what you mean by "separate concerns".

joaotavora · 2022-07-01T19:18:04Z

Your way to inject libraries with cmake generator will be removed in conan v2 anyway,

Yes, @paulharris has let me know as well. Well I hope do hope there's the usual generous deprecation period between now and "removal". I mean, the "current way" is still the one recommended in the tutorial today.

and write an agnostic CMakeLists. I don't understand what you mean by "separate concerns".

I think you answered exactly in the preceding sentence :-). "Separate concerns" means the same as "agnostic CMakeLists.txt". Like the one I have now. A package-agnostic one. IOW, a CMakeLists.txt where the names of the dependencies can be completely absent.

So currently, if I add a new dependency, say boost, glm, catch2 or wunderfoo, I only have to mention it 2. Once in my conanfile.txt and again in my actual code that #include <x> 's it.

So if there are other, more modern 2.0 ways to write "agnostic CMakeLists.txt", I'm in. It's just that your earlier suggestion didn't seem to point in that direction.

SpaceIm · 2022-07-01T20:36:12Z

By agnostic CMakeLists, I mean not dependent to a specific package manager, something like this:

cmake_minimum_required(VERSION 3.12)
project(myproject CXX)

find_package(glm REQUIRED)

add_executable(myapp ...)
target_compile_features(myapp PRIVATE cxx_std_20)
target_link_libraries(myapp PRIVATE glm::glm)

By separation of concerns, you mean a generic CMakeLists for all your projects without explicit link of your targets to their dependencies. It's not the direction taken by conan v2, it's not even recommended in conan v1 I think, and it's a good thing.

joaotavora · 2022-07-01T21:07:47Z

By agnostic CMakeLists, I mean not dependent to a specific package manager,

Interesting. I prefer being tied to a package manager than tied to a specific package in multiple places. That's because I change package managers much less often than I do dependencies.

It's not the direction taken by conan v2, it's not even recommended in conan v1 I think,

Well, it is the version recommended in the "Getting Started" document. As I am also "getting started" I though that would be good place to start :-).

and it's a good thing.

Sure, we can disagree. Personally, I hate repeating myself. This is why I like things like package-agnostic CMakeLists , file-agnostic CMakeLists (using GLOB, which other don't like) and things as auto and template argument deduction, among so many others.

prince-chrismc · 2022-07-06T18:45:51Z

The beauty of Conan is that you can do almost anything.

That being said the "default" or "provided" solutions are aimed towards the majority and as you pointed out is not the flavor you like (which is perfectly okay). The industry has been moving towards CMake targets and the toolchain integration is what Kitware is recommending which is why that is the approach taken for 2.0.

Isn't there an alternative that doesn't involve me adding "package-x"-specific stuff to my CMakeLists.txt? Maybe some option in conanfile.txt? Or tell conan to use -isystem instead of -I?

You'll want to move into the custom generators which is definitely a more advanced approach but gives you the flexibility to do unique creative solutions. It gives you deps info and you can globally set the include directories for instance.

My job is to educate and share Conan, so it you ever go down that road please ping me I'd love to help and write up a blog post because it will help others too.

joaotavora · 2022-07-06T21:43:37Z

My job is to educate and share Conan, so it you ever go down that road please ping me I'd love to help and write up a blog post because it will help others too.

As I use Conan more and more, and in larger projects, those problems will presumably arise, and I will definitely remember to research these new techniques you linked to. But if you write a blog post tomorrow explaining why one should seriously consider -- even in a simple project -- increasing the minimum amount of mentions of a given dependency in checked-in sources from 2 to 3 (+50%), I'll be very happy to read it asap.

The beauty of Conan is that you can do almost anything.

Wholeheartedly agree. I like systems (like Conan) that makes the simple things easy and complex things possible. Even better a system where complex things are rarely needed.

But we are focusing too much on my personal use case for this PR. Isn't it good to have an updated version of glm anyway, for features and bugfixes? It doesn't look like there's much progress on the g-truc/glm#1108 front, so maybe more people should approve this?

conan-center-bot · 2022-07-11T19:36:48Z

All green in build 4 (1f2a65f745813d7f7e9084c2de4467b04cd80e18):

glm/0.9.9.8@:
All packages built successfully! (All logs)