andreasbuhr-cppcoro: Conan 2.0 support

[Ahajha]

Specify library name and version: andreasbuhr-cppcoro/all

I noticed the recipe previously had a single component defined, which seemed unnecessary, so I removed it. If anyone might know why that was there I can re-add it.

Closes #20564
Closes #16621

• I've read the contributing guidelines.
• I've used a recent Conan client version close to the currently deployed.
• I've tried at least one configuration locally with the conan-center hook activated.

[ghost]

I detected other pull requests that are modifying andreasbuhr-cppcoro/all recipe:

• andreasbuhr-cppcoro: migrate to Conan v2 #18817

This message is automatically generated by https://github.com/ericLemanissier/conan-center-conflicting-prs so don't hesitate to report issues/improvements there.

[AbrilRBS]

Hi @Ahajha thanks a lot for your PR, we really appreciate it! :)
The windows error comes from the fact that a check for C++17 at least should be done, else CCI will set it to 14 in windows and it won't compile

Just checked that there's a similar PR (I thought my first review didn't go thru!) for this recipe, maybe we can work to bring them both together with their changes?

[Ahajha]

@RubenRBS I didn't even notice there was another PR for this until I had already pushed it, but it seems this one will be a bit easier since it has a few more months of changes/fixes. I can definitely incorporate the rest of that branch's changes.

[github-actions]

Hooks produced the following warnings for commit 18ef9c1

andreasbuhr-cppcoro/cci.20210113@#cd2c14706331779efaea159f160e1418

post_package(): WARN: [MISSING SYSTEM LIBS (KB-H043)] Library '.\bin\cppcoro.dll' links to system library 'ws2_32' but it is not in cpp_info.system_libs.
post_package(): WARN: [MISSING SYSTEM LIBS (KB-H043)] Library '.\bin\cppcoro.dll' links to system library 'mswsock' but it is not in cpp_info.system_libs.

[Ahajha]

Getting a C5231 on MSVC in the test package, which has almost no documentation online, I can't visually tell what's causing it, and I can't reproduce it on my machine. So for now trying to remove 20210113 and see if it's fixed upstream.

[Ahajha]

Not quite ready yet:

1. Need to figure out why cci.20210113 is failing on Windows, maybe we either drop support or bump it to a slightly later commit. Regardless I think having the latest is a good idea.
2. Add system deps for Windows
3. Minor test package cleanup (v1 should defer to v2)

[Ahajha]

Looking at the changes between cci.20210113 and the latest, it's mostly very small bugfixes (including the windows build issue), so I imagine it won't cause any breakages for people to upgrade. Thus, I think we can just leave only the latest version. If someone needs a previous version we can revisit.

With that note, this should be ready for another review once CI passes.

[Ahajha]

@RubenRBS This is ready for review (not sure if there's another process to signaling ready-ness)

[AbrilRBS]

Pinging works, thanks :) (If not, we usually come around the PR eventually after a few days)

[AbrilRBS]

Thanks! Somall questions, but looks nice

[Ahajha]

@RubenRBS Can you please take another look at this PR to see if there's any more required changes?

[AbrilRBS]

Thanks. I have a concern with Clang >= 16. I've proposed a solution, and I'm interested in hearing what you think about it :)

[AbrilRBS]

This will be an issue for compilers that only have coroutines support for C++20 enabled. This is the case of clang >= 16, where only having -std=c++20 enables coroutines. With this check, CCI will only try to build for C++ 17. Maybe a solution is to force C++20 as a min required version if the other flag checks have not succeeded?

[Ahajha]

Maybe we could just update this value to be
return 20 if self.settings.compiler == "clang" and self.settings.compiler.version >= 16 else 17?

[Ahajha]

There's also a funny edge case that I just ran into: When using libstdc++ with clang, it always required C++20. With libc++, it allows C++17 actually through clang 16, but fails with 17. I'll double check all my tests, but assuming that's correct I'll update the checks.

[Ahajha]

@RubenRBS A couple things I found while doing some more extensive clang testing:

1. It seems that the -fcoroutines-ts flag is never needed, at least as far down as clang11. Just to be on the safe side, for versions older than that, I kept the flag.
2. If using newer libstdc++ versions (I have libstdc++ 13, not sure if earlier ones will cause it) with clang 14 specifically, the build may fail for an unrelated reason. I don't know if there's a setting to test this, but I have it outputting a warning for now if it detects libstdc++ and clang 14.
3. libstdc++ + clang always requires c++20
4. clang allows c++17 mode up to and including clang 16, clang 17 is the first one to require c++20.

[Ahajha]

@RubenRBS I think this is ready for another look (I don't see the Conan v2 pipeline though, odd)

[conan-center-bot]

Conan v1 pipeline ✔️

All green in build 16 (d8ce9ebf6aa58a6e997d51c444606537192780e6):

• andreasbuhr-cppcoro/cci.20230629:
  All packages built successfully! (All logs)

---

Conan v2 pipeline ✔️

Note: Conan v2 builds are now mandatory. Please read our discussion about it.

All green in build 18 (d8ce9ebf6aa58a6e997d51c444606537192780e6):

• andreasbuhr-cppcoro/cci.20230629:
  All packages built successfully! (All logs)

[Ahajha]

@RubenRBS Can you take another look at this one?

[uilianries]

LGTM