Hi,
A new CLion 2017.1 EAP (build 171.3566.4) is now available for download. You will get a notification about a patch-update in case you are using the previous EAP build (171.3224.8).
This build includes a lot of preliminary work for the upcoming big changes: disassembly view for debugger and Microsoft C++ compiler support. While these features are not quite ready yet, this EAP build introduces important changes. Your help at this stage is highly appreciated, so please check the build and submit any issue to our tracker.
Assembly language
Starting with this build, CLion’s editor can highlight code written in assembly language:
The files are detected by the .s and .asm extensions (configured for you in Settings | Editor | File Types | Assembly Language). This works with a few limitations, however:
- Only AT&T dialect is supported
- Assembler with preprocessor is not supported
This work is the first step towards a disassembly view in debugger, which is going to come shortly to CLion EAPs.
MSVC support
Before we go through the changes, here are the two main reasons to introduce MSVC support in CLion:
- MinGW and Cygwin are often difficult to use and configure
- Cross-platform projects often use MSVC under Windows as a compiler
Saying this, we’d like to emphasize that our goal is not to provide support for VS projects, but to make it possible to use MSVC with CMake in CLion.
What is supported
Since MSVC support is still experimental, it’s not enabled by default. To turn it on, use Registry (in Find Action dialog (Shift+Ctrl+A on Linux/Windows, ⇧⌘A on macOS) type Registry; open Registry, type clion.enable.msvc and turn on the setting).
If you have Visual Studio 2013, 2015 or 2017 installed, you can now configure CLion to use MSVC compiler:
- In Settings | Build, Execution, Deployment | Toolchains, select ‘Visual Studio home’:
- In Settings | Build, Execution, Deployment | CMake, configure the architecture (x86, amd64, x86_arm, amd64_arm, etc.), platform (empty by default, store or uwp) and version (empty by default or Windows SDK name). Under the hood, CLion calls the script to configure the environment to build the project for the selected architecture and passes these parameters to it.
Now you can build your project with MSVC. Note that CLion will run CMake with the NMake generator in this case.
What is not yet there
There are still some things that are under development for now. We hope to finish them before releasing CLion 2017.1, but if not, development will continue for the 2017.2 EAP.
- Auto-detect MSVC installed on user’s machine – done in the next EAP
- PCH support (works in CLion 2017.1 EAP for non-MSVC cases)
- There is a known issue with encodings and localized output
- Easier navigation through compiler errors (CPP-7158) – done in the next EAP
The following will definitely not come to 2017.1, but will be worked on for the 2017.2 EAP:
- Specific Microsoft C++ language extensions (CPP-8675)
Note that the debugger is currently not in the roadmap (CPP-8677). We are still considering the possible workarounds, but haven’t reached a decision at this point.
Find some improvements to MSVC support in the next EAP build.
Find in Path popup
Find in Path lets you run a text search across the whole project or any selected scope. Now, you can get it in a popup window instead of the usual modal dialog:
That’s it! The full release notes are available here.
The CLion Team
JetBrains
The Drive to Develop
Thrilled to learn about the MSVC support! Seeing this feature mature with debugging support and all, I’ll have a much stronger argument to management for buying licenses.
“Cross-platform projects often use MSVC under Windows to compiler” should be changed to “to compile” or “as compiler” I think.
thanks, I’ll update!
Thanks a lot for “Find in Path popup” function. I was missing it a lot – clicking twice on the every occasion to open the whole edit page when one needs only a preview with a context was very tiresome.
Glad you liked it!
CLion might be viable replacement of MSVC considering seeming permanent 32-bitness of it, but MSVC debugging experience is just too hard to beat I think. Looking forward to it anyway.
What is so special in MSVC debugging comparing to gdb/lldb?
I’m not a lawyer, but I guess it’s just impossible due to licencing restrictions, alas. This is briefly discussed here: https://youtrack.jetbrains.com/issue/CPP-8677.
ASM is really good news. I only hope Intel syntax is also on the road map. AT&T really hurts my eyes (not to mention I always read / the parameters in the wrong order).
We can consider it later (https://youtrack.jetbrains.com/issue/CPP-9009). The main idea of that work for now is to have disassemble view in debugger.
Yes, I get it. It’s just much easier to read this disassembly when you’re not constantly confused by the unfamiliar syntax.
Anyway it’s a step in the right direction. Thank you, but don’t stop there 😉
Do I understand it right that support for MSVC 2013 is still not included? If so then is it planned, or will you require a minimum version of 2015? We currently use MSVC 2013 at wirk and I am not sure if we can upgrade to 2015.
For now minimum supported version is VS 2015. If there are many requests about VS 2013, we may consider it as well later.
As we are currently still using MSVC2013 support for that would be great. Is there an issue for that which I can vote for? Never the less, great improvement that MSVC support is coming.
I see MSVC support feature (in your post) refers to VIsual Studio itself.
please confirm that feature will be compatible with MS C++ commandline compiler kits –
“MS C++ Build Tools” (https://go.microsoft.com/fwlink/?LinkId=691126) as well as the same package for 2017 (https://www.visualstudio.com/thank-you-downloading-visual-studio/?sku=BuildTools&rel=15)?
Not yet, but we plan to investigate it later.
Thank you for the MSVC support. Worked perfectly for me. Looking forward for the debugger implementation.
Thanks. Unfortunately can’t promise you anything at this point. It’s not clear how to get it, so it for sure won’t be ready for 2017.1.
The visual studio install on my machine isn’t detected. Its a standard install in program files of vs 2015 professional. What path should I use in the tool chain dialog please?
Never mind please. I checked logs and vcvarsall.bat was getting blocked
I really wonder where you got the idea that people have difficulty using mingw and cygwin.
We mostly got it from the uninstall feedback we collect on Windows, as well as many comments in support / issue tracker / during various events.
MSVC support is very welcome: I recently moved from MacOS to Windows for my main development platform and left behind the ability to easily embed Python in C++ because I struggled with LONG_BIT issues due to differences in the Cygwin, MinGW, and MSVC toolchains. Most (all?) Windows pythons are compiled in MCVS but CLion forced the use of Cygwin or MinGW. After a lot of trial and error (emphasis on the error), I was ready to abandon Clion on Windows. This may change that decision if this allows Python embedding that is worry-free once again like on Linux, UNIX, and MacOS.
Thanks for sharing your use case with us. We’ll be glad if you give CLion another try!
Any plan to support VSBT(Visual Studio Build Tools)?? dont wana install the whole VS of the terrifying size.
I understand that and we do have such plans: https://youtrack.jetbrains.com/issue/CPP-10615. However, the estimation is not yet clear. Feel free to upvote and follow the ticket for the updates.
After going over things.
Clion is the best ,but it needs a few minor fixes. VisualStudio is becoming a huge joke. Every install is 20+gigs and service release becomes 20+ gigs by service pack3 you would think 60+ gigs to make s 7 neg file is worth it? Then the cone out with another 10-38 gig VisualStudio 2017.
That to me is absolutely crazy.
Every ide except c++ builder is under 400megs atleast.
Great speed improvement on the 2018 ide much much better.
Include Qt5 and C++ builder and you will take the market by Storm.
Thanks for your support and reasonable suggestions.
Please fix the failed compiler false flag problem. The compiler works in ming32, ming64, VusualStudio 2015.
But inside the Clion it’s running a diff test that always fails.
Great work on the 2018.1 version.
Keep up the great work.
Cross compiling is prevailing into the future.
*Here is a valuable hint*
Make the coins and you make the money.
Not sure about this: “Please fix the failed compiler false flag problem. The compiler works in ming32, ming64, VusualStudio 2015.” Could you please provide more details?
For some reason, CLion is not detecting my installation of Visual Studio Professional 2017. It can’t find it automatically, and it can’t find it when I manually set it to this.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional
What am I doing wrong here? This is my Windows machine. It works perfectly on my Linux machine and didn’t require any configuration.
Could you please attach the logs (Help | Show Logs in Explorer) to this ticket https://youtrack.jetbrains.com/issue/CPP-13032?
Okay. How can I do that? I’ve never used YouTrack before. Thanks!
Just log in to the system and drag-and-drop log to the comment to the ticket.
I’m already logged in. Okay, I dragged and dropped it into the ticket. It uploaded and now exists there as idea1.log since there’s already an idea.log there. Not sure what to do now.
That’s fine now. We’ll take a look at the log and contact you. Thanks