Add ability to detect .color_coded options from CMakeLists.txt about color_coded HOT 12 CLOSED

I'm not sure what this issue represents; color_coded doesn't use CMake.

from color_coded.

Sorry I wasn't clear - I don't want to write a .color_coded file. Instead, I was suggesting that color_coded could interop with popular build systems like CMake to detect your compiler options.

from color_coded.

Bonus - a decent configuration can be generated on the fly simply by doing find . -name "*.h" and putting a -I before each result.

from color_coded.

On Thu, Apr 02, 2015 at 09:00:11AM -0700, Drew DeVault wrote:

Bonus - a decent configuration can be generated on the fly simply by doing
find . -name "*.h" and putting a -I before each result.

Not gonna happen. Globbing and compilation do not mix.

from color_coded.

Not gonna happen. Globbing and compilation do not mix.

It works in most circumstances, though. I just went to a handful of my C projects and effectively did this and got pretty good syntax highlighting out of it. It's okay to provide defaults that work for most people and then give people the chance to tweak if neccessary. color_coded isn't a compiler, even if it leverages one. It's 100% okay for it to make a mistake, it's not even slightly mission critical.

Regardless, the CMakeLists.txt parsing should give you exactly what the compiler is using, and shouldn't be a problem to implement.

from color_coded.

Sorry I wasn't clear - I don't want to write a .color_coded file. Instead, I was suggesting that color_coded could interop with popular build systems like CMake to detect your compiler options.

This is something we can consider. There was also consideration for parsing YCM's config file, but that would involve an embedded Python interpreter, which is just unrealistic. In a similar vein CMakeLists.txt files can be difficult to parse in some cases, since the adding of options can be based on conditional logic, inclusion of other files, calling of child processes, etc.

from color_coded.

It's okay to provide defaults that work for most people and then give people the chance to tweak if neccessary.

color_coded does try to provide sane defaults, as outlined in the README. The specific flags used are an implementation detail and subject to change, but can be found here: https://github.com/jeaye/color_coded/blob/master/include/conf/defaults.hpp

from color_coded.

In a similar vein CMakeLists.txt files can be difficult to parse in some cases,

cmake -LA -N

If you need a repo to try it out on, here's one.

color_coded does try to provide sane defaults, as outlined in the README. The specific flags used are an implementation detail and subject to change, but can be found here: https://github.com/jeaye/color_coded/blob/master/include/conf/defaults.hpp

Sure. Those defaults can be improved by guessing project-specific include paths.

from color_coded.

Perhaps an easier route here would be to support clang's compilation databases? YCM supports this, and it's more general than parsing the CMakeLists.txt. CMake can be configured to generate it, and it can be generated by other tools as well. (One caveat that I'm aware of is that it doesn't generate compiler flags for header files.)

https://github.com/Valloric/YouCompleteMe/blob/master/README.md#c-family-semantic-completion-engine-usage

from color_coded.

A better option is to just add support for generating .color_coded to YCM-Generator. It already collects clang-compatible compilation flags from makefile, autotool, and cmake -based projects, so 99% of the work is already done.

from color_coded.

@rdnetto Not a bad idea, thanks for suggesting. This is certainly low-priority for me right now, given all of the other items.

from color_coded.

Closing this, since YCM-generator is proven to work.

from color_coded.