Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make rebar3 work with dialyzer internally #1750

Merged
merged 1 commit into from
Apr 18, 2018

Conversation

ferd
Copy link
Collaborator

@ferd ferd commented Apr 14, 2018

We got funny interactions since PR #1656:

  • the last debug_info-related option seen in a list of options after
    profile merge is kept, allowing later profiles from overtaking earlier
    ones
  • if you go rebar3 as a,b,c compile, the options from profile A come
    before B, which come before C, so C's options win
  • overrides are applied in order of profile as well, giving a priority
    to a later profile than an earlier one
  • The values in overrides are prepended rather than suffixed to the
    existing list
  • this means if we have to overrides adding options, such as default
    adding no_debug_info', and dialyzeaddingdebug_info, the results are [debug_info]asdialyzeis applied first, and then[no_debug_info, debug_info]asdefault` overrides are applied
  • the final result is no_debug_info always winning when erl_opts are
    overriden specifically.

only debug_info options are going to suffer this, and in the context of
overrides. Other erl_opts should be fine. I'm not sure how that can be
fixed at all.

In the meanwhile, we can add support back while leaving the default to
not having debug information. This is done by:

  • moving all no_debug_info options to the prod profile
  • forcing prod to be called by ./bootstrap so that most people keep
    getting no debug info
  • anyone calling rebar3 clean -a and then rebuilding with rebar3 escriptize (i.e. rebar3 devs) get debug info going

This is up for review and discussion. Context at #1749

We got funny interactions since PR erlang#1656:

- the last `debug_info`-related option seen in a list of options after
  profile merge is kept, allowing later profiles from overtaking earlier
  ones
- if you go `rebar3 as a,b,c compile`, the options from profile A come
  before B, which come before C, so C's options win
- overrides are applied in order of profile as well, giving a priority
  to a later profile than an earlier one
- The values in overrides are prepended rather than suffixed to the
  existing list
- this means if we have to overrides adding options, such as `default`
  adding `no_debug_info', and `dialyze` adding `debug_info`, the
  results are `[debug_info]` as `dialyze` is applied first, and then
  `[no_debug_info, debug_info]` as `default` overrides are applied
- the final result is `no_debug_info` always winning when erl_opts are
  overriden specifically.

only `debug_info` options are going to suffer this, and in the context of
overrides. Other `erl_opts` should be fine. I'm not sure how that can be
fixed at all.

In the meanwhile, we can add support back while leaving the default to
not having debug information. This is done by:

- moving all `no_debug_info` options to the `prod` profile
- forcing `prod` to be called by `./bootstrap` so that most people keep
  getting no debug info
- anyone calling `rebar3 clean -a`  and then rebuilding with `rebar3
  escriptize` (i.e. rebar3 devs) get debug info going

This is up for review and discussion.
@ferd ferd merged commit c48435a into erlang:master Apr 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants