Move to a more flexible and portable build system

[jeaye]

They all suck, looks like I'll be putting in CMake.

[jeaye]

@oblitum Are you available to test the cmake branch? It has updated install instructions. Ideally, we test in fresh directories (not existing color_coded installation) and on Linux and OS X. I've given it a go on OS X and Arch Linux and I'll do Ubuntu tomorrow. If you can, let me know how it goes and what you were able to test.

[oblitum]

@jeaye only when I get back home late.

[jeaye]

No problem. At your convenience!

[jeaye]

@tony I'll change the shebang to be more portable. I know you've been through hell with color_coded and I really appreciate the help getting things going on your machine.

Now try to open up some code and see if things are working!

[jeaye]

The shebang has been updated on cmake and master.

[tony]

It looks like make completes, but it gives color_coded unavailable: you need to compile it (see README.md).

tony at x in ~/.vim/bundle/color_coded (cmake●●) 
$ ls -al
total 50318
drwxr-xr-x   14 tony  tony        28 Apr  9 23:29 .
drwxr-xr-x  105 tony  tony       106 Apr  9 23:23 ..
-rw-r--r--    1 tony  tony        21 Apr  9 23:24 .color_coded
drwxr-xr-x    8 tony  tony        15 Apr  9 23:29 .git
-rw-r--r--    1 tony  tony       166 Apr  9 23:24 .gitignore
-rw-r--r--    1 tony  tony         0 Apr  9 23:24 .gitmodules
-rw-r--r--    1 tony  tony      3009 Apr  9 23:24 .ycm_extra_conf.py
-rw-r--r--    1 tony  tony      3363 Apr  9 23:24 .ycm_extra_conf.pyc
-rw-r--r--    1 tony  tony     27900 Apr  9 23:27 CMakeCache.txt
drwxr-xr-x    7 tony  tony        18 Apr  9 23:29 CMakeFiles
-rw-r--r--    1 tony  tony      1908 Apr  9 23:27 CMakeLists.txt
-rw-r--r--    1 tony  tony      1090 Apr  9 23:24 LICENSE
-rw-r--r--    1 tony  tony     18535 Apr  9 23:27 Makefile
-rw-r--r--    1 tony  tony     10428 Apr  9 23:24 README.md
drwxr-xr-x    3 tony  tony         3 Apr  9 23:24 after
drwxr-xr-x    2 tony  tony         3 Apr  9 23:23 autoload
drwxr-xr-x    7 tony  tony         7 Apr  9 23:24 clang+llvm-3.6.0-amd64-unknown-freebsd10
-rw-r--r--    1 tony  tony  41111272 Apr  9 23:24 clang+llvm-3.6.0-amd64-unknown-freebsd10.tar.xz
drwxr-xr-x    3 tony  tony         7 Apr  9 23:23 cmake
-rw-r--r--    1 tony  tony      2199 Apr  9 23:27 cmake_install.cmake
-rwxr-xr-x    1 tony  tony  19125189 Apr  9 23:29 color_coded.so
drwxr-xr-x    2 tony  tony         3 Apr  9 23:24 colors
drwxr-xr-x    9 tony  tony        11 Apr  9 23:24 include
drwxr-xr-x    3 tony  tony         5 Apr  9 23:24 lib
-rw-r--r--    1 tony  tony    186684 Apr  9 23:29 libcolor_coded_boost.a
drwxr-xr-x    2 tony  tony         3 Apr  9 23:23 plugin
drwxr-xr-x    2 tony  tony         3 Apr  9 23:23 src
drwxr-xr-x    2 tony  tony         4 Apr  9 23:24 test

I don't see a build directory.

Anything you need for me to look for? I have to rebuild vim with +profile support to get more info.

[jeaye]

Ok, the best thing to do here is to jump into the bin directory (with color_coded.so) and run:

lua -l color_coded

It should drop you into a lua prompt with no errors. If there are errors, please paste them here.

[jeaye]

The build directory is optional, but it's generally where you should be building. Instead of in-source builds, which clutter the project directory with build files, it's common to go into a separate build directory and cmake from there. That's why the README suggests

mkdir build ; cd build
cmake ..
make && make install

Note, this doesn't matter; color_coded should work either way.

[jeaye]

@tony Also, in case you weren't following the README, make sure that you have said make install. :)

[tony]

tony at x in ~/.vim/bundle/color_coded (cmake●●) 
$ lua52 -l color_coded
Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
> 

I'm updating to the latest cmake branch, clearing things out, and doing it with the build directory.

Also, in case you weren't following the README, make sure that you have said make install. :)

And that could be it. Checking it out

[tony]

FreeBSD Current. Looks like we're up and running.

[jeaye]

You're the man. Now, you'll need to tweak your colorscheme to use the new highlighting groups, as the README suggests. You can also try out color_coded's builtin colorscheme:

:color twighlighted

If you don't update your colorscheme (or use twighlighted), you won't be taking full advantage of all the different color groups.

[tony]

Here is it without the plugin:

I am using base16-monokai. FYI.

I will follow up with twighlighted for both.

[jeaye]

Also, since it looks like you're writing C (instead of C++), you should consider adding a .color_coded file to your project root which specifies that C should be used. See https://github.com/jeaye/color_coded#using-for-c

[tony]

Can their be a vim settings to pass in flags by filetype? Could you add -x c by default for c filetype? Can you make it so a user can script it via autocmd?

[tony]

@jeaye I tried loading a file in the v8 project and got an error. (https://github.com/v8/v8/blob/master/src/accessors.cc).

I have to recompile vim to give you more info on that. Stand by.

[tony]

Having a hold up with compiling vim on BSD. Here is what I have so far:

[neobundle] Uncaught error while sourcing "color_coded": Vim(execute):E121: Undefined variable: b:current_syntax in function color_coded#enter, line 7

[tony]

This happens when loading a .cc file.

[jeaye]

Can their be a vim settings to pass in flags by filetype?

That's not currently possible, but it's something that's very reasonable. The only issue I foresee is trying to decide whether or not the flags in .color_coded end up being applied to all file types, or just some. This might require the .color_coded file to be more complex, having groupings or flags based on file types. I can make an issue about this as a task. For now, you need to set it project-wide.

[jeaye]

@tony b:current_syntax is an internal vim variable. The docs are here: http://vimdoc.sourceforge.net/htmldoc/syntax.html (can't link you directly, but searching for b:current_syntax shows the first result properly on the page).

It could be that your colorscheme or vimrc is undefining it. If that's the case, I'm not sure right now what I can do, since color_coded needs to know they syntax type of a buffer.

[tony]

@jeaye : Looking into it.

Here is the profile.log and vim version here from the error: https://gist.github.com/tony/a23eb36f188102120df6

It's not convenient to have to put a .color_coded in every C project. In my case it'd be /usr/src in freebsd and various open source projects I study in ~/study/c. YCM has a project config for the users $HOME directory as a fallback if there isn't a config in the project.

[jeaye]

It's not convenient to have to put a .color_coded in every C project.

You don't need to do that. You should really read the README. :P color_coded will search up to / from the current directory and use whichever .color_coded it finds first. This means you can have one in ~ or somewhere above your projects and you can also customize per-project.

[jeaye]

I'm closing this issue, since cmake has been merged into master. @tony Feel free to still comment here on your b:current_syntax issue.

[tony]

@jeaye Let's make it into it's own issue.

[oblitum]

@jeaye I've figured out my cmake build problem in a previous comment is because of this:

https://llvm.org/bugs/show_bug.cgi?id=22951

[jeaye]

On Mon, Apr 13, 2015 at 07:28:25PM -0700, Francisco Lopes wrote:

[1]@jeaye I've figured out my cmake build problem [2]at a previous comment
is because of this:

[3]https://llvm.org/bugs/show_bug.cgi?id=22951

Hm, this doesn't say that -std=c++1y has the same issue. Does it?

[oblitum]

yeah it doesn't specify that. I'm still checking whether it got fixed at the libc++ repo, or the clang one. Because AFAIK, I don't have a custom libc++ on OS X, so this should be reproducing with the system one that may have got updated or something. Still checking why I get this...

[oblitum]

It's in my current clang trunk revision... it's fixed in clang.

[jeaye]

On Mon, Apr 13, 2015 at 07:47:33PM -0700, Francisco Lopes wrote:

It's in my current clang trunk revision... it's fixed in clang.

Hehe. So this isn't an issue anyone else is likely to have then.

[oblitum]

yep.