Open c-bik opened 6 years ago
Right now you only get this information if you enable debug output with DEBUG=1
; it was initially judged too noisy (especially on large apps) and was consciously removed from the regular output. I'm not sure we want to re-enable it.
For what it's worth, even without an auto-compile and load plugin, you can use r3:compile()
from within rebar3 shell
in order to compile and re-load modules directly.
👍 @ferd for work around. I feel the same way about the default 'noise' (was hesitating because of that to raise this).
However, last time I tried rebar3 shell
I had issues with clustering (something related to epmd needs to be manually started before first node etc), I haven't checked recently how that works with latest version of rebar3
now. If that epmd bit is no longer an issue then IMHO rebar3 shell
is the way-to-go!
Alternatively, can DEBUG=X
(numbers highter that 1
) be a good idea for this (or other similar optional debug features)? -- without the heavy DEBUG=1
baggage, full compiler command and env dump (for ports e.g.) which is perhaps also unnecessary to just know which files got compiled!
I guess I'm trying to propose, in general, more DEBUG
granularity.
The distribution layer for rebar3 now attempts to boot its own EPMD if it isn't there: https://github.com/erlang/rebar3/blob/416176290b20e1e68c5901f83cccef71ec2bc322/src/rebar_dist_utils.erl#L66-L70 So that should at least take care of the problem.
And yeah, lack of debug granularity is certainly a problem. I don't think that there's a quick easy fix (since we only support 3 levels). It would probably be faster to write a verbose switch than refactor all of the tool to add that granularity.
@ferd is there a way to tell rebar3 shell
to use werl.exe
(instead of erl.exe
) for/if windows? I have got nothing against erl.exe
except the annoance of not having TAB (or working correctly) to autocomplete erlang (specially module exported function list) in some shells (GitBash for one).
I like the verbose switch idea 👍
rebar3 -v compile
or rebar3 --verbose compile
can even be rebar3 -vvv compile
etc. Looks more intuitive than DEBUG=1,2,3
(and of course it can be any command and not just compile
).
Is there a plan to work on this?
I would like to have output like mix does in recent versions. It prints how many modules were compiled.
Though I'd leave out the "generated ... app", but having the number of compiled modules could be nice and actually useful while still being minimal.
Mix output:
λ mix compile
==> connection
Compiling 1 file (.ex)
Generated connection app
==> decimal
Compiling 1 file (.ex)
Generated decimal app
==> db_connection
Compiling 23 files (.ex)
Generated db_connection app
==> postgrex
Compiling 62 files (.ex)
warning: Enum.partition/2 is deprecated. Use Enum.split_with/2 instead
lib/postgrex/error_code.ex:14
Generated postgrex app
Since we wouldn't want the "Generated" line maybe we could even make the whole thing one line:
λ rebar3 compile
==> connection (compiling 1 module)
@c-bik You can run rebar3 (and any other escript) with werl by specifying the ESCRIPT_EMULATOR
environment variable. In a Git bash that would be
ESCRIPT_EMULATOR=werl ./rebar3 shell
In cmd.exe
it's
set ESCRIPT_EMULATOR=werl
escript rebar3 shell
What'll be the goal of the implementation here?
rebar.config
to allow listing compiled modules (verbose)?I'd like to see a count.
Pre-Check
If there isn't already way to do this (please point me to how), then this is a feature request.
Environment
N/A
Current behaviour
Assuming default is incremental compile, currently apart from
===> Compiling myapp
,rebar3 compile
doesn't say which files it compiled.Expected behaviour
Rather, good to have:
This helps rebar3 users to manually load the new compiled modules among others who aren't using Auto Compile and Load plugin.