Conan 1.12: Editable packages, Composable profiles, Command improvements & New architectures
This time we have 1.12 out to start the 2019 year and there are some interesting features and improvements we would like to highlight. Let’s go over them!
It is fairly common that to test new code in packages with other dependencies while developing, you had to go through the slow
conan create process to store new code in the cache.
Following the path of other package managers, we tried to imagine how an “editable” mode for Conan should work and there were some main points:
The user has to be able to compile without Conan (IDE/command line, not
Freedom to choose any project structure for header folders, source code, library folders…
Handle any configuration of settings without creating artificial packages for all of them.
To illustrate how editable package work, we have created a repo here that we would use it as example.
Let’s say we are developing a final “hello” application and we are relying on another library called “say” to print our message. We are
developing the “say” library and would like to check the changes in the “hello” app. The normal way would be to make changes in the “say”
library and run
conan create to put its binaries in the local cache. After that, consume it from the “hello” app with a
With this feature, we have a command conan link to tell Conan
that we want to consume the “say” library under the package name
say/0.1@user/testing directly from the current folder instead from the
$ cd cmake/say $ mkdir build && cd build $ conan link .. say/0.1@user/testing --layout=../layout
The layout indicates Conan that it has to search in the following paths relative to the directory of the conanfile.py used in the command. Here is the content of that file:
Now we can build in the development folder (this could also be triggered by an IDE):
$ conan install .. $ cmake ../src -G "Visual Studio 15 2017 Win64" $ cmake --build . --config Release
Let’s consume the “say” library from the “hello” app now:
$ cd ../../hello $ mkdir build && cd build $ conan install .. ... conanfile.py (hello/0.1@None/None): Installing package Requirements say/0.1@user/testing from user folder - Editable Packages say/0.1@user/testing:6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7 - Editable ... $ cmake ../src -G "Visual Studio 15 2017 Win64" $ cmake --build . --config Release $ bin\app.exe Release: Hello World Release!
Now we make some changes in the “say” library without moving it to the cache. For example, we change the
Release: message to
****** Release ******: and build it:
$ cd ../../hello $ cmake --build . --config Release
Finally, out “hello” app should be built with the modified “say”:
$ cmake --build . --config Release $ bin\app.exe ******* Release *******: Hello World Release!
As you can see, having this new workflow is very convenient during development and the compilation is not coupled with Conan, only a
conan install is necessary.
If you want to read more, here is the link to the docs section explaining this new feature and the possibility to use different layout files.
There are some pending issues like having a proper layout templating system or showing packages that are in editable mode when searching, but we hope to have them fixed for next release.
New path for workspaces
We are aware that there has been a lot of interest in the experimental workspaces feature. However, as releases came out and development continued we started to think the implementation of workspaces was lacking at some points.
Additionally, the idea of the package layouts and editable mode was something really interesting to explore. So our decision was to delay the development of issues regarding workspaces until editable packages were released.
There has been some work done already to redesign and reimplement workspaces on top of the editable mode feature and our first impressions are good. We will try to restart the development of them for the following releases.
With Conan 1.12, commands with the
--profile parameter are now provided with the possibility of using it multiple times to achieve a
$ conan install . --profile windows --profile 32bit
The priority of the applied values is from right to left. In the case of the example, the “32bits” profile configuration will have priority over the “windows” profile configuration.
# windows # 32bit # result [settings] [settings] [settings] os=Windows os=Windows os=Windows os_build=Windows os_build=Windows os_build=Windows arch=x86_64 arch=x86 arch=x86 arch_build=x86_64 arch_build=x86 arch_build=x86 compiler=Visual Studio compiler=Visual Studio compiler.version=14 compiler.version=14 compiler.runtime=MD compiler.runtime=MD build_type=Release build_type=Release
It is a very useful feature when you want to add build require tools like CMake, which is something not specific to a configuration. For
example, having a profile
cmake with build require cmake_installer and a
mingw one with the “gcc” compiler and the mingw_installer too would make it
very easy to apply to a and to use it:
$ conan install . --profile mingw --profile cmake
Full reference and JSON for some commands
As you might now, some commands had some issues when referencing names of other packages. For example, the
conan install --build <name>
was only using the name of a requirement, which could be problematic when using dependencies with the same name but coming from different
users. Now you can do this:
$ conan install . --build liba/1.0@user/channel
Together with this feature, the install command also includes now an additional reference for consumer packages that comes handy to have some information defined like the user or the channel.
$ conan install . liba/1.0@user/channel
There is more information in this section of the documentation.
To end with the new commands, the
conan info has now a generalized
--json parameter not only for build order but for the dependency
graph information. We are sure this will come handy for those orchestrating CIs using Conan. Check the
output section to see how it looks like.
New architectures supported
New architectures arrived at this release too. This time we included new ones for Apple and PowerPC.
Apple introduced a new one for watchOS called
arm64_32. As we had already followed the
armvX pattern and
amrv8 was already in
place, we decided to call this one
armv8_32. Similarly, the new iOS architecture called
arm64e was introduced in settings.yml as
armv8.3. You can manage this conversions with
Finally, there was a request to support PowerPC 32-bit architecture, so there is also a new
ppc32 one too.
Those can be correctly handled with apple tools and
tools.get_gnu_triplet() and will be taken into account in some generators like
Check that your settings.yml is updated when you install Conan 1.12 and run a new
conan install. In case your settings.yml was
modified, a new settings.yml.new will be created so you can check the diff.
Generators: Template files & variable naming convention
Some releases ago we introduced a new make generator and there were some issues with the naming of the variables that could be misleading to users (See conan-io/docs#955).
As the Conan
cpp_info model includes a
cppflags that is confusing, we finally decided to rename
CONAN_CXXFLAGS in the generator and follow this path for premake too, following the convention that was already in place in the
cmake generator. There is also an issue open to create a
cpp_info.cxxflags attribute deprecating
cpp_info.cppflags used in
package_info() method of conanfile without breaking (conan-io/conan#4461).
In the other hand, some users requested the the possibility to export some kind of templating files in order to make the task of generating
the conanbuildinfo files easier in some cases. now the use of
exports attribute is allowed in custom generators:
You can see a full example in this how-to.
There are new tools and improvements available in this release too:
tools.SVN()have anew method
get_tag()that checks the name of the tag has been checked out. (See link).
MSBuild()build helper has now a definitions dictionary that can be used to set any property to the project during the build. Also the default toolset is now applied although no toolset was specified in the profile. This should not break the old behavior as this was the default value already applied in
PlatformToolsetflag. (See link).
tools.environment_append()is now able to unset variables using the
Nonevalue. (See link).
Short paths feature now generates them in a deterministic way instead of having a random path in the short paths directory.
If you want to know more about the changes in this release, check the full list of features and fixes in the changelog (it includes links to the related Pull Request) and don’t forget to update!
Finally, if you find a bug or want to start a new discussion, please do not hesitate to open a new issue here.