[Vim/YCM] Calculate system library paths based on Clang++ binary path.

[Vim/YCM] Calculate system library paths based on Clang++ binary path.

The YouCompleteMe configuration still needs to determine the list of
system include paths. The current chromium.ycm_extra_conf.py logic
requires that the host machine has a 'clang' binary in its PATH that can
yield this information.

This change calculates the system include paths based on the clang++
binary used to compile the target file. It allows the use of wrappers
(E.g. goma), by looking for a clang++ command in the first and second
tokens in the compile command. It's still not perfect since the Clang
library used by ycmd might be different, but it should work better than
the current logic.

BUG=none
NOTRY=true

Committed: https://crrev.com/01c39d08735ba762e1788d3ce4922d46f25c4028
Cr-Commit-Position: refs/heads/master@{#330409}

[asanka, 2015-05-18 17:40:47]

asanka@chromium.org changed reviewers:
+ eroman@chromium.org

[eroman, 2015-05-18 17:56:42]

https://codereview.chromium.org/1137303005/diff/20001/tools/vim/chromium.ycm_...
File tools/vim/chromium.ycm_extra_conf.py (right):

https://codereview.chromium.org/1137303005/diff/20001/tools/vim/chromium.ycm_...
tools/vim/chromium.ycm_extra_conf.py:213: clang_path = clang_line.split(' ')[0]
This is too simplistic, the "path" may contain spaces.

For instance when using goma, my line starts with:

/usr/local/google/home/ericroman/goma/gomacc
../../third_party/llvm-build/Release+Asserts/bin/clang++

So there is at the very least going to be a space before clang++

How about instead taking clang path as everything from the start of the line up
until (and including) "clang++" ?

[asanka, 2015-05-18 19:36:48]

https://codereview.chromium.org/1137303005/diff/20001/tools/vim/chromium.ycm_...
File tools/vim/chromium.ycm_extra_conf.py (right):

https://codereview.chromium.org/1137303005/diff/20001/tools/vim/chromium.ycm_...
tools/vim/chromium.ycm_extra_conf.py:213: clang_path = clang_line.split(' ')[0]
On 2015/05/18 at 17:56:42, eroman (sick slow) wrote:
> This is too simplistic, the "path" may contain spaces.
> 
> For instance when using goma, my line starts with:
> 
> /usr/local/google/home/ericroman/goma/gomacc
../../third_party/llvm-build/Release+Asserts/bin/clang++
> 
> So there is at the very least going to be a space before clang++
> 
> How about instead taking clang path as everything from the start of the line
up until (and including) "clang++" ?

That's also a no-go due to the gomacc wrapper not liking the stdin source used
by SystemIncludeDirectoryFlags. I've updated the code to use shlex (so as not to
be confused by embedded whitespace), and looking at the first two tokens for a
Clang like command.

Let me know if we should be more general than this.

[eroman, 2015-05-18 20:21:13]

LGTM. I suggest also describing the wrapper allowance in the CL description
(might be helpful if not too specific, to call out goma)

[asanka, 2015-05-18 20:37:15]

On 2015/05/18 at 20:21:13, eroman wrote:
> LGTM. I suggest also describing the wrapper allowance in the CL description
(might be helpful if not too specific, to call out goma)

Done. Thanks!

[asanka, 2015-05-18 20:37:56]

The CQ bit was checked by asanka@chromium.org

[commit-bot: I haz the power, 2015-05-18 20:41:10]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1137303005/40001

[commit-bot: I haz the power, 2015-05-18 20:47:19]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-05-18 22:42:43]

Patchset 3 (id:??) landed as
https://crrev.com/01c39d08735ba762e1788d3ce4922d46f25c4028
Cr-Commit-Position: refs/heads/master@{#330409}

[eroman, 2015-05-30 00:30:18]

This is causing some problems for me (not able to find <stddef.h> for instance).

With this patch I am getting only:

'-isystem', '/usr/lib/youcompleteme/third_party/ycmd/ycmd/../clang_includes'

Whereas before I was getting all of these:

'-isystem', '/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8',
'-isystem',
'/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8',
'-isystem',
'/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/backward',
'-isystem', '/usr/local/include',
'-isystem',
'/work/src/chromegit/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.7.0/include',
'-isystem', '/usr/include/x86_64-linux-gnu',
'-isystem', '/usr/include',
'-isystem', '/usr/lib/youcompleteme/third_party/ycmd/ycmd/../clang_includes'

I haven't dug into where the problem lies exactly, however a brief investigation
reveals that "/usr/lib/youcompleteme/third_party/ycmd/ycmd/../clang_includes" is
not actually a path for me, so I am guessing that is the problem. Interestingly
this is the internally packaged YCM (by YCM author no less), so not sure what is
up with that....

[asanka, 2015-05-30 03:31:57]

On 2015/05/30 at 00:30:18, eroman wrote:
> This is causing some problems for me (not able to find <stddef.h> for
instance).
> 
> With this patch I am getting only:
> 
> '-isystem', '/usr/lib/youcompleteme/third_party/ycmd/ycmd/../clang_includes'
> 
> Whereas before I was getting all of these:
> 
> '-isystem', '/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8',
> '-isystem',
'/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8',
> '-isystem',
'/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/backward',
> '-isystem', '/usr/local/include',
> '-isystem',
'/work/src/chromegit/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.7.0/include',
> '-isystem', '/usr/include/x86_64-linux-gnu',
> '-isystem', '/usr/include',
> '-isystem', '/usr/lib/youcompleteme/third_party/ycmd/ycmd/../clang_includes'
> 
> I haven't dug into where the problem lies exactly, however a brief
investigation reveals that
"/usr/lib/youcompleteme/third_party/ycmd/ycmd/../clang_includes" is not actually
a path for me, so I am guessing that is the problem. Interestingly this is the
internally packaged YCM (by YCM author no less), so not sure what is up with
that....

Is this for a file that ninja doesn't know about? Perhaps we can try 'clang++'
as a fallback option in case ninja doesn't give us a commandline.