clean eunit and ct

[tsloughter]

Currently the only way to do this is rebar3 as test clean. Maybe we should extend either the eunit and ct providers ho have clean commands or extend clean to have a --tests option?

[ferd]

sounds like rebar3 clean --tests is exactly as many characters as rebar3 as test clean

[tsloughter]

It isn't about number of characters it is about discoverability. If it is an option on clean then doing rebar3 help clean would inform the user of this.

[ferd]

it would, but then if I'm running a different tool, then there's no option for it and we're stuck adding arguments forever.

It might be better for rebar3 help clean to mention using it with a profile to clean stuff in non-default profiles. If I end up running tests under the native profile, then I would still need to do rebar3 as native clean --tests, or ask for rebar3 clean --profile=test+native which frankly isn't great.

[tsloughter]

I'm not sure what a different tool would matter. If it is based on tests compiled as extra src to the test profile it would be deleted just the same as eunit and common test beams. And if there is more to clean then it would have to provide a rebar3 <tool> clean command.

[ferd]

What I'm saying is not tool-related. It's that if I'm running test under a different compiler profile for example (where native specifies HiPE compilation), then our standard clean --tests or even a plain clean break because of the profile.

The current failure of the clean command is due to profile usage. I'm not too sure why profiles shouldn't be used to fix it either.

[tsloughter]

Then not sure what is wrong with rebar3 eunit clean.

[ferd]

that would be fine. That's up to the provider and I like it more than rebar3 clean --test or something.

[talentdeficit]

command line options already supported by eunit/ct complicate this

if a user does:

$ rebar3 ct --dir protocol

they will need to do:

$ rebar3 ct clean --dir protocol

additionally, ct and eunit currently share the test directory. cleaning one is going to have consequences for the other

i think extending rebar3 clean --all to simply deleting _build would be better

[ferd]

I've put the 3.0.0 milestone on this since we should make a decision before cutting a final release if it risks breaking backwards compatibility.

[tsloughter]

Crap, @talentdeficit has a good point. But I don't know that I like rebar3 clean --all just deleting the _build dir... That seems over the top.

[talentdeficit]

i think we should reconsider having rebar3 clean --all remove _build. it solves #1074 i think