Possible to have CLion build a project with an external command, e.g. make?


I have a project that is built with Make, ChucK, which I'm trying to edit with CLion. I just installed CLion, so I'm still trying to get my head around it. Is it possible to make CLion build the project with an external command, i.e. make in this case? How do I tell CLion which files belong to the project?


CLion takes the information about the file included into the project from the CMakeLists.txt files. So CMake build system is necessary for your project to be supported in CLion.
We are planning to support more build systems after 1.0 release probably: http://youtrack.jetbrains.com/issue/CPP-274. In particular Makefiles: http://youtrack.jetbrains.com/issue/CPP-494


OK, thank you for confirming that Anastasia, good to know.


The build system at my company is a complex system of Makefiles. So to experiment with CLion I found it easiest invoke our existing build harness rather than trying to covert all of the information to CMake. Using:

add_custom_target(target_name ALL build_command build_arg1 build_arg2 WORKING_DIRECTORY working_dir SOURCES ${SOURCE_FILES})

you can replace "build_command" with whatever you want and pass the desired arguments.

Since this is not a "buildable" target in CMake parlance, I also found it necessary to add a buildable target to get calls to include_directories and the like to be respected for parsing. Adding something like:

add_library(target_name_bogus_indexing_target EXCLUDE_FROM_ALL ${SOURCE_FILES})

did the trick for me.


Thanks for that tip Ryan. Didn't quite understand what you meant about the add_library bit, but I wanted to add what my CMakeLists.txt looks for anyone else coming here looking to set up a harness of sorts

cmake_minimum_required(VERSION 3.9)

add_custom_target(target_name ALL build_command build_arg1 build_arg2 WORKING_DIRECTORY /some/path)

I skipped the SOURCE_FILES part since I haven't defined any, and I really just want targets that I can play with. With this I have target_name in the list, and I can build it, in which case it calls my build system, and I can set different executables and run them. Works for me!

Update: I also replaced "/some/path" with "${CMAKE_SOURCE_DIR}" so that I don't have a dependency on my local machine and can check this file into my VCS so that others on my team can benefit from it :)


My 2c I also have a build system which does a lot, generating code, more than one language etc.  It would be easy in that system, and most likely other systems as well to generate a file with the information CLion needs if the format and location of the file is known.  It it could be refreshed any time a the project is built.  Is it possible to do this with a CMakeLists.txt ?

I assume CLion would need to be provided with everything supplied to the compiler, #defines, include paths, and source files, and possibly some of the compiler flags, and the the location of the final outputs  from the link ?


Hi, Peter. 

In CLion 2018.2 we've added support for compilation database format, it might be interesting for you. It means that now you can open a project by loading its compilation database. A compilation database lets CLion detect project files and extract all the necessary compiler information, such as include paths and compilation flags. You cannot build or run for now, but code insight does work for such projects. More information about Compilation DB support in CLion can be found here: https://www.jetbrains.com/help/clion/compilation-database.html. We are going to support building for such projects (https://youtrack.jetbrains.com/issue/CPP-14271) and also an ability to add build system-independent build targets (https://youtrack.jetbrains.com/issue/CPP-14472).


I will check it out as I get more into using CLion - I just downloaded it and am trying out on some emscripten wasm projects :)

My fantasy would be if you had a command line utility or a "generator" for your CMake that would generate or update your database from a simple format which would be easy to generate from any competent build system. This would be designed to allow others to maintain the connection to the IDE.

That and a way to specify "commands" for the menu build targets and configurations. ( which could be part of the "database" IDE update format )

The idea being the custom build auto maintains the IDE when you alter the definitions in it, and it will refresh the database and update the IDE.

For now I put a target in our build system to generate CMakeList.txt files from our build.  The "add_custom_target " trick does work to put an entry in your build menu and run the build.  Next (reading cmake docs ...) trying to figure out how to call our "clean" target and targets for your default Debug and Release configurations. I have been using our build for the past 5 years to build large native C++, assembly, java projects with generated code in intellj but had to put in all the calls to it as ant targets. ( ant is um ugly )

Over decades of writing makefiles, Nmake files, etc and loathing it's syntax and arcanity along with shell scripts and perl I decided a while back to create an "object oriented" build system for large projects written in Ruby ( and rake with a bunch of tweaks )  which has served us incredibly well.  Though not really mature (is it ever?) I put it on rubygems as "rakish".

Thanks for this info !


Thanks for the detailed response! Feel free to comment or upvote the issue in our tracker about custom project model support (https://youtrack.jetbrains.com/issue/CPP-1607) in order to get updates.