Makefile projects in CLion: now public!
CLion 2020.2 EAP2 brings long-awaited Makefile project support. While it’s still in its early stages with various limitations and known issues, it’s good enough to cope with a long list of projects already.
Do you have a Makefile project? Grab the free EAP build and give it a try now. Share your feedback with us!
In this blog post we’ll answer:
- How does it work under the hood?
- How to start with your Makefile project in CLion?
- What can I do if something goes wrong and my project fails to load correctly?
- What are the known issues and limitations?
Our approach to implementation
Some time ago we presented our findings and the approach we took to support Makefile projects in CLion. There we overviewed the approaches to handle Makefile that are preferred by various modern C++ IDEs and editors:
- Compiler wrappers are used to wrap the actual compiler calls and then a full clean build is performed and the project information is extracted.
- LD_PRELOAD environment variable is used and a specific dynamic library is loaded before the execution of any build process to intercept the compiler calls and collect project information.
- The output of the
makecommand is parsed, often used with the
--just-printoption to avoid actual build.
The 3rd option provides several very important benefits:
- It doesn’t affect the build process.
- It allows us to collect the information quicker compared to the full project build.
- This would work as a ‘portable’ option, as the IDE can theoretically start with the Make output recorded on another machine.
So we took the 3rd approach and implemented a prototype. We’ve tested it on a long list of projects, which you may find on our confluence page. And we hope it also performs for a huge variety of others. So it’s time for you to give it a try on your Makefile project and share the feedback with us!
How to start with your Makefile project in CLion
To open a Makefile project in CLion:
- Select the project in File | Open.
- You can open a folder as a project and CLion will search for the top-level Makefile (as well as CMakeList.txt or compile_commands.json files) and suggest opening it as a project. Or directly point CLion to a Makefile in the Open dialog.
- CLion might ask you to Clean the project. This is required as the Make build is incremental and when run on an uncleaned project only the updated files will be compiled, so project reload won’t work correctly and will miss all the unchanged files.
- CLion will now try to load the project.
- When the project is loaded successfully, you can start working with it in CLion and benefit from all the smart IDE features it provides.
There are important settings you can tune if the defaults don’t work for you. Go to Settings/Preferences | Build, Execution, Deployment | Makefile settings:
Here you can change:
- Toolchain used to load the Makefile project. All local toolchains (Clang, GCC, MinGW, Cygwin, WSL) are supported. Visual Studio toolchain relies on NMake, which is currently not supported, but if you manage to build your project using GNU Make then it will work in CLion. Remote mode is not yet included.
- Arguments used to call the
makecommand in CLion to extract the project information.
- Build and Clean Make targets used along with the
makecommand in CLion to extract the project information. For Build, an empty field means CLion takes the first target specified in the project’s Makefile.
Here are a few final tips for you to work with a Makefile project in CLion:
Tip 1: CLion searches for targets in your Makefile project so that you can start using them in the Run/Debug configuration instantly:
And if CLion fails to find your Make target, you can create a Custom Build Target with type Make and use it in the configurations:
Tip 2: Out-of-source builds are supported, but you’ll likely want to call Tools | Makefile | Change Project Root after the project loading to get your sources presented nicely in the Project View.
Tip 3: Currently, CLion doesn’t update or reload the project automatically on any file changes, like for example adding a new file. The notification on the Makefile will appear after you update it, so that you don’t forget to reload the project. However, if the configure step is used for your project, don’t forget to call it first to update the Makefile and get the notification.
What can I do if something goes wrong and my project fails to load correctly?
We’ve tested it on a long list of projects, which you may find on our confluence page. And we hope it also performs for a huge variety of others, including yours. However, if you meet any issues, here is a list of actions you may take:
- Check the Toolchain you are using in Settings/Preferences | Build, Execution, Deployment | Makefile settings. You should be able to build the project in the selected environment.
- Check reload arguments and build target in Settings/Preferences | Build, Execution, Deployment | Makefile settings. Most of the projects which worked successfully for us were fine with the default argument, but you might need some changes there in your case.
- Try Tools | Makefile | Clean and Reload Makefile Project.
- If the steps above don’t help, try cleaning the project from the /makefiles in the system directory. For example, for the postgres project on my macOS, it’s ~/Library/Caches/JetBrains/CLion2020.2/makefiles/postgres.dc29ef09. Reload the project after that.
- Finally, if all the tips from the above don’t work for you, go to Help | Diagnostic Tools | Debug Log Settings… and turn on the debug logs by adding #com.jetbrains.cidr.cpp.makefile. Then reproduce the problem and submit the logs to our tracker or support.
Known issues and limitations
The most fragile part of the algorithm used is extracting the compilation commands from the
make command’s output. We have found issues happen in some cases:
- The project is suppressing printing the directories. And so the algorithm fails to correctly detect which source files are actually being built.
- The compiler is unknown or compilation flags can’t be correctly extracted. Various wrappers like
libtoolmake things worse by hiding the compilation flags and interfering in the Make’s output (CPP-19549, CPP-19305).
We’ve put several heuristics in to overcome the cases like that we’ve experienced on our test projects. The users can also control the arguments used to call the
make command while extracting the project information: Settings/Preferences | Build, Execution, Deployment | Makefile | Arguments.
- There is a Makefile support plugin which provides code highlighting and some support for building make projects. The plan is to rework and bundle it into CLion (CPP-16933).
- Unit testing integration will be enabled for Makefile projects later (CPP-20718).
- Add an ability to link Makefile to an existing project (CPP-20733).
- Changing toolchain or other settings affecting the project load should trigger the reloading (CPP-18982).
- To expand the support to GNU Autotool projects, allow users to set up the "pre-configure" step for Makefile projects (CPP-16924).
- Support non-GNU Makes (NMake, BSD) (CPP-18723).
- Implement the approach with compiler wrappers and make it work in combination with the current one.
But before all that, we plan to polish the current prototype and fix various issues. And at this point your feedback is really important and valuable. Please report any issues you face to our issue tracker.
Mind the list of projects we’ve already tested our prototype on: Makefile projects in CLion.
Your CLion team
The Drive to Develop