Production ready?

[tonka3000]

Production ready?

[memsharded]

I have many reasons:

• Same reason why I usually use git in the command-line, instead of from IDEs or cmake. I prefer command line direct access to the tool
• The only command that is executed by cmake-conan is conan install. But conan has other commands you typically also use while working with conan, like info, search, remove, test_package. So you are either limited to consuming packages with cmake-conan, or have to go to the command line anyway.
• With conan profiles, the command line is not also very short to type, but profiles is a perfect way to share different configurations with the team, with CI, to ensure that always the same settings are used. Profiles can be shared putting them in the repo, or in a dedicated repo. You ensure reproducibility much better. I don't use compiler, version as separated settings anymore (just for demos, and docs), but always profiles (which btw also support other powerful features like build_requires)
• Too much layer of abstraction to avoid just typing one line. Cmake-conan already has 320 lines of cmake code to basically implement something done in one line in the terminal. More lines, more things that can fail, more bugs. And right now they don't implement all the install features, like build_requires. Adding them would require more cmake lines.
• If I go the cmake way, I end scripting too much in cmake, and I hate it. I much prefer scripting in python. So all automation tasks I can directly do in python, those are many many lines of problematic cmake code that I save. So for "project management" tasks, like code generation from templates, arranging files, running side-tools, etc., much better to do it from python.

[memsharded]

So good :) I will make next version beta!

[memsharded]

Good point. As you know, I am not a big fan of cmake-conan :) :) So I am not using it in production.
But I also think that it has matured, it has some testing in travis and appveyor, so I would say that we can move next release to 0.5 (i.e. leaving alpha) that would be beta (IMO, that is enough for production ready, actually conan is still beta (0.23), until it hits 1.0, and is largely used in production), and remove the experimental notice in the README.

Looking forward more opinions here.

[tonka3000]

As you know, I am not a big fan of cmake-conan :) :) So I am not using it in production.

Why you don't use it in production, what are the cons from your point of view?
For me, the main benefit is that the developer don't need to enter the compiler (version, etc.) and the build option every time (we have to support many compilers), so it's not painful anymore.

But I also think that it has matured, it has some testing in travis and appveyor, so I would say that we can move next release to 0.5 (i.e. leaving alpha) that would be beta (IMO, that is enough for production ready

Good idea

[JPGygax68]

I'd like to comment on this - I also use cmake-conan extensively, and I would go as far as saying that, unless I'm missing something fundamental, conan cannot actually succeed without it.

And the reason is something that you were kind enough to discuss with me some time ago: nested projects. Such a situation is a nightmare to manage unless the build tool, in this case CMake, is capable of obtaining dependencies on its own, which is of course precisely what cmake-conan makes possible.

Without that capability, the only viable alternative is to use conan from A to Z, i.e. to replace nested projects with conan-managed packages. But that route has problems too - the nested project has to be in a reasonably stable state lest you loose too much time exportting it again and again and again after every small change - which is in direct opposition to the reason for using nested projects in the first place.

EDIT: I just realized that the above is not strictly true - it is of course possible to craft CMake files that can switch from submodules to cmake-conan and back easily with a simple definition line at the top, or even leave the choice to the user via an option. It's still rather more manual work than I care for, though.

[memsharded]

conan cannot actually succeed without it.

You might be missing the fact that conan is not tied to cmake. Conan has quite large usage with other build-systems.

nested projects. Such a situation is a nightmare to manage unless the build tool, in this case CMake, is capable of obtaining dependencies on its own, which is of course precisely what cmake-conan makes possible. ... to replace nested projects with conan-managed packages. But that route has problems too - the nested project has to be in a reasonably stable state lest you loose too much time exporting it again and again and again after every small change - which is in direct opposition to the reason for using nested projects in the first place.

You might have missed some of the later improvements to conan. Local workflows have been improved, new commands like package_files allow to directly export binaries from user folder to the conan cache, avoiding re-build, and even small hacking allow to directly link with user space folders. If you didnt, you might be interested in watching: https://www.youtube.com/watch?v=qpOul18bXes.

Also, cmake install feature can now be very easily used instead of the package() method, further easing the task.

We keep continuing working on this, for example, the next big feature will be "conan-projects" a convenient way to define packages that are simultaneously under edition, so everything is transparent.

From what we see, just a small part of conan users are using the cmake-conan approach, which means that there are many, many users successfully using conan without it. So I do not agree on cmake-conan being that critical :).

[JPGygax68]

If you didnt, you might be interested in watching: https://www.youtube.com/watch?v=qpOul18bXes.

Thank you for that link, I watched this last night, and indeed it was very interesting.

Also, cmake install feature can now be very easily used instead of the package() method, further easing the task.

One of my main takeaways from the video!

We keep continuing working on this, for example, the next big feature will be "conan-projects" a convenient way to define packages that are simultaneously under edition, so everything is transparent.

That may amount to a small revolution in itself.

From what we see, just a small part of conan users are using the cmake-conan approach, ...

Hm... I wonder if users of both Conan and CMake are actually aware that cmake-conan exists ?

[memsharded]

Hm... I wonder if users of both Conan and CMake are actually aware that cmake-conan exists ?

There is a dedicated section for it in the docs:

http://conanio.readthedocs.io/en/latest/howtos/cmake_launch.html?highlight=cmake-conan

And it is also a repo in the conan github organization, so its visibility is not bad. It also appears as an answer in some github issues I think.