CLion run configuration picks the wrong file for executable


I have a Mac OS X graphics app that uses Vulkan and Qt. The project creates a MACOSX_BUNDLE.

Everything used to work correctly and ran perfectly. Yesterday I updated to the latest CLion 2019.3.4

Now when I try to run, it does not attempt to run the executable but instead one of the resource files (compiled Vulkan shader). Of course this resource file cannot be executed....

How does CLion run configurator pick the actual executable in a Mac OS Bundle? Is there an easy workaround? I could pick the actual executable, but then would have to constantly adjust the path when switching between Release and Debug modes.

Official comment

CLion is using information from CMake to infer what executable file to use when launching run configuration.

I'm not sure, but I have a strong suspicion that your problem is caused by fix for this ticket - CPP-10292 It changed process how CLion selects executable. To check if this actually a problem here you can try switching to force CLion to use CMake File API (for this you need CMake 3.15). To do this just specify `-G <your generator>` (e.g. `-G Unix Makefiles`) in CMake settings ( If your issue goes away with these steps - then the problem is most likely with CPP-10292 

To workaround this issue for now you can explicitly specify what executable to use in run configuration

I am troubleshooting a similar issue.


I am using CPACK so that the build generated a .app file.  This works.  But when I try to run the app in CLion, I get an error 13 permission denied, as it's trying to execute the icon for the app.  The app runs fine if I go to the Finder and run it there.  It also runs fine if I use the Unix build instead of the Apple (not using CPack).


So it seems CLion is not running the .app, but is randomly selecting some file in the bundle.


Anna Falevskaya There seems to be indeed a relation. The symptoms are slightly different from the first post.


I have created a new target in which I specify the executable. It's a bit annoying because I need one for Release, one for RelWithDebInfo and one for Debug.


I have the same issue after latest update to CLion 2019.3.4 on MacOS: IDE attempts to run .metallib files from Resources in bundled targets of Metal graphics applications. Can be easily reproduced with any executable in public repository:


@Anna Falevskaya This does not look like issue CPP-11749, which was there sine 2017 release. The new issue described here affects any CMake bundled target (.app) on MacOS and is a regression introduced in CLion 2019.3.4 (everything worked fine before that). This should be fixed ASAP, cause it affects critical IDE functionality - developed applications can not be run or debugged...


@Evsgor, correct, this is not that issue.


I think that as this is marked 'Answered' it will no longer receive attention from Jetbrains.


I also have the same problem. In my case, CLion selects a JSON file instead of the executable.


Thanks for reporting this and sorry for the inconvenience caused. We were able to reproduce the issue and working on a fix, please follow this ticket Feel free to share additional details in the comments.


Same behavior here, in a different project. CLion tries to execute an icon-file (.icns) instead of the generated and working binary. Took me a while, because it appeared after I changed some CMake targets and the appearance of this bug was not very deterministic switching back and forth on the CMake settings. Does not happen with 1919.2.5.


The workaround provided by Semyon Kolton with adding explicit generator specification in CMake options (like "-G Ninja") worked fine for me - bundled app targets start normally again from CLion 👍


"-G Ninja" did the job and should have been there anyways. Thanks.


Just a quick update on the issue: we released 2020.1 EAP with the fix and going to backport this to 2019.3.4 later on.

Since we have only one reproducer of the issue, we'd really appreciate it if you could download the new version, try it with your project (without -G Ninja this time) and give us feedback. Thanks!


I saw the EAP and have tried it.  It now works for me.




Can confirm that it is fixed:

- EAP 2020.1 Feb 20: launches bin only with Ninja

- EAP 2020.1 March 4: launches bin in both cases.


Can confirm that EAP 2020.1 March 12 launches bin correctly


Please sign in to leave a comment.