CLion 2018.1.6 requires drake/tools/clion/bazel_wrapper (re-titled)

[sherm1]

Although our CLion instructions as of PR #9212 claim that CLion 2018.1.6 can be used with Drake, some installations using the recommended combination of ingredients fail to find many Drake symbols, leaving them red and preventing navigation. I saw this problem on a brand-new Puget running Ubuntu 16.04, and it has also been reported on an intern's new laptop installation. OTOH, when I upgraded my own laptop to 2018.1.6 it has no trouble finding symbols.

Edit: I am seeing red in some locations on my laptop also, including examples/multibody/cart_pole/cart_pole_passive_simulation.cc, while everything is fine in examples/multibody/cart_pole/bouncing_ball_run_dynamics.cc.

On the virgin machine I installed Bazel 0.16.1, Plug in 2018.06.11.0.3, and CLion 2018.1.6. No combination of clearing cache, re-syncing, and importing a new project resulted in the symbols being found. Dropping back to 2017.3.4 and its matching plugin worked fine, even using the same CLion project for which 2018.1.6 could not find symbols. It may also be important to note that symbols were located correctly in many Drake subdirectories, but were missing in many others (I was mostly looking in systems/framework, for example see context.h, but there were red symbols in other locations also).

Here is the link to a Slack discussion on this topic.

[soonho-tri]

All issues must have owners. @sherm1 could you suggest one for this one? (@jwnimmer-tri or @amcastro-tri ?)

[sherm1]

Assigned to @jwnimmer-tri for now.

[jwnimmer-tri]

I attempted to reproduce this:

• I removed the clion-201*.*.* install folders.
• I removed the ~/ClionProjects and ~/.CLion201*.* data folders.
• I reinstalled CLion and the plug-in (slightly newer v2018.08.06.0.1).

Almost all symbols seem to work fine (i.e., I cannot repro this issue).

I see in cart_pole_passive_simulation.cc two red squiggles (on DRAKE_DEMAND(!!cart_pole.get_source_id()); and cart_pole.get_actuation_input_port()). I also saw those prior to the reinstall. I think its just a CLion bug in their C++ handling, not anything bazel-related.

To make progress here, I'll need someone who is experiencing the problem to nuke their setup and screenshare me through their full installation steps and demonstration of the problem. My best guess at this point is that there is some installation step that we're doing differently, that is under-documented.

[jwnimmer-tri]

@amcastro-tri did a fresh Clion 2018.1.6 install on a new computer, and it seems to be resolving symbols just fine so far (no more than the usual 0.1% of red squiggles). Assuming his setup keeps working, I think I will have to do live screenshare debugging with someone who is experiencing this, to make progress.

[sherm1]

@amcastro-tri and I have identical machines so this is a disappointing result! Alejandro, please look in file systems/framework/context.h. Whenever I installed 2018.1.6 the line

class Context : public ContextBase

always showed ContextBase in red. Is yours actually right?

[sherm1]

Now I'm wondering if I did something wrong in importing my bazel project. The instructions say:

File > Import Bazel Project
Select Workspace: Use an existing Bazel workspace, and provide the path to your drake directory.
Select Project View: choose “Import project view file”, and select the file drake/.bazelproject
Project View: Pick a project data directory of your choice for the CLion project files. It must not be a subdirectory of drake.

I'm not sure what's meant by a "project data directory". There is a directories: line in the .bazelproject file, with two entries: "." and "-build". I did not make any change to that -- did you?

Also, I have CLion installed in /opt/clion-1018.1.6 which is not a writable directory (however that's where I have CLion 2017.3.4 installed also).

[sherm1]

Oh, rats. I found the "project data directory" -- it is the first field in the form and I had been ignoring it thinking it was just the project directory (because it defaults to that directory). That violates the above instruction! So I fixed it to point somewhere outside the drake repo. And ... no change :( still red.

Next thought: I have my Drake repo in directory ~/Documents/GitHub/sherm1/drake is that any different than how Alejandro's machine is organized?

[jwnimmer-tri]

Alejandro did not change the .bazelproject at all (it's VC'd by git, so we should not be touching it).

Alejandro had ~/Foo/drake as the checkout.

Alejandro and I both had CLion unpacked within ~/ somewhere, not /opt -- hopefully that doesn't matter. Maybe best is to schedule some screenshare time tomorrow and debug interactively.

[jwnimmer-tri]

Per slack -- the problem was that CLion wasn't using bazel_wrapper. It used to be not-so-bad to skip that step. It looks like now, things are very broken if you skip it. I'll update the docs to clarify.

[amcastro-tri]

@sherm1, Re the fact that ContextBase shows in red in context.h. Yes, I did see the same problem and Ctrl+B did not take me to the declaration. However, if you left click on ContextBase (this is sort of flaky you might need to try a couple times or just trust me on this) you'll see a contextual menu telling you that there actually are multiple options and you'd need to type Alt + Enter on the ContextBase class to select the appropriate one. When you do that you'll see a little contextual dialog showing you options (I believe three for me). BEFORE you click on the right path you might one to take a screenshot of the dialog since you might not be able to retrieve it again. Once you do that, Ctrl + B "seems" to work and you might even believe it for a few seconds....

... until you realize it actually took you to some wacky virtual directory. Aghh!!!

I don't know if this helps. Bottom line, @sherm1's problem is not solved in my installation of CLion and who knows what else is broken.

FTR, it works perfect in CLion 2017.2.3 with Bazel plugin 2017.11.20.0.4

[jwnimmer-tri]

@amcastro-tri Did you fix your setup to use bazel_wrapper yet?

[amcastro-tri]

nope, sry, going through my github emails in the order they arrive and I just saw your PR. I'll try next