Open pcbennion opened 2 years ago
I suspect #12078 may have broken compatability with older conan installs.
OSX and Linux builds seem to be unaffected. UPDATE: The cmake scripts are broken for all platforms; our OSX and Linux were failing silently because they automatically fall back to system sqlite3 libraries.
Updating my windows machine to conan 1.51.3 fixed the issue.
@pcbennion please, read CCI documentation, how to isolate my project from upstream changes
The Conan Center Index expects that every user is running the latest version available. We know not any company can switch from one version to another easier, so for those cases, we recommend Lockfiles.
Also, we started to prepared official recipes to support Conan v2, which should become the standard version in few months.
Did it fail with CMakeDeps
or cmake_find_package
?
For CMakeDeps
, there was this kind of issue for example: https://github.com/conan-io/conan/issues/11862, (fixed by https://github.com/conan-io/conan/pull/11874).
CCI recipes can't track conan client issues & regressions of each generator, and set a required_conan_version
depending on which generator you use to consume a recipe.
@uilianries
@pcbennion please, read CCI documentation, how to isolate my project from upstream changes
The Conan Center Index expects that every user is running the latest version available. We know not any company can switch from one version to another easier, so for those cases, we recommend Lockfiles.
Also, we started to prepared official recipes to support Conan v2, which should become the standard version in few months.
We isolate our projects by hosting our own conan server. On the occasions we pull from conancenter (usually while updating dependency versions/options), we specify recipe revisions and use a lockfile. Our lock on sqlite3 was last updated to pull in 3.39.2.
--build
ing the older sqlite3 recipe rev still results in a broken .cmake script. Using conan 1.49.0, the only way I've been able to make a working sqlite3 since the PR above was by checking out a prior conan-center-index commit and building it from there.
@SpaceIm
Did it fail with
CMakeDeps
orcmake_find_package
?For
CMakeDeps
, there was this kind of issue for example: conan-io/conan#11862, (fixed by conan-io/conan#11874).CCI recipes can't track conan client issues & regressions of each generator, and set a
required_conan_version
depending on which generator you use to consume a recipe.
We use cmake_find_package
.
Package and Environment Details
Conan profile
[settings] arch=x86_64 arch_build=x86_64 build_type=Release compiler=Visual Studio compiler.runtime=MD compiler.version=16 os=Windows os_build=Windows [options] [conf] [build_requires] [env]
Steps to reproduce
On windows, using conan 1.49.0 and earlier, consume the conancenter sqlite3 package with the following CMakeLists.txt:
find_package will fail to populate any of the associated sqlite3 targets or variables.
Logs
Click to expand log
``` conanfile.py (Sqlite3Consumer/0.0.1): Calling build() ********************************************************************** ** Visual Studio 2019 Developer Command Prompt v16.4.5 ** Copyright (c) 2019 Microsoft Corporation ********************************************************************** [vcvarsall.bat] Environment initialized for: 'x64' -- Conan: Using autogenerated FindSQLite3.cmake -- Library sqlite3 not found in package, might be system one -- Library sqlite3 not found in package, might be system one -- Sqlite3 dirs: ```