exercises rebar/gpb integration
The bulk of these tests are written by Luis Rascão, hence he is the
author of this commit. As the committer, I have cherry-picked his two
commits 4c87bcd and ebb8182, from the feature/support_gpb_protobuf
branch in the git://github.com/lrascao/rebar repo, and have slightly
adapted it to fit this pluggable-proto-compilers-gpb branch.
Update the THANKS file
This adds the config option {proto_compiler,gpb} for selecting gpb
as the compiler for protocol buffer files. When gpb is used as
compiler, it reads the gpb_opts config item for options.
Make it possible for plug in alternative protocol buffer compilers.
The compilers are picked up based on if they export all of the
functions key/0, proto_compile/3, proto_clean/3 and proto_info/2.
The set of compiler modules to choose from, is fetched from the rebar
application environment, from the app_dir modules.
A new config option, {proto_compiler,Compiler}, specifies which of
the available protocol buffer compilers to use. The 'protobuffs'
compiler is now one such compiler (the only one), and it is also the
default, for backwards compatibility.
When the option {cover_print_enabled, true} is set and that the code
coverage is 100%, the '%' will end up being truncated.
This patch makes it so that the truncation happens at 4 a characters
width so that instead of the following printouts:
some_mod : 99%
some_other: 100
We instead show:
some_mod : 99%
some_other: 100%
This solves issue #331 as reported by @lispking and @NineFX.
This patch adds a typer target to the Makefile. It makes it
easier for developers to start adding specs to the codebase. It
also as a build_plt target with the built-in applications typer
needs to analyze rebar.
This also includes the Erlang version in the generated PLT file.
typer and dialyzer targets use this file. Finally, the distclean
target removed the versioned PLT file.
Using code:set_path/1 with very large paths is very slow on larger
projects. On my mid-sized project, it seems to take around .4s per
call. Emulating the call with direct path removal (using
code:del_path/1) seems to be quite a lot faster.
If you happen to fetch a zip archive of the git repo and try to build
from that, you may, for example, ask erlc to build src/._rebar.erl.
._* are OS X resource forks and not real .erl files. This may also
happen with network filesystems on OS X. To fix that, limit the
files compiled by rebar to include only those which start with
a letter or a digit.
