BTW offers a simplified way to build and execute programs from vim. In essence, this plugin encapsulates :make
and :!./%<
.
Several options can permit to tune the behaviour of BTW.
Command | Default keybinding | Variable to set in .vimrc |
---|---|---|
:Make |
<F7> |
g:BTW.key.make |
:StopBGCompilation 1 |
N/A (yet) | N/A (yet) |
:Execute |
<C-F5> |
g:BTW.key.execute |
:Config |
<M-F7> |
g:BTW.key.config |
:ReConfig |
<M-F8> |
g:BTW.key.re_config |
- 1 Requires Vim 7.4-1980 compiled with +job feature.
Role | Option name | Values (default) | Best set in/changed with |
---|---|---|---|
Shall the compilation happen in background? 1 | g:BTW.make_in_background |
1/(0) | .vimrc /:ToggleMakeBG |
Shall the background compilation autoscroll the qf-window to display last message?2 | g:BTW.autoscroll_background_compilation |
1/(0) | .vimrc /:ToggleAutoScrollBG |
Shall the compilation use all available cores? | g:BTW.make_multijobs |
n/(0) | .vimrc /:ToggleMakeMJ |
Directory where the compilation shall be done | (bpg):BTW.compilation_dir |
path ('') | local_vimrc / BTW CMake submodule |
Shall we update BTW tools chain every time we compile? | (bpg):BTW.use_prio |
'' /('update' ) |
local_vimrc |
Command to use to compile in background (useful to follow the compilation in an external xterm) | (bpg):BTW.make_in_background_in |
('' )/'xterm -e' /... |
local_vimrc |
Name of the project | (bpg):BTW.project |
('%<' ) |
local_vimrc |
Build Target | (bpg):BTW.target |
(project name, or 'all' if empty) |
local_vimrc |
-
1 Requires perl or Vim 7.4-1980 compiled with +job feature. The old perl way works on *nix systems. The new +job way has been tested successfully on:
Linux Cygwin + gvim643 Cygwin + cyg-vim Mingw + gvim645 VC10 + gvim 645 Mono-file project ✔️ ✔️ ❓ ❓ ✔️ 4 Out-of-source build ✔️ ❓ ❓ ❓ ❓ -
2 Requires Vim 7.4-1980 compiled with +job feature.
-
3 My
&shell
options are configured through my very old system-tool plugin. More investigations are required for other configurations. -
4 Tested with gvim64 launched from VS2015 CLI for native x64 console, and
:BTW set cl
, and:Make %
. -
5 Without any Cygwin binaries in the $PATH.
The option (bpg):BTW.project_config
says what to do on :Config
.
When (bpg):BTW.project_config.type
equals
modeline
, add a let-modelinemakefile
, open the make file named(bpg):BTW.project_config.file
in(bpg):BTW.project_config.wd
.ccmake
, starts ccmake in(bpg):BTW.project_config.wd
, with(bpg):BTW.project_config.args
as parameters.
Role | Option name | Values (default) | Best set in |
---|---|---|---|
Tunes where the quickfix window shall be opened | g:BTW.qf_position |
('' )/'botright' /... |
.vimrc |
Tunes the size of the quickfix window | g:BTW.qf_size |
number of lines (max(15, &winfixheight)) | .vimrc |
Tells whether we shall jump to the first error | g:BTW.goto_error |
(1)/0 | .vimrc |
Role | Option name | Values (default) | Best set in |
---|---|---|---|
Parameters to pass to the program executed with :Execute |
(bpg):BTW.run_parameters |
string (empty) | local_vimrc |
Program to execute | (bpg):BTW.executable |
(project name, or does nothing if empty) | local_vimrc |
Projects are compiled on <F7>
or :Make
, in the directory specified by (bpg):BTW.compilation_dir
. The compilation may be done in background (on nix boxes only), it may use all cores available.
The compilation tries to detect automatically the target though (bpg):BTW.project...
options, though it may be forced as a parameter to :Make
.
When an error is found, the quickfix window will get automatically opened. However, when the quickfix window is not opened (link errors are not detected by default as compilation errors), the command :Copen
is provided. :Copen
differs from :copen
in the sense it adjust its size the number of lines to display.
First, a quick reminder. When, our system has gnu make installed (and not the badly configured gnumake from Mingw), we can compile the standalone file foo.c
with make foo
from our shell. We don't need to (and must not) write any Makefile! The executable foo
will be generated in the current directory.
Any need to inject an option ? $CFLAGS
, $CXXFLAGS
, $CPPFLAGS
, $LDFLAGS
(to name the main ones) are already there waiting to be set. For instance, we can compile the C++14 standalone file bar.cpp with CXXFLAGS='-std=c++1y' make bar
. And execute the result with ./bar
.
How is it related to vim, you'll ask? Well, this means we can compile foo.c from vim with :make foo
, or even :make %<
when the current buffer is foo.c. To compile bar.cpp, we'll first have to set $CXXFLAGS
with :let $CXXFLAGS='-std=c++1y'
, and then we can simply compile with :make %<
. Et voilà!
The way BTW handles its default settings, we just need to hit <F7>
to compile the current buffer. And if we need to set options, just set $CXXFLAGS
once, and hit <F7>
or :Make
(note the capital 'M')
NB: my plugin let-modeline may help here.
Of course, this will only work as long as there is no Makefile in the same directory of the file we wish to compile. If there is a Makefile, I strongly suggest you to better organize the directory where your pet projects/tests are. I usually have projects made of single files in a same directory, but when a project (even a small one) is made of several files, I store its files apart.
Note, that this will work only if there are implicit rules known by gnumake to handle the file you wish to compile. For other organizations, filetypes without implicit rules know by gnumake, or scripts to be interpreted, you can play with filters, or use other plugins like SingleCompile.
This time BTW won't be able to use the name of the current buffer to determine the target to use with make
. Define a Makefile, and set the option (bpg):BTW.target
to whatever you wish ('all', 'myprog', or 'whatever').
The best way to define this option is from a project oriented plugin like local_vimrc
I have a lot of things to say on this topic.
Just hit <C-F5>
to execute the current program. You may have to change the key bound if you are using vim in console instead of gvim or macvim.
In the case of the multi-files project, or a project having tests managed through CTest, you'll have to set (bpg):BTW.executable
.
If (bpg):BTW.executable
contains { 'type': 'make' }
, the execution is redirected to the quickfix window. Same thing with { 'type': 'ctest' }
, but this time the result is filtered on-the-fly to correct the noise introduced by CTest (regarding &errorformat
)
You'll see in this little demo, an example of use of BTW on two CMake based projects simultaneously opened in Vim 8 (7.4-2342 actually).
The compilation of both projects is launched in background. The job queue (from lh-vim-lib) is then opened to follow what is done in background and what will be done shortly after.
The explicit update (in background) of tags for all files in ITK project is also requested (thanks to lh-tags v2.0.3).
And we see ITK compilation fails because cmake
has never been run for the
reldeb compilation mode (ReleaseWithDebugInfo). A problem is detected and the
next jobs are not executed automatically. The job queue is paused (I also could
have ignored the error, etc.).
Then I change the current compilation mode to sanitize (some kind of
ReleaseWithDebugInfo mode but compiled with clang++ with two sanitizations
activated). This time cmake
has been executed in the associated directory. I
register the compilation on ITK in this mode.
The queue is still paused. I unpause the job queue through the :Jobs
console.
Eventually I see ITK is still not compiling, but this is another issue.