1

I understand that by default, Clion creates the binary files for a project loaded in Clion in all the four configurations:

(Debug;Release;MinSizeRel;RelWithDebInfo)

as well as one called: __default__.

I am using a third party cmake module which downloads an external project in a way that add_subdirectory() can be run on it so it would be included in the root project. 

add_subdirectory(${downloaded_proj_src_dir} ${downloaded_proj_bin_dir} EXCLUDE_FROM_ALL)

In this setup, if I decide to place the child project outside the binary directory of the root project, I get:

Error:Binary directories outside of CMake build directory are not supported. Most likely this error is caused by an add_subdirectory command with an explicitly specified binary_dir argument.

which is an understandable restriction by CMake.

now if I instead decide to set the binary directory of the downloaded project in a subdirectory of the binary directory of the parent project, ie:

set(downloaded_proj_bin_dir "${CMAKE_BINARY_DIR}/${downloaded_proj}-build")
...
add_subdirectory(${downloaded_proj_src_dir} ${downloaded_proj_bin_dir} EXCLUDE_FROM_ALL)

I will get the file created in the parent binary directory of all the build configurations because ${CMAKE_BINARY_DIR} is different for each configuration. To avoid seeing all these directories listed on the project view sidebar, I have set the CMAKE_CONFIGURATION_TYPES to be Debug. But even then, I get:

Error:Configuration Debug The current CMakeCache.txt directory /path/Debug/downloaded_proj_bin/CMakeCache.txt is different than the directory /path/__default__/downloaded_proj_bin/CMakeCache.txt where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt

Clearly something is going on with this __default__ configuration which I don't understand. So the question is, what is the significance of this default configuration and why should there be a conflict here?

P.s. Setting the configuration to __default__ does not solve the problem as I will have a __default__0 configuration created instead and get the same error.

Update: some further observations

  1. My enviornment variables set in IDE don't have any effect on the cmake builds.
  2. Cmake "options" however which presumably will be passed as arguments to cmake do seem to work. -D CMAKE_CONFIGURATION_TYPES=Debug.
  3. When I specify the command line option, I get

Warning:Manually-specified variables were not used by the project: CMAKE_CONFIGURATION_TYPES

But it clearly does have the effect of no longer creating the other build configurations. My guess is that this message relates to the __default__ build which is ignoring the argument.

  1. Even in the case of specifying CMAKE_CONFIGURATION_TYPES in the IDE, I still get the additional __default__ build which is apparently unaffected by the CMAKE_CONFIGURATION_TYPES assignment.
  2. Logging: message("Build type: ${CMAKE_BUILD_TYPE} ) does not return any build_type.
  3. Outputting message(and generator: ${CMAKE_GENERATOR} ") returns "Unix-make files" for both, so both are being generated with the same generator.
  4. Taking a diff from the CMakeCache.txt files, I can see that they are identical.
Maths noob
  • 1,684
  • 20
  • 42
  • A few more things for you to clarify in your question: (1) How/where are you trying to set CMAKE_CONFIGURATION_TYPES? (2) What CMake generator do you/CLion use when running CMake? (3) Have you copied anything around in your testing (probably not a good idea)? (4) Do you get the same error if you wipe out your build directory and start afresh? – Craig Scott Apr 27 '16 at 10:22
  • @CraigScott 1) I did it in clion's options: http://postimg.org/image/hx8b4154x/ 2) For some unknown reason, after I experimentally added: set(CMAKE_CONFIGURATION_TYPES Debug CACHE TYPE INTERNAL FORCE) before project() and just deleted my binary directory it is giving me: Error:CMake was unable to find a build program corresponding to "Unix Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool. Error:CMAKE_C_COMPILER not set, after EnableLanguage Error:CMAKE_CXX_COMPILER not set, after EnableLanguage am trying to get it working again. 3) No 4) yes. – Maths noob Apr 27 '16 at 10:36
  • It is starting to sound like CLion has cached some things that you are changing in ways it can't cope with. Does CLion have its own project file (additional to CMakeCache.txt and CMakeLists.txt)? If so, try removing it and recreate a fresh project. – Craig Scott Apr 27 '16 at 11:00
  • 1
    Also, if CLion is using the "Unix Makefiles" generator, then under the covers it would have to be setting up 4-5 completely separate builds. The Unix Makefiles generator is single-config. CLion may be simulating multi-config by managing the 4-5 build types for you. Trying to fool it by forcing CMAKE_CONFIGURATION_TYPES may ultimately not be a viable path. [This link](http://stackoverflow.com/a/24470998/1938798) may help your understanding (not CLion-specific). – Craig Scott Apr 27 '16 at 11:02
  • @CraigScott yeah it did create separate builds. and I managed to get it to create only the debug build by setting the configuration type from the IDE. I just realized that my problem was that I had unticked the "pass environment variables" option. this got rid of the errors that I had mentioned above, but I am still getting the original error that I described in the question. I will have a look at the look you had linked to thanks. – Maths noob Apr 27 '16 at 11:47
  • @CraigScott I summarized my observations in the update. Does this make it any clearer? – Maths noob Apr 27 '16 at 13:42
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/110433/discussion-between-craig-scott-and-user4376555). – Craig Scott Apr 27 '16 at 20:39

2 Answers2

0

Do you have in DownloadProject.cmake the right setting? for:

set(_DownloadProjectDir "${CMAKE_CURRENT_LIST_DIR}")

I had the same problem trying to set google test(with the help of https://github.com/Crascit/DownloadProject) and my _DownloadProjectDir was setted as "test". Maybe when I moved this cmake file in my project Clion changed that automatically.

michoo_42
  • 1
0

So, it turns out that you can sort this out quite easily by adding the following line above line 145 in DownloadProject.cmake:

file(REMOVE "${DL_ARGS_DOWNLOAD_DIR}/CMakeCache.txt")

This seems to be because CLion copies the default across to the other configurations and doesn't clear the cache. This is a problem only because DownloadProject creates a project within the project (I think...). Anyway, deleting this file before configuring the CMakeLists.txt by-passes this issue. I'll submit a pull request to the DownloadProject repository as this doesn't seem to have any adverse effects when not using CLion.

Chris S
  • 1
  • 1