Upgrading to conan 1.0
If you have been using a 0.X version of Conan, there are some things to consider when upgrading to version 1.0. These are reflected in the changelog., however, this section summarizes the most important ones:
Command line changes
There are quite a few things that will break existing usage (compared to 0.30). Most of these are in command line arguments, so they are relatively easy to fix. The most important one is that now, most commands require the path to the conanfile folder or file, instead of using --path
and --file
arguments. Specifically, conan install, conan export and conan create are the ones most affected:
# instead of --path=myfolder --file=myconanfile.py, now you can do:
$ conan install . # Note the "." is now mandatory
$ conan install folder/myconanfile.txt
$ conan install ../myconanfile.py
$ conan info .
$ conan create . user/channel
$ conan create . Pkg/0.1@user/channel
$ conan create mypkgconanfile.py Pkg/0.1@user/channel
$ conan export . user/channel
$ conan export . Pkg/0.1@user/channel
$ conan export myfolder/myconanfile.py Pkg/0.1@user/channel
This behavior aligns with the conan source, conan build and conan package commands, that all use the same arguments to locate the conanfile.py containing the logic to be run.
Now all commands read: command <origin-conanfile> ...
Also, all arguments to the command line now use a dash instead of an underscore:
$ conan build .. --source-folder=../src # not --source_folder
Deprecations/removals
scopes were completely removed in conan 0.30.X
self.conanfile_directory
has been removed. Useself.source_folder
,self.build_folder
, etc. insteadself.cpp_info
,self.env_info
andself.user_info
scope has been reduced to only thepackage_info()
methodgcc
andConfigureEnvironment
were already removed in conan 0.30.1werror
doesn’t exist anymore. It is now built-in behavior.Command
test_package
has been removed. Use conan create and conan test instead.CMake
helper now (from conan 0.29) only allows theCMake(self)
syntaxconan package_files command was replaced in conan 0.28 by conan export-pkg command.
Settings and profiles. GCC/Clang versioning
GCC and Clang compilers have modified their versioning approach, from GCC > 5 and Clang > 4. The minor versions are really bugfixes, and then they have binary compatibility. To adapt to this, conan now includes the major version in the settings.yml default settings file:
gcc:
version: ["4.1", "4.4", "4.5", "4.6", "4.7", "4.8", "4.9",
"5", "5.1", "5.2", "5.3", "5.4",
"6", "6.1", "6.2", "6.3", "6.4",
"7", "7.1", "7.2"]
Most package creators want to use the major-only settings, such as -s compiler=gcc -s compiler.version=5
,
instead of also specifying the minor versions.
The default profile detection and creation has been modified accordingly, but if you have a default profile, you may want to update it to reflect this:
Conan-associated tools (conan-package-tools, conan.cmake) have been upgraded to accommodate these new defaults.
New features
Cross-compilation support with new default settings in settings.yml:
os_build
,arch_build
,os_target
,arch_target
. They are automatically removed from thepackage_id
computation, or kept if they are the only ones defined (as usually happens with dev-tools packages). It is also possible to keep them with theself.info.include_build_settings()
method (call it from yourpackage_id()
method).
Important
Please don’t use cross-build settings os_build
, arch_build
for standard packages and libraries.
They are only useful for packages that are used via build_requires
, like cmake_installer
or mingw_installer
.
Model and utilities for Windows subsystems
os:
Windows:
subsystem: [None, cygwin, msys, msys2, wsl]
This subsetting can be used by build helpers such as CMake
to act accordingly.