External symbol lore stopped to work with remote Makefile based project
I have a Makefile-based project configured remotely via SSH. CLion correctly runs compilation and remote compiler error parsing. But, since the remote machine reinstallation, it canʼt recognize any symbol outside the project. This includes definitions from system libraries: functions like sendto() or OPENSSL_malloc(); macros like SA_LEN. In Problems -> Current file, it reports "not found" for each header of used libraries (openssl, srtp, etc.)
The apparent triggering event was a minor upgrade of target installation, but I doubt this is the real reason.
Project-internal symbols are recognized without visible issues.
No typical cleanup actions as "Clean and reload Makefile project" or "Invalidate caches and restart" fix the problem. I also tried to disable clangd - nothing changes.
CLion version is 2021.2.3, running on Ubuntu 20.04, target system is Oracle Linux 7 (based on RHEL 7.9) with GCC9.
Additionally: I had a suspicion this is connected with remote toolchain configuration. At Settings -> Build, execution, deployment -> Deployment, there are 3 remote toolchains. There is an icon that says this is for the current project, but, attempt to delete a possibly obsolete entry results in warning on chance of use in other projects. It seems this part is mishandled by settings dialog.
UPD: There is a unit test which is included to top level Makefile using an intermediate one which iterates subdirectories. Its main file "does not belong to any project", but files included from the main code doesnʼt mark symbols as unknown. How it could happen?
Please sign in to leave a comment.
Hi Valentin!
Does `Tools | Resync with Remote Hosts` help?
hi Anna,
> Does `Tools | Resync with Remote Hosts` help?
Ha, seems fixed - stopped writing on unknown target (at least in the main code) and all hints started working. Thanks! :)
A dependent question: this project has special "unittest" goal which compiles and runs files in a set of subdirectories. CLion does not treat these files into a project. Even making a top-level goal (which refers another makefile) does not make it treat a unittest file belonging to a project. What logic does CLion implement here? Is there a suggested way to force it to understand the project structure?
Currently it looks like:
top level GNUmakefile:
unittest:
$(MAKE) -C test/nt all
test/nt/Makefile:
TOPTARGETS := all clean
SUBDIRS := $(wildcard */.)
$(TOPTARGETS): $(SUBDIRS)
$(SUBDIRS):
$(MAKE) -C $@ $(MAKECMDGOALS)
.PHONY: $(TOPTARGETS) $(SUBDIRS)
(I understand that migration to CMake would ease all the detection, but itʼs to be considered separately.)
Please go to `File | Settings | Build, Execution, Deployment | Makefile` and set all unittest in the `Build target` field. Then do `Tools | Makefile | Clean and Reload Makefile Project`. Does it help?
hi Anna,
> Does it help?
Yes, thanks :)
It is not apparent in any way that the field can contain a set of targets, itʼs labelled as "Build target". Let it be renamed?