For llpkg, the C language ecosystem extends far beyond the 1,800 libraries hosted on Conan. For example, V8 is not available on Conan, and the Flint version on Conan is only 3.0.1, whereas the latest Flint release has reached 3.2.2 (https://github.com/flintlib/flint/releases/tag/v3.2.2).
GoPlus provides a solution for this by offering a repository to store and distribute as many C/C++ libraries as possible: https://github.com/goplus/cppkg.
In previous discussions, we proposed creating an all branch to aggregate as many Conan packages as possible. However, if upstream sources expand beyond Conan to include all packages, the design of the all branch would need adjustments.
Should we adopt a structure similar to cppkg for storing libraries?
For llpkg, the C language ecosystem extends far beyond the 1,800 libraries hosted on Conan. For example, V8 is not available on Conan, and the Flint version on Conan is only 3.0.1, whereas the latest Flint release has reached 3.2.2 (https://github.com/flintlib/flint/releases/tag/v3.2.2).
GoPlus provides a solution for this by offering a repository to store and distribute as many C/C++ libraries as possible: https://github.com/goplus/cppkg.
In previous discussions, we proposed creating an all branch to aggregate as many Conan packages as possible. However, if upstream sources expand beyond Conan to include all packages, the design of the all branch would need adjustments.
Should we adopt a structure similar to cppkg for storing libraries?
For instance, abedra/libvault in cppkg. Currently, the top-level directories in the all branch still map 1:1 to Conan packages.
Tagging strategy for Conan packages and future cppkg-hosted packages not on Conan.
Integrating cppkg into llpkg to support versions absent from Conan Center Index.
Relevant discussion: Allow users to submit versions that are not yet available on Conan. #54.