Using makefiles for autocompletion if the makefile is meant to run with docker

Hello!

What CLion version do you use? 

Hello,

I am on CLion 20201.1.1 Build #CL-211.7142.21

Hello,

Would it be possible to use some sort of a cscope of ctag system that vi uses? Not having code autocompletion/definitions/usages/refactors really negate a lot of uses of Clion.

In CLion 2021.1 the full remote mode is supported for Makefile projects - https://www.jetbrains.com/help/clion/remote-projects-support.html . Feel free to try using it.

Also this link might be useful - https://blog.jetbrains.com/clion/2020/01/using-docker-with-clion/ (it's about CMake projects, but still).

I've spent several hours of frustration trying to make everything work in a dockerized setting, makefile and remote debugging. It doesn't do the job. Can your IDE not tag local files in a directory and then do auto-complete/find references without a makefile or cmake file? This is something vi does (and literally every IDE). I find it baffling that Clion will not find a class definition if it can't parse the makefile - surely your product is more robust than this?

Even if I can somehow manage to get all this working in remote mode, it's horribly slow trying to push everything into the docker container. Working full remote is not a viable development solution. This is a project with complicated build dependencies. It will be extremely hard (if not impossible) to map out the mk files in the docker mounted file system since they are environment variable dependent. Additionally, your model of remote development forces me to open up an SSH port in my container, which is currently NOT recommended by Docker. You are supposed to use an openssh server with sandboxed access.

https://docs.docker.com/samples/running_ssh_service/

Running sshd inside a container is discouraged

>I find it baffling that Clion will not find a class definition if it can't parse the makefile

C++ is the language which parsing/resolve requires some extra knowledge like compilation flags, header search paths, etc. This information is stored in the project model and has to be extracted from there. So the build system integration is basically essential for truly smart code features.

Sorry for disappointing you.

>Additionally, your model of remote development forces me to open up an SSH port in my container, which is currently NOT recommended by Docker

We plan to skip source synchronization in case of Docker in CLion 2021.2 EAP cycle (CPP-14315 is already ready to test).

>We plan to skip source synchronization in case of Docker in CLion 2021.2 EAP cycle

But the whole point of having docker is to use things docker exec and docker mount. You can achieve synchronization without doing anything on your part. Docker has done all the lifting for you

>C++ is the language which parsing/resolve requires some extra knowledge like compilation flags, header search paths, etc. 

Again, literally every IDE handles it without needing to know how to build. Building and tagging are two separate events - by creating a dependency like this, and not using all the abstraction docker gives you, what's the point in saying you have "docker integration"? In the real world applications such as mine have 16+ microservices. Some run from independent repos, in one case 4 services launch from the same repo. The dockerfile settings are for a multi stage build, and are set up so that multiple teams can push updates. Do you expect each service to open up a port just to tag code? Why reinvent the wheel?

Again, if you don't provide all "smart" features that's an acceptable compromise if I can at least see my class definition, and simple things like vector<int>.push_back.

You can implement this with a simple grep command. I fail to see the need for building to know where a class definition exists. Give developers the tools they need and don't force incorrect development models on them.

Are you telling me that if you have the directory structure of

projectRoot

    inc

   src

You can't create a tag file without being able to build? All the sources are right there?

Dear users,

I understand that the lack of basic things like autocompletion is pretty annoying. But an IDE is not a text editor, which does the things approximately. It needs an AST to work with and be more accurate, treat the symbol context, compilation flags, etc. And building AST w/o parsing the project model is kinda impossible. W/o proper information about AST, we can only make assumptions about the code structure, which in turn, for C++ especially, can produce many false positives and false assumptions.

Saying this, I have to add that we can consider switching to some basic text-based-search model in case the project model is not available or can't be parsed correctly. However, the requirements for such mode are not clear to us and I'm afraid the quality won't be to IDE standards. But you are right, that this might be an option.

As for the original case, we have another approach to consider - since CLion is parsing Make output, we think we can implement a solution when this output is simply produced on another machine and CLion is parsing it locally. This seems to resolve the original problem. What do you think, @limk?

>However, the requirements for such mode are not clear to us 

The requirements and design problems were solved over 30 years ago - http://cscope.sourceforge.net/large_projects.html

http://cscope.sourceforge.net/

This seems to be more like an official position and less like a technical problem. I've used both Clion and ctags for years. The latter has no issues resolving namespaces and ambiguous definitions. 

>we think we can implement a solution when this output is simply produced on another machine and CLion is parsing it locally. 

Can you please give me more details? When you say "another machine" do you mean a docker instance?

@limk yes, in your case it would be docker.

Thank you. That sounds interesting and I'd be willing to give it a shot. Currently, I have a "makefile" that has scripted docker make commands that I call "makeDock". Running any make target on this file invokes the actual make command which uses the real Makefile with the targets. Docker compiles work thru' clion just fine, and I can bring up my application (and all microservices) with a docker-compose.yml file. All this works just fine, but lacks any IDE features. I can do all this thru' vi and iterm (plus the tagging) but Clion consolidates all this into 1 window. At present the benefits of Clion are only to consolidate my code and deployment in 1 window - not much else. That's cool and all but not sure it's worth the cost for multiple licenses for our team.

Any solution here that doesn't involve shunting 700 MB of data back and forth is welcome. I have about a week left on my evaluation license before I make a recommendation to the team on procuring the licenses.

@link, Ok, we'll discuss it with the team. But I doubt we can come up with some changes in one week. But when this is available, you will be able to check it out in EAP builds which are free to use (like now we are running the 2021.2 EAP).

Saved the idea to the feature request if anyone wants to follow for the updates or upvote: https://youtrack.jetbrains.com/issue/CPP-25385