The current manual states that:
"YCM looks for a file named 'compile_commands.json' in the directory of the
opened file or in any directory above it in the hierarchy (recursively); when
the file is found, it is loaded."
I think it would be nice to be able to configure the location of the compilation database. I like to keep all my "personal" files in a hidden subdirectory of a project. Chromatica (https://github.com/arakashic/chromatica.nvim) does support this:
let g:chromatica#dotclangfile_search_path='.vim_project/compile_commands.json
What do you think?
Regards,
Robert
What do you think?
That the compile_commands.json is a per-project thing so I'm not sure that a global configuration is going to solve this problem.
It is not global. The mentioned search path is relative to the current file. So instead of traversing the directory tree until a file called "compile_commands.json" is found, Ycm could traverse until a fille called "ycm_compile_database_file" is found. In my example this is ".vim_project/compile_commands.json"
any g: is a global config, so either you have the same convention for every project you work in or you need to adjust this per-project. I'm not saying I'm against it, one might use tpope/vim-projectionist and set a variable accordingly, but still you would be limited.
Ah, now I got what you mean. But right now there is already a global configuration:
We have to have a file called "compile_commands.json" in the project dir. It just not configurable right now, but it is global.
We have to have a file called "compile_commands.json"
That is actually not true. What we require is the flags to compile your code and if you need more flexibility thre is always the .ycm_extra_conf.py. Since a lot or projects uses CMake or tools that generate this compile_commands.json file we added support to automaticly use it but you're not require to use it directly. Potentially you could write a .ycm_extra_conf.py file which all it does is to search the compile_commands.json file and use it.
True that always works. However, I think it is overkill to create an .ycm_extra_conf.py just to change the name/location of the compile_commands.json, but that's just my 2 cents...
I'm not saying that there is no problem, for example for out of source builds the system that we currently have does not work our of the box, but before start thinking on possible solutions and start working on one, that we have then to maintain forever (in this project we try to always be backward compatible) I would like to see that is really a pain for our users
What you are asking can be done with the g:ycm_extra_conf_vim_data option. You can pass Vim variables to YCM extra conf files with this option. So, for instance, you could set the variable g:ycm_compilation_database_folder to a relative path, retrieve the value of this variable in the global extra conf, and find the compilation database according to this value. Here's a global extra conf that implements this approach. Put this file in your home directory (or anywhere else) and add these options to your vimrc:
let g:ycm_compilation_database_folder = '.vim_project'
let g:ycm_global_ycm_extra_conf = '~/global_extra_conf.py'
let g:ycm_extra_conf_vim_data = [ 'g:ycm_compilation_database_folder' ]
We really don't want to make things configurable, particularly not when using a compilation database. The idea with the compilation database is that we want heuristics that work for 90%+ of compile db users, and the remaining 10% can use .ycm_extra_conf.py and either provide flags or load the database themselves.
Granted, we don't put anything in the readme about loading the database yourself, but YCM's own .ycm_extra_conf.py file includes comments and an example implementation.
That's not to say that our existing heuristics hit the desired sort of 90% mark; we don't know that for certain. We know nonzero users have said "yeah, but my compile_commands.json isn't in the place you want it to be", and our response is usually "you could use a symlink, or write your own .ycm_extra_conf.py". But until there is a critical mass of people with a particular setup, we're not likely to implement new heuristics. Certainly, we don't want to add any configuration items for this: we're aiming for "it just works" even if that's more effort on our part.
My use case is: we have a large tree that we can build with several different options. So, our file structure is:
.
โโโ source
โย ย โโโ foo
โย ย โโโ bar
โโโ build-with-vanilla
โโโ build-with-vanilla-and-sprinkles
โโโ build-with-strawberries
All the build-* folders contain a compile_commands.json file generated by cmake. Which one of them should I symlink to 'source'? Somehow it seems... odd.
Should I start vim from a particular build-* folder and pass in absolute file names? Or is it possible for youcompleteme to read all compilation databases from peer folders of current one and 'merge' the suggestions?
YCM will not merge. You should write a ycm_extra_conf.py that works for you.
@0x8000-0000 When I had a project that could have been built in a number of ways I just put all the flags in .ycm_extra_conf.py even though I was never passing everything to the compiler at the same time.
Clangd supports --compile-commands-dir=, for those who need it, check :h g:ycm_clangd_args.
Most helpful comment
My use case is: we have a large tree that we can build with several different options. So, our file structure is:
All the build-* folders contain a compile_commands.json file generated by cmake. Which one of them should I symlink to 'source'? Somehow it seems... odd.
Should I start vim from a particular build-* folder and pass in absolute file names? Or is it possible for youcompleteme to read all compilation databases from peer folders of current one and 'merge' the suggestions?