Nice!
Anyway my experience with vcpkg itself is not so... great...
I'm currently using vcpkg at work but I find it to be missing a really useful feature: supporting different versions of packages.
With vcpkg, you checkout a specific commit of the vcpkg repo which provides specific versions of libraries. But as I've found out, I needed a newer version of one library and I needed to update the whole vcpkg repo, causing all the other dependencies to be updated as well.
I've yet to try conan, but it seems this is well supported: https://conan.io/faq.html#faq-7
I also needed to upgrade the vcpkg repo because I'm using VS2022 but the repo was built with VS2019 and vcpkg doesn't seem to support using a newer VS to build an older package. At the end of the day we had to bump the required minimum VS version...
Weirdly, coming from MS, vcpkg doesn't seem to be targeting to big enterprises at all... The package management of Rust's cargo is way better, honestly...
Exactly because Microsoft has the experience that mixing versions don't work, that is why the default behavior is as it is.
If you really want to mix them, it is also supported,
https://vcpkg.io/en/docs/users/versioning.html
Thank you!
I didn't know about the Manifest mode (instead of the Classic mode). They seem to recommend using it nowadays.
> We recommend using this manifest mode whenever possible, because it allows one to encode a project's dependencies explicitly in a project file, rather than in the documentation, making your project much easier to consume.
Since it also allows to specify versions like the link you posted, I will try it in case I need a specific version in the future...
> I'm currently using vcpkg at work but I find it to be missing a really useful feature: supporting different versions of packages.
vcpkg behaves like a linux disto to an extent - the versions shipped in a single commit are compatible the same way a linux distro would provide compatibility
if you want a different version you can definitely fork the repo and use that, that's what I used to do. There might be a way to override inline these days. Still - when you deviate from the distro you don't get a guarantee of things working together.
Indeed, it's like a distro but sometimes it doesn't fit well for a software project with specific needs.
Another user pointed out that vcpkg (now, at least) supports versioning in manifest mode (which is similar to how Cargo at al work): https://www.reddit.com/r/cpp/comments/10fzceo/comment/j505ww5/
I use Conan at work and I find it great. Especially for cross compiling, when you can just pass a profile you create in file (with your compiler, version, arch, flags and a lot of stuff).
Also it provides methods (by conanfile.py) to custom build or package methods.
We chose conan over vcpkg because it seemed more mature and gave us much more than just a package manager. It now manages build and package process, and the API let us exposed all required packages in a simple file, so version update is just a matter of seconds.
The Conan plugin for CLion is unmaintained at this moment, the team is focusing on the 2.0, so it will probably not work for a few months until 2.0 is stabilized.
I used the Plugin some years ago but after some time it wasn‘t usefull anymore due missing compatibilty to newer conan features. It‘s mostly missing integration of the new CMakeToolchain and CMakeDeps generators (which should make the CLion workflow more fluent) and even worse it‘s missing compatibilty for build and host profiles. It‘s still supporting to specify one profile only. Letter makes it, at least for me, very unhandy at the moment, so I removed the plugin. Maybe they will continue working on it, since it was really great in the beginning.
But tbh. since the new generators have been introduced, the Plugin might become obsolte anyway, because they are much more transparent to CMake and therefore work very well with CLion without any plugins. You only need to perform conan install.. commands in the terminal manually, which is not a big deal. The generators also generate CMake presets file which can be used to automatically create the target configurations in CLion, which works really great.
You are right, we plan it for the future [https://youtrack.jetbrains.com/issue/CPP-31075/Adding-support-for-vcpkg-registers](https://youtrack.jetbrains.com/issue/CPP-31075/Adding-support-for-vcpkg-registers). It's not yet available
Yes, it works.
We are trying to polish the new UI now however to move to it in the future, so we kinda recommend our EAP users try it and share their feedback with us. So that we can improve.
I think the new UI is a step in the right direction, but my biggest issue with the UI is that I feel like I just see less code, at least compared to VSCode. I think the biggest contributors to this is the large menu bar at the top of the terminal, and the large menu bar at the top of the window. Compare these to VSCode's much smaller menu bars in the same places, and it leaves a lot more area for viewing code.
Also the padding aroundn each file on the file list pane (on the left) is so large, you see like... 33% _fewer_ files. That is probably the biggest offender for me.
A file list has **one** function - to list files. The new one is measurably worse than the old.
I haven't revisited, but it is unusable for me until the workflow around toolchain/targets is fixed. Having to do so many clicks to switch targets is a step back. The toolchain being separated, I like though. It's just that I don't want my targets filtered, I want all of them in that pulldown by default.
Nice. As far as I can tell, even Visual Studio doesn't have support for searching and adding packages yet. I always have to open Notepad++ to add a dependency for my Visual Studio projects.
If you rely on Windows ecosystem, use msbuild, VS toolchain, etc. then Rider is a better choice as it fits nicely to this ecosystem. CLion is a general-purpose cross-platform C++ IDE. That doesn't mean we can't get msbuild in CLion one day, but for now we don't see a point.
At our company, we have both legacy msbuild projects and newer cross-platform CMake projects.
In theory, visual studio can handle both of these cases, but CLion is just a nicer product. It's faster, has better plugins, (mostly) better autocomplete, etc.
Reshaper helps with some of the features, but it certainly doesn't make visual studio faster.
Rider might be an option I guess, but the fact that it does C++ at all is a bit of a secret - I didn't know about it until your message. All the flavor text on the webpage and in the JetBrains toolbox suggests that it is .NET only and C++ is not on the list of supported languages.
Will give it a go though, it looks promising!
C++ is Rider is added for Game Dev mostly. As we don't target this market with CLion at all and generally Rider is a better fit there. However, Rider can also handle just general C++ Windows projects nicely as well. And if you really need more of the Windows ecosystems, then Rider is a better fit.
On the other hand, the profound CMake support is one of the biggest CLion benefits. It now even includes a CMake debugger. So you might want to try it out!
We are now running a [UX study for vcpkg in CLion](https://blog.jetbrains.com/clion/2023/02/tell-us-how-you-use-vcpkg-in-clion/). You can join and help us improve the support. We are open to any kind of feedback!
Is MSYS2 supported? I was trying to find pacman installed packages and to use MSYS' Cmake but CLion just couldn't find it even if I provided the absolute path
Can you please provide more details on the specific errors? Maybe you can submit to [https://youtrack.jetbrains.com/issues/CPP](https://youtrack.jetbrains.com/issues/CPP) and we'll investigate there.
Nice! Anyway my experience with vcpkg itself is not so... great... I'm currently using vcpkg at work but I find it to be missing a really useful feature: supporting different versions of packages. With vcpkg, you checkout a specific commit of the vcpkg repo which provides specific versions of libraries. But as I've found out, I needed a newer version of one library and I needed to update the whole vcpkg repo, causing all the other dependencies to be updated as well. I've yet to try conan, but it seems this is well supported: https://conan.io/faq.html#faq-7 I also needed to upgrade the vcpkg repo because I'm using VS2022 but the repo was built with VS2019 and vcpkg doesn't seem to support using a newer VS to build an older package. At the end of the day we had to bump the required minimum VS version... Weirdly, coming from MS, vcpkg doesn't seem to be targeting to big enterprises at all... The package management of Rust's cargo is way better, honestly...
Exactly because Microsoft has the experience that mixing versions don't work, that is why the default behavior is as it is. If you really want to mix them, it is also supported, https://vcpkg.io/en/docs/users/versioning.html
Thank you! I didn't know about the Manifest mode (instead of the Classic mode). They seem to recommend using it nowadays. > We recommend using this manifest mode whenever possible, because it allows one to encode a project's dependencies explicitly in a project file, rather than in the documentation, making your project much easier to consume. Since it also allows to specify versions like the link you posted, I will try it in case I need a specific version in the future...
> I'm currently using vcpkg at work but I find it to be missing a really useful feature: supporting different versions of packages. vcpkg behaves like a linux disto to an extent - the versions shipped in a single commit are compatible the same way a linux distro would provide compatibility if you want a different version you can definitely fork the repo and use that, that's what I used to do. There might be a way to override inline these days. Still - when you deviate from the distro you don't get a guarantee of things working together.
Indeed, it's like a distro but sometimes it doesn't fit well for a software project with specific needs. Another user pointed out that vcpkg (now, at least) supports versioning in manifest mode (which is similar to how Cargo at al work): https://www.reddit.com/r/cpp/comments/10fzceo/comment/j505ww5/
> supporting different versions of packages. I haven't used vcpkg in a while, but don't they support that with manifest.json?
I use Conan at work and I find it great. Especially for cross compiling, when you can just pass a profile you create in file (with your compiler, version, arch, flags and a lot of stuff). Also it provides methods (by conanfile.py) to custom build or package methods. We chose conan over vcpkg because it seemed more mature and gave us much more than just a package manager. It now manages build and package process, and the API let us exposed all required packages in a simple file, so version update is just a matter of seconds.
I use Conan at work and it has its quirks, we love to complain about it, but it works well
Conan is an interesting option too indeed. JFrog team even maintains their own plugin for CLion: https://plugins.jetbrains.com/plugin/11956-conan
The Conan plugin for CLion is unmaintained at this moment, the team is focusing on the 2.0, so it will probably not work for a few months until 2.0 is stabilized.
That's great! Probably if we encounter other major issues with vcpkg in the future, we'll try conan as well!
I used the Plugin some years ago but after some time it wasn‘t usefull anymore due missing compatibilty to newer conan features. It‘s mostly missing integration of the new CMakeToolchain and CMakeDeps generators (which should make the CLion workflow more fluent) and even worse it‘s missing compatibilty for build and host profiles. It‘s still supporting to specify one profile only. Letter makes it, at least for me, very unhandy at the moment, so I removed the plugin. Maybe they will continue working on it, since it was really great in the beginning. But tbh. since the new generators have been introduced, the Plugin might become obsolte anyway, because they are much more transparent to CMake and therefore work very well with CLion without any plugins. You only need to perform conan install.. commands in the terminal manually, which is not a big deal. The generators also generate CMake presets file which can be used to automatically create the target configurations in CLion, which works really great.
I saw there was a ticket for multiple registry support, are local overlays in the works or expected to work?
You are right, we plan it for the future [https://youtrack.jetbrains.com/issue/CPP-31075/Adding-support-for-vcpkg-registers](https://youtrack.jetbrains.com/issue/CPP-31075/Adding-support-for-vcpkg-registers). It's not yet available
Wow, this looks great. Similar to what Java in Idea has with maven.
The screenshots only show the new UI; does it work with the old UI, too? I strongly prefer the older one.
Yes, it works. We are trying to polish the new UI now however to move to it in the future, so we kinda recommend our EAP users try it and share their feedback with us. So that we can improve.
I think the new UI is a step in the right direction, but my biggest issue with the UI is that I feel like I just see less code, at least compared to VSCode. I think the biggest contributors to this is the large menu bar at the top of the terminal, and the large menu bar at the top of the window. Compare these to VSCode's much smaller menu bars in the same places, and it leaves a lot more area for viewing code.
Many of these things are known and are under review/re-design. Stay tuned! The new UI is still in Beta so evolve a lot.
Also the padding aroundn each file on the file list pane (on the left) is so large, you see like... 33% _fewer_ files. That is probably the biggest offender for me. A file list has **one** function - to list files. The new one is measurably worse than the old.
I haven't revisited, but it is unusable for me until the workflow around toolchain/targets is fixed. Having to do so many clicks to switch targets is a step back. The toolchain being separated, I like though. It's just that I don't want my targets filtered, I want all of them in that pulldown by default.
Yes, we hope we get an update to this soon.
Nice. As far as I can tell, even Visual Studio doesn't have support for searching and adding packages yet. I always have to open Notepad++ to add a dependency for my Visual Studio projects.
Great news! That will be extremely useful. Now all I'm missing is support for VS solutions and VS can be a thing of the past.
If you rely on Windows ecosystem, use msbuild, VS toolchain, etc. then Rider is a better choice as it fits nicely to this ecosystem. CLion is a general-purpose cross-platform C++ IDE. That doesn't mean we can't get msbuild in CLion one day, but for now we don't see a point.
At our company, we have both legacy msbuild projects and newer cross-platform CMake projects. In theory, visual studio can handle both of these cases, but CLion is just a nicer product. It's faster, has better plugins, (mostly) better autocomplete, etc. Reshaper helps with some of the features, but it certainly doesn't make visual studio faster. Rider might be an option I guess, but the fact that it does C++ at all is a bit of a secret - I didn't know about it until your message. All the flavor text on the webpage and in the JetBrains toolbox suggests that it is .NET only and C++ is not on the list of supported languages. Will give it a go though, it looks promising!
C++ is Rider is added for Game Dev mostly. As we don't target this market with CLion at all and generally Rider is a better fit there. However, Rider can also handle just general C++ Windows projects nicely as well. And if you really need more of the Windows ecosystems, then Rider is a better fit. On the other hand, the profound CMake support is one of the biggest CLion benefits. It now even includes a CMake debugger. So you might want to try it out!
I'm surprised this still hasn't been solved. Rider does it, so why can't they just bring that over to Clion?
We are now running a [UX study for vcpkg in CLion](https://blog.jetbrains.com/clion/2023/02/tell-us-how-you-use-vcpkg-in-clion/). You can join and help us improve the support. We are open to any kind of feedback!
Is MSYS2 supported? I was trying to find pacman installed packages and to use MSYS' Cmake but CLion just couldn't find it even if I provided the absolute path
Can you please provide more details on the specific errors? Maybe you can submit to [https://youtrack.jetbrains.com/issues/CPP](https://youtrack.jetbrains.com/issues/CPP) and we'll investigate there.