CLion Requirements
I have a paid subscription to the all products pack because I use IDEA and PHPStorm for work. Outside of work I use C for a couple of retro platforms, cross-compiling from Mac OS and would like to use CLion.
For one of the platforms (Amiga) I was able to get everything working very nicely. There is a version of GCC 6 that cross compiles to Amiga C/C++, there is a platform NDK (SDK - I don't know why Commodore called it an NDK) I can point CMake to and I was able to get full code insights and intellisense working in CLion. The experience is great.
I have spent a couple of evenings now trying to get the other platform (Vectrex) working and haven't been able to get anywhere.
Does CLion HAVE to use a GCC cross compiler or can it be made, via, CMake to use any compiler? Also can it be made to take small steps, not expect to do everything in one go? I probably need to explain this part.
At the moment I build using a custom bash script and Xcode. It's clunky but it works. I use a 6809 assembler to compile the crt startup code to s19 format, gcc-6809-cc1 to compile (but not link) the C code to assembler, then the 6809 assembler again to compile this to s19 format, then a program called aslink to join the parts together and a final step to convert it to a ROM binary.
Now, I realise that this is more CMake related than CLion related, but I can't help but feel like I'm not just fighting with CMake here, but also the way that CLion wants to use CMake.
Can this setup be made to work from within CLion or am I really wasting my time ??
I understand the editor won't like the assembler as it's not AT&T format but there's very little of it so it doesn't have to understand it. The 1 file can be edited externally and any inline ASM will be minimal. It would be great if it could understand the C parts, read my include files and provide error checking / code insights?
Thanks.
Please sign in to leave a comment.
Very quiet in here! I had hoped that someone would at least have had something to add on the subject of whether the above may even be possible!
For what it's worth I've got intelligence working. I don't know if it's working correctly because until I get compiling working I don't know if it's making suggestions based on clang or something, or based on the C std level I've specified.
I think to see if I can get stuff to build I'll look at cmake custom actions but I've no idea what CLion is going to make of them.
Hi, Martin.
Generally, if you'll manage to set up this in CMake, CLion should be able to use it, as it is only interested in compiler flags used for compiling C code, and just calls `cmake --build` to actually build the project. However, I don't know whether how complicated it could be to achieve it via CMake. Please make sure that the `CMAKE_CXX_COMPILER` variable points to the actual compiler and the .c files are added to some CMake target. Here is a general tutorial about cross-compiling with CMake: https://cmake.org/Wiki/CMake_Cross_Compiling.
I've been able to get this to work by more or less completely using custom commands ('add_custom_command' plus 'add_custom_target') for all stages of the build.
I was not able to use CMAKE to do the compiling itself as you would traditionally cross-compile because I have to use cc1 to produce assembler source and then assemble that source, finally linking and turning it into a binary image. I haven't had time to investigate yet but I think this is mostly because my gcc-6809 isn't compiled correctly. The individual tools work but the gcc "wrapper" application just spits out assembler instead of actually running. There's something very wrong my end on that.
In order to keep CLION happy I simply added a fake target executable called "fake" and added a single main function that simply returns 0. I was then able to add my source and include folders to the project through the IDE and I now get code intelligence and 'intelli-sense' from the IDE. I was also able to add full touch bar support for building, running etc. through the use of an external program and keyboard shortcuts. (Wish JetBrains would pull their finger out on this, it's a major reason for using the Mac!!)
I haven't had much time to work with it yet and it seriously felt like I was fighting against the IDE, not the IDE working with me but if it works, it works. It would also be a major plus point if more that just AT&T assembler dialect was supported.
I was going to achieve something like this. I'm a student. We study CUDA (nvcc compiler) , MPI (intel... something compiler) But CMake says it doesn't support anything but bare GNU C/C++.... By using gcc compiler instead of nvcc and
#ifdef __JETBRAINS_IDE__
#include <host_defines.h>
#include <driver_types.h>
#include <cuda_runtime_api.h>
#include <device_launch_parameters.h>
void __syncthreads();
#endif
and //@formatter:off
I was able to get the code-completion
Thank God I could asociate .cu files with cpp But still had to compile everything through console
and use a dummy cpp file with
int main(){
//This is to SHUT UP the CMake
//That's looking for .cpp with main()
return 0;
}
along each CUDA target that I specified in CLion
since I CAN"T SIMPLY WRITE Bash-like commands explaining CMake what and how it should compile as I would in make. Very disappointing... Why so many problems instead of polishing the existing build system a bit and so attracting new developers I don't know... It could simply be a plugin called Nvidea Cuda
And here is a separate problem:
I was also going to complaint about it some time later but found your topic. I'm also going to complain that I CAN'T SPECIFY NOT THE FULL PATH TO GDB EXECUTABLE but to force Clion do so:
Build executable on local machine then do ssh and ON REMOTE MACHINE exacute GDB and whatsoever connected to it.
On my university cluster we can connect to say node n1100 and work on it. THere we have GPFS - a distributed file system and also all the open IPs/ports are forwarded through So In short Clion wouldn't even notice a difference if I could force it to execute whatsoever connected with GDB not on local mgmt node (where I run Clion) but on a separate node. The thing is: on mgmt node there are lots of compilers , tools available that are not available on other nodes. However GDB doesn't work on mgmt. node And to debug (run) I don't need abilities of mgmt node (If I link everything needed in the executable) . But I need to compile on mgmt node...Though I now realized that it's already gonna me implemmented in 2018.1 (Remote debug via SSH (w/o gdbserver)) isn't it?
I'm lazy to start that topic...
Anyway, guys from Clion team I know you read it If you want I can describe my experience using Clion for CUDA and MPI
I'll be honest, I don't really understand most of what you wrote or how it relates to my topic, but on the remote chance that it might be useful to you or anyone else, I created a Gist with my CMakeLists.txt in it.
Note, this is 100% probably not the right way to go about this!! I just hacked something together until it worked. There will almost certainly be better and more correct ways to do it!!
https://gist.github.com/Guddler/a0fdb917aa04a001da22edf775ff5ff2
Thanks a lot Martin. Someday I'm going to post my above message in a separate topic named "remote debug usecase" but now I'm lazy to do so. Though I now realized that it's already gonna me implemmented in 2018.1 (Remote debug via SSH (w/o gdbserver)) isn't it? Your CMakelists may help me - I'll see...