Providers Setting Profile Configs about rebar3 HOT 5 CLOSED

I'd expect update_profile to crush the config entirely for erl_opts. I'm guessing a general get/set mechanism could be okay.

from rebar3.

The current way profiles work are that key's that have list values have those lists merged. So this is in keeping with how profile merging works.

from rebar3.

i don't think i really understand the life cycle of a command. the problem with the eunit handler in particular is that it's got a declared dependency on compile which means compile runs before eunit and the TEST macro is never defined for source files in src. that means no inline tests are run

i think the intention is that running eunit under the test profile would cause it's dependencies (compile) to also run under the test profile but that still means you need an {eunit_compile_opts, [...]} or {erlopts, [...]} tuple declared somewhere in the config right? there's no way to have the eunit provider modify it's dependency's state, right?

from rebar3.

@talentdeficit the life cycle is:

• Rebar3 starts
• Config file is read in to the state
• rebar_state:create_logic_providers/2 runs the init/1 of every available provider
• The command is parsed out from the cli arguments
• in rebar_core providers:get_target_providers is called to get the order of providers to run for the command
• The profile for the command (test in the cause of common_test, and eunit should as well) is applied to the config with rebar_state:apply_profiles
• do/1 is called for each provider in that list in order

So if you modify the test profile to include the macro in erl_opts in eunit provider's init/1 it'll be used when the compile provider is run.

from rebar3.

I don't remember what this is about and I opened it, I think I'll close it...

from rebar3.