Optional(?) New Output Directory Structure

[tsloughter]

rebar is unique as a build tool for writing all over and not into a single directory. mix uses _build, lein uses target, cabal uses dist, ocamlbuild uses _build and sinan used _build.

So I suggest a structure like:

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

We could support this being optional and outputting as we are currently if not selected. But since where things are outputted doesn't change actual build compatibility with rebar2 (I hope...), maybe that is a waste of effort.

Obviously we'll also need to make some optional changes to rebar.config as well to allow for these different build profiles (dev, prod, etc.) But my idea for that is to simply have anything at the top level be dev or default and you can then define a context like {prod, [....]}. where any usual rebar.config term can be within that list.

[talentdeficit]

+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?

[tsloughter]

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.

[talentdeficit]

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

[tsloughter]

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).

[talentdeficit]

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

[tsloughter]

Yup, that is what I was thinking.

@ferd ?

[ferd]

What would the default profile be?

[tsloughter]

@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.

[ferd]

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?)

[tsloughter]

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.

[tsloughter]

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

[tsloughter]

This change is made in #31