Feature request: strip_include_prefix

[mbravi]

strip_include_prefix is currently being ignored by this plugin, with the result that for projects using the feature CLion can't find anything because it expects different #include.
The feature is of interest for projects with a rich directory structure (think boost), as it can be simplified in the dev environment, but still left intact when libraries are installed on the target system.
To clarify the issue let me provide an example:

My project structure:
project/include/dog.hpp
project/BUILD

BUILD content:
cc_library(
name = "doglib"
hdrs = ["include/dog.hpp"]
include_prefix = "animal/land"
strip_include_prefix = "include"
)

If I want to include dog.hpp from another part of my codebase I need to use the following #include or the compiler won't find the header in its include path, because of how Bazel virtual include path works:

#include <animal/land/dog.hpp>

What Clion wants me to use is

#include <animal/land/include/dog.hpp>

Effectively the issue is that without strip_include_prefix we either can not create a directory called "include" in our bazel package, but instead must use one with the name of the most external namespace, which means the dir structure of any two packages would be different (which is bad for huge projects), or must accept that the #include path starts with "include" (#include "include/animal/land"), which is weird and not standard beside forcing us to ceate in dev the dir structure we want when the package is installed, which makes for worse navigation.

[jwnimmer-tri]

Having landed here while researching RobotLocomotion/drake#7586, as I understand it the underlying cause is more about include_prefix than strip_include_prefix. I believe using include_prefix induces the _virtual_includes symlink farm that I believe is what's confusing CLion, while I believe strip_include_prefix only changes the -I paths sent to the compiler, without additional symlinks.

I plan to create a small, standalone project to illustrate and focus the issue.

[jwnimmer-tri]

In researching how CLion and bazelbuild/intellij negotiate include paths, I came to the conclusion that this might be very difficult to fix.

When compiling for cc code, the bazelbuild/intellij aspect uses the cc provider to learn about the structure of the build; in the cc provider, Bazel uses various symlink folders ("virtual_includes") to establish what the compiler will see. From all I could tell in its plug-in APIs and other bug reports, CLion does not know how to deal with symlinks at all, period, full stop -- it assumes each link is a fresh new copy of the file, and trying to teach it otherwise seemed doomed.

Since in my case all I needed was effectively to add $PROJECT_SOURCE_DIR/.. to my include path (so that I must say #include "myproject/package/file.h when in git we have just package/file.h), I put together RobotLocomotion/drake#7843 to trick CLion into using that path in the IDE, with Bazel's compilation unaffected.

I do hope this issue gets resolved, but I'm not sure there is much to leverage to be had on the bazelbuild/intellij side; it seems like a fundamental CLion shortcoming.

[brandonpollack23]

+1 on this

[thomasj02]

+1, particularly for include_prefix. Right now any project that uses this is unusable with CLion

[mstebelev]

+1.
I've found an issue about that on jetbrains site https://intellij-support.jetbrains.com/hc/en-us/community/posts/115000402310-Bazel-BUILD-files-virtual-directory-structure-not-understood-by-CLion
and they said "Hopefully, in one of the next releases, the technology will be there to rewrite the plugin properly", so may be that technology is ready now, after a year from that comment

[eugene-bulkin]

Has this gone anywhere? Unclear from @mstebelev's comment above whether that functionality is possible yet.

[thomasj02]

Is it possible to put a bounty on this or something to move development forward?

[sgowroji]

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.