Build Entire Project

This is the top missing feature for me right now.

Kelly, CLion developers have made one strange decision: always create four cmake caches for different build types (DEBUG, RELEASE, RELWITHDEEBINFO, MINSIZEREL).

Most of users want do select only one build type and work only with it.
Eclipse works with one build type, all custom Makefile work with one build type, KDevelop works with one build type. But CLion wanted to be 'unique'.


After that strange decision CLion started having a lot of problems, which is extremely hard to solve. Examples:

* you cannot run 'make' manuallly
* you cannot run 'make install' at all
* you cannot specify 'EXECUTABLE_OUTPUT_PATH'
* you cannot specify 'LIBRARY_OUTPUT_PATH'
* you cannot build all project, only particular target
* you cannot run script that prepares cmake env
and so on

And what do CLion developers do now? They try to develop lots of workarounds. For example in recent build they introduced 'Build Output Path'. This configuration option is absolutely useless. It covers none of the problems. It just proves that CLion developers have never tried to build any non-empty C++ project themselves.


Manuel Riecke has posted quite detailed description of typical C++ project setup in comments to CPP-838.
Let me repost it here:

Manuel Riecke  14 Oct 2014, 14:31

Let me outline how a typical modern C++ workflow can look like under Linux. (The same workflow works under Windows too, but is less typical.) Set up a folder structure like this: Buildsystem/ ./Install ./Build ./Source Add Buildsystem/Install to the CMAKE_PREFIX_PATH environment variable so that CMake finds libraries and binaries installed there. Add Buildsystem/Install/bin to PATH environment variable so you can access the binaries there from command line. Add Buildsystem/Install/lib to LD_PATH environment variable so it finds the shared libraries when starting a application. For every library your project depends on: git clone it into Buildsystem/Source Create folder Buildsystem/Build/name_of_lib and run CMake from there. (Out of source build so that the source folder doesn't get cluttered, for some projects this is necessary.) make install to install it to Buildsystem/Install And finally open up your own project and code to your hearts wish. It would be very nice if CLion could support this kind of workflow. For that is just needed: Ability to set a custom build directory. Ability to invoke make install. Further would be "nice to have" but not necessary: Ability to set a CLion-local default install directoy. (e.g. a value that CMAKE_INSTALL_PREFIX in the project configuration is defaulted to.) Ability to edit the system-wide and/or CLion-local CMAKE_PREFIX_PATH environment variable.

Hi,

i can confirm this:
* you cannot specify 'EXECUTABLE_OUTPUT_PATH'
* you cannot specify 'LIBRARY_OUTPUT_PATH'
this.

both worked in 2014* versions of clion.

we create a framework with libs and plugins and it is a must,
that libs and bins will be where we define them to be.


some more criticism:
clion/cmake create a lot of stuff we do not need.
we mostly work with "Release" so we do not need "Debug" folder within .clion10/system/cmake/generated

i hope this behaviour will be corrected because i want to use clion for much more as playing around.

greetings

Olaf,
do you need to set different output paths for EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH or are they the same?

Hi Anton,

i need both.
EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH pointing to different locations.
hope that jetbrains "can allow" cmake to act in expected way.
Everything works fine if i start cmake project from bash.

And within same context:
I also want to create ALL targets with one click - like i can do from commandline.

Thank for your interest Anton.
I like clion very much - but i was also very disappointed because of this behaviour.
Guess it is not easy to bring harmony between clion and cmake.

Greetings
Olaf

Olaf,
let's separate two issues: building all targets and specifying EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH.
The first issue is on the short-list (CPP-158).

As for the second - specifying output paths - could you please describe the use case?

EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH are outdated variables. If you need to point the executable and library output directories in a way that's compatible with the latest CLion build you can use RUNTIME_OUTPUT_DIRECTORY and LIBRARY_OUTPUT_DIRECTORY target properties.

I agree building all projects is a different issue than other CMake issues.

Build Types:

We would like to define our own build types.  For our command line builds, we do the following:

#!/bin/bash

mkdir -p debug_shared
mkdir -p release_shared
mkdir -p release_static

cd debug_shared
CC="distcc gcc" CXX="distcc g++" cmake -DBUILD_SHARED_LIBS=TRUE -DCMAKE_BUILD_TYPE=Debug ~/source/

cd ../release_shared
CC="distcc gcc" CXX="distcc g++" cmake -DBUILD_SHARED_LIBS=TRUE -DCMAKE_BUILD_TYPE=Release ~/source/

cd ../release_static
CC="distcc gcc" CXX="distcc g++" cmake -DBUILD_SHARED_LIBS=FALSE -DCMAKE_BUILD_TYPE=Release ~/source/
cd ..

Most of our deployed software is statically linked, but we have some python and java plugins that require dynamic linking, hence two different release builds.  We will never use the other types of builds, so don't prepare them.

Build and Binary Locations:

The above results in separate bin and lib directories under each build directory that are knowable so developers can add ~/build_root/debug_shared/lib to their LD_LIBRARY_PATH and PYTHON_PATH.  I believe it is useful to have these directories outside of the clion config directories (~/.clion10), as that makes it easy to do things like write a nightly script to svn update and do a full clean/build.

-K

Also, there doesn't seem to be a way in the settings dialog, cmake section to specify the build type, so changes there affect all builds.  So 'build output path' causes all binaries from all build types to be dumped into a single directory.

-K

Anton,

we have a little cross platform Framework with dynamic libraries and plugin architecture.

and

add_subdirectory (libX)
add_subdirectory (libY)
...
add_subdirectory (pluginSimple)
add_subdirectory (pluginQtDraw)

pluginX)

...

programX)
add_subdirectory (programY)
...

Every subdirect has its own CMakeList.txt 
clion find all stuff and show in Run/Debug configurations - ok

All libs, all programs and all plugins have different locations.
This can be done by setting EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH witin cmake.
And after i run cmake from bash, all bins and libs are in the desired folders.
This never happen with clion.
clion do not care about my wanted bins-libs-plugin dependcies.
Bad workaround is a globally override like "Build output path" and adapt my plugin loader source code, etc...

From my point of view clion should respect my decision where my bins and libs should be .... specified
by EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH.

Both ways, building within cmake/clion and building within cmake/bash should create same results.

greetings

Kelly,
is that correct that you need the following functionality:
1) have artfacts, produced by dufferent build types in separate folders (e.g Debug, Release... etc)
2) additionaly be able to build an arbitrary build type + set of options into a specified folder.

If everything is clear with 1), it's not that obvious with 1). how do you intend then to use these artifacts in or outside of the ide?

BTW, you can select which configuration type to build in the Run Confiiguration dialog.

Thanks for the details Olaf,
I can understant your pain, and we are trying to come up with a solution; but I'm afraid that without fully understaning your specific case, chances are we'll have a solution for a different problem.
Could you maybe create a basic sample project which mimics yours and describe the steps you take in command line so we could repeat them and better understant the problem? (Ideally in the tracker)

Many thanks for your help.

Anton,

Re 1&2, yes, I would like to specify/configure/name the build types I want and I would like to know where the resulting libs and exes will end up.  It's been so long since I set up our CMake config here, I forgot that I had to specify ouitput paths... deep in our cmake config I have this:

set( EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/bin )
set( LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/lib )


I do lots of things outside the IDE.  In fact, I would prefer an IDE to not be an IDE at all, but a really nice editor that works with my build system in concert with command line.  (I realize my wishes may not be typical)

All of our developer's machines have full source and nightly builds set up.  Throughout the day, when running any of our programs, developers run their local build rather than installed versions.  During development, it's easier (for me anyway) to run from the command line rather than via the IDE, especially if the program is part of a pipeline.  I imagine there's a way I can do this from the IDE:

cat test_input_file.txt | ./bin/program

But why would I?  It's trivially easy to type that on the command line, switch between multiple different input files, etc.  IDE does not make that easier.


I realize I can select the build/run configuration from that dialog.  But there doesn't seem to be a way to adjust CMake settings based on build type.

Hi Anton,

i was thinking about creating a sample project.
cmake main dir
cmake child dirs with cmake

but before i do this i want to know one think:
Will clion accept my cmake files as they are ?
Maybe with an extra switch  use "TAKE CMAKE INSTRUCTIONS 1:1".
Because this will solve all problems ... from my point of view.
In general it is a major request from lot of software companies i worked.
Build process must be transparent - it should build/run without IDE.

Within CLions its different.
All stuff build/run without clion.
If i want to use CLion for typical build-run,/build-run, .... lions fails.

All be hand from bash work like this:

cd build
cmake ../
make -j 4

And after this is
Every target is build and every expected binary is wher it should be.
-------------------------------------------------------------------------------------------------------------------------------

Some other stuff, which is in my mind:

I hope that jetBrains give developers time enough to create good, stable product.
Its a big chance. Lots of C++ developers (some ex java developers also) wait for a good IDE
like IntelliJ .
I know C++ is much harder than Java IDE. And i hope jetBrain managers know this also.
CLions approaches are very good. But for my taste its going to fast.
So lion is in danger.

C++ needed many years to become 11. Maybe to slow - but now we all have good quality.
We all do not want to wait years that lion will be officially out.
Speaking for myself - i can wait half year longer. Specially if problems are not solved.

An economic idea could be:
Let clions users pay a little to support Beta version.
Register,license, etc....
If first official release is published and we want to buy clion 1.0 - litte money already payed for beta
should be considered. Just an idea from my side. Because i am using clion now like it is.
And others also.
Beta users should pay - but never must pay - this is the difference.
Dynamically between 5 % and 100 % of price per single developer license.
Or - if jetBrains does not know about the price - just say between 10 and 200 Euro.

Managers will be happy to see that lions developers are on right way.

But if they press to much .... your good ideas and ideas from comunity can not be implemented accurately.
I have seen projects suffering a lot because of wrong balance between expectations,progress and quality.

Greetings,
Olaf

I have the same problems as Olaf. My project uses a self-written library and third-party libraries and there are several applications derived from it. These are built separately in different directories. Plug-ins will also be added in the future. As Olaf said it, the given CMakeLists.txt files should be respected. It is not unusual in practice, that a project will be compiled separately from an IDE. I think it is a good idea to spend a little bit more time to a better cmake integration.
CLion has all preconditions to be the best IDE for C/C++. So far from me, kudos to JetBrains :)

Thanks Vyacheslav.
It works!

I've just added the following to root CMakeLists.txt:

set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${EXECUTABLE_OUTPUT_PATH}")
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${LIBRARY_OUTPUT_PATH}")

Olaf, please file a request with a sample project that demonstrates the problem and we'll see that we can do.

Kelly, please check the comment by Vyacheslav below.

I'd like to thank everyone who participates in this discussion - your feedback is really important to make sure CLion moves in the right direction.
It's not always obvious how to support this or that workflow, though, in the IDE that is supposed to be simple to use - the command line and custom scripts will always be more versatile than any IDE.

We want to start with the basic functionality and make it right in the common scenarios first, and only then add more advanced features.

If you have a workflow you want to be covered by CLion, the best way is to report it as a request with a minimalistic sample project(s) that demonstrates this workflow.

Back to the issues duscussed in this thread:
1) we are going to implement Build All feature shortly: CPP-158
2) we'll add a separate folders for release/debug: CPP-710
3) advanced configuration options such as per-configuration CMake options (such as those described here) should not be expected soon, please consider implementing them in terms of custom CMAKE_BUILD_TYPEs
3) when we get sample projects for the rest of the issues, we'll decide if we want to implement them right now or wait for more use cases.


Thanks for your help and understanding.