Optional(?) New Output Directory Structure about rebar3 HOT 12 CLOSED

+1 to _build

also could you have arbitrary subdirs like windows, freebsd etc or are you going to just restrict it to prod and dev?

from rebar3.

I wasn't planning to restrict it. Would subdirs like windows make sense for rebar3? Not that I'm saying you won't be able to name them that, but seems like something a user would do before releases in relx not building BEAM files.

I also plan to do this change of build profiles for relx.

from rebar3.

you might want to make different api calls (via os:cmd or whatever) on different platforms. it would be nice to be able to handle this with rebar profiles rather than platform defines. i can think of a few other reasons to want arbitrary profiles too, windows was just the first that came to mind

from rebar3.

Ah, yea, good point. Now for how these should be configured.

{profiles, [{dev, [
                         {erl_opts,
                           [debug_info,
                            warnings_as_errors]}
                         ]}           
               ]
}.

Just something like that and then if a profile is set it merges the contents of the list from the profile with the rest of the config values. And the output dir I guess would just be atom_to_list(Profile).

from rebar3.

that looks great, although you need pretty clear merging rules. maybe lists are appended and everything else is replaced?

from rebar3.

Yup, that is what I was thinking.

@ferd ?

from rebar3.

What would the default profile be?

from rebar3.

@ferd I suppose either default or dev.

One issue I realized is, maybe we should do this structure instead:

_build
├── lib
├── dev
│   └── releases
├── plugins
│   └── lib
├── prod
│   └── releases
└── test
    └── lib

Where we could also replace the name lib with deps. But we should probably share the project deps like this. And then each profile can have their own deps declared that are installed into their subdirectory, like test deps and plugins.

from rebar3.

I agree lib makes more sense at the top-level there. Worst case will be the compile options that may change cross profiles.

The downside of this remains booting a shell with it.

erl -pa ebin -env ERL_LIBS _build/lib:_build/test/lib

Or the more expected

erl -pa ebin _build/lib/*/ebin _build/test/lib/*/ebin

Because most people don't use the rest.

Of course we could focus more work on rebar3 shell <profile> and build these on users' behalf. Of course that would also add in needs for dialyzer ... <profile> and whatnot for other commands, and then asks the question of whether profiles should be per-provider, or always handled by rebar3 itself to avoid errors.

Having it be visible could be interesting because relx with a dev profile could use different configuration than the default one, but yeah.

I'm for the general idea of moving things to _build, and I agree the different profiles are needed, but need some thinking (along with possibly dropping the test deps mechanism currently in there?)

from rebar3.

My idea was to have it all set before getting to providers. And maybe just using env vars like how DEBUG is done. Or maybe either or, allow an env var or a --profile.

$ PROFILE=prod rebar3 compile

Hm, but some providers, like ct and eunit will want to use those specific profiles... That makes it a bit trickier.

And definitely want this for relx, I was planning to add it on top of relx itself separately, and rebar3 will be able to pass what the profile should be to relx. Note that the release provider also currently supports taking the relx config from rebar.config. If that isn't defined then it wil llook for relx.config.

from rebar3.

Working on a document of how profiles work, open for comment: https://gist.github.com/tsloughter/1e16d70268182db1415a

from rebar3.

This change is made in #31

from rebar3.