Closed prince-chrismc closed 6 months ago
m4: Closed #12815 which is superseded by #12892
autoconf; Closed #12777 which is superseded by #12896
libffi: #12904
libtool: #12916
The recipe and test_v1_package
are mostly ported, still working on the test_package
which holds a bit of a challenge since it tries to test 3 different scenario's with multiple tools, in non-standard installation locations
Is would be cool to update bison to 3.8.2 and upgrade it to conan v2, it will also close https://github.com/conan-io/conan-center-index/issues/10381
Libcurl #12956
benchmark: https://github.com/conan-io/conan-center-index/pull/13080 cppcodec: https://github.com/conan-io/conan-center-index/pull/13110 libjpeg: https://github.com/conan-io/conan-center-index/pull/13123 libtiff: https://github.com/conan-io/conan-center-index/pull/13109 libuuid: https://github.com/conan-io/conan-center-index/pull/13130 libuv: https://github.com/conan-io/conan-center-index/pull/13129 magic_enum: https://github.com/conan-io/conan-center-index/pull/12894 md4c: https://github.com/conan-io/conan-center-index/pull/12977 odbc: https://github.com/conan-io/conan-center-index/pull/13131
October 5th update
Has a test_v1_package/ to ensure 1.x is not broken
I think it should be optional.
test_package
is executed for both v1 and v2. test_v1_package
is executed just for v1.therefore, if recipe has test_package
and it passes CI, we ensure recipe can be successfully consumed with both v1 and v2.
however, test_v1_package
might be used to test some legacy v1 generators, such generators v2 doesn't have and will not ever have (for instance, legacy cmake
generator).
in reality, it's rarely needed, as both v1 and v2 can perfectly use modern generators (such as CMakeDeps
), so test_v1_package
should be an optional thing. so for most of new recipes, it should be enough to just have test_package
using sub-set of features available in both v1 and v2.
I disagree. CCI recipes must still check both new & legacy genrators, because a PR may break legacy generators and therefore break consumers or other CCI recipes which are still relying on these legacy generators.
You are both right and we are doing exactly that -- just in different words
test_package/
which is called by both 1.x and 2.0 pipelines uses CMakeDeps
or equivalent
conan create
which what contributors are testing when they develop locallytest_v1_package/
is intended to be ran with 1.x pipeline to ensure that legacy generators are not broken
To follow :)
October 31st update
@SSE4 , @SpaceIm , @prince-chrismc out of paranoia, for the B2 recipe I ended up adding all three test packages (test_package, test_v1_package, test_v2_package). Perhaps not the best approach. But it's hard to discern from my distant vantage point what should be done when. And would much rather just hope a single test package. But, whatever ;-)
But it's hard to discern from my distant vantage point what should be done when
I commented on your PR trying to help :)
flex: #14013 ...but I'm having a problem detailed in a comment there about flex_target
not being defined, as it is with the built-in CMake module.
November 29th update
I have not been maintaining this list but you can take a peak at my fork to see what's been cooking 🧑🍳
A complete list can be found in https://github.com/prince-chrismc/conan-center-index/blob/config/v2-top100/.github/top_100_recipes.yaml
Since this list is not maintained, maybe we can close this issue in favor of #20992 which is more up-to-date.
Great suggestion!
Recipe Migration
One of the more important requirements for the Conan 2.0 adoptions strategy is to have a very strong showing of recipes that are ready to go.
⭐ Goal ~80% of most download recipes from August 2022
Criteria for "2.0 ready" currently is:
conans
layout
conan.tools.files
helperstest_v1_package/
to ensure 1.x is not broken (why?)test_package/
hastest_type
,requires
,can_run
Migration Effort
This list of just over 100 recipes hits just above the 80% mark.
Last updated: November 29th 2022 👻
test_type
test_type
andcan_run
test_type
test_type
PkgConfig
toolstest_type
andcan_run
test_type
andcan_run
test_type
andcan_run
test_type
test_type
andcan_run
test_type
andcan_run
test_type
andcan_run
can_run
test_type
test_type
andcan_run
test_type
andcan_run
test_type
andcan_run
can_run
test_type
PkgConfig
tool