{"action":"created","issue":{"url":"https://api.github.com/repos/rebar/rebar3/issues/158","labels_url":"https://api.github.com/repos/rebar/rebar3/issues/158/labels{/name}","comments_url":"https://api.github.com/repos/rebar/rebar3/issues/158/comments","events_url":"https://api.github.com/repos/rebar/rebar3/issues/158/events","html_url":"https://github.com/rebar/rebar3/issues/158","id":57982771,"number":158,"title":"all beam files should generate in a predictable location","user":{"login":"talentdeficit","id":4431,"avatar_url":"https://avatars.githubusercontent.com/u/4431?v=3","gravatar_id":"","url":"https://api.github.com/users/talentdeficit","html_url":"https://github.com/talentdeficit","followers_url":"https://api.github.com/users/talentdeficit/followers","following_url":"https://api.github.com/users/talentdeficit/following{/other_user}","gists_url":"https://api.github.com/users/talentdeficit/gists{/gist_id}","starred_url":"https://api.github.com/users/talentdeficit/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/talentdeficit/subscriptions","organizations_url":"https://api.github.com/users/talentdeficit/orgs","repos_url":"https://api.github.com/users/talentdeficit/repos","events_url":"https://api.github.com/users/talentdeficit/events{/privacy}","received_events_url":"https://api.github.com/users/talentdeficit/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2015-02-17T21:12:27Z","updated_at":"2015-02-25T01:45:05Z","closed_at":null,"body":"currently, rebar3 places beam files in a number of places depending on which task generated them. ideally, they should all be in the ebin dirs. this vastly simplifies tasks like `shell` and `cover` that expect to know where all beam files are located. however, as profiles currently share ebin dirs this means one profiles state can leak into another profiles state\r\n\r\npossible solutions:\r\n\r\n### generate each profiles (or combination of) artifacts in it's own _build tree ###\r\n\r\nrunning `rebar3 as test compile` (or any other command that generated beams) would create `_build\\test\\{ebin,priv,lib}` and use those paths for any subsequent tasks run under that profile. `rebar3 as foo, bar compile` could generate `_build\\foo+bar\\...` running as the default profile could continue to build as rebar3 does now (although we would probably want to move `_build/lib` to `_build/default/lib`\r\n\r\n##### advantages #####\r\n\r\n* no worrying about one profile's state infecting another profile\r\n* no requirement to use any kind of manifest to track desired state\r\n* things would mostly work as users expect them to work now\r\n\r\n##### disadvantages #####\r\n\r\n* `rebar3 as foo, bar do...` and `rebar3 as bar, foo do...` would generate different build trees which could be confusing to users\r\n* path complexity for users using tools outside of rebar's scope\r\n\r\n### add a cleanup step to rebar ###\r\n\r\nwe could generate a timestamp at initialization of state and then clean any beam files from the various ebin dirs that predate that timestamp in a cleanup step that runs after all tasks have completed\r\n\r\n##### advantages #####\r\n\r\n* the cleanup step would be fairly simple and would only require checking the last modified time of each beam file against the timestamp generated at startup. beams that are not regenerated during compile (because they are already correct) can have their timestamps updated with `file:change_time/2` when they're checked by `needs_update/4`\r\n* rebar would continue to work almost exactly as it does now\r\n\r\n##### disadvantages #####\r\n\r\n* plugins would have to be aware of this step and update timestamps on it's own generated beams that aren't regenerated\r\n* external tools that add beams to the ebin dir would have to do so after each time the cleanup task is run\r\n\r\n### don't ever delete anything in ebin dirs except when `rebar3 clean` is called ###\r\n\r\n##### advantages #####\r\n\r\n* easy to understand\r\n* users and external tools can do whatever they want outside of rebar and rebar won't interfere\r\n\r\n##### disadvantages #####\r\n\r\n* projects relying on `*.app.src` could, failing `rebar3 clean` being called, could end up with messed up app files\r\n* all projects, in the absence of `rebar3 clean`, could end up with messed up releases\r\n* potentially confusing output from tasks run with beams that user is not expecting to be present"},"comment":{"url":"https://api.github.com/repos/rebar/rebar3/issues/comments/75889838","html_url":"https://github.com/rebar/rebar3/issues/158#issuecomment-75889838","issue_url":"https://api.github.com/repos/rebar/rebar3/issues/158","id":75889838,"user":{"login":"talentdeficit","id":4431,"avatar_url":"https://avatars.githubusercontent.com/u/4431?v=3","gravatar_id":"","url":"https://api.github.com/users/talentdeficit","html_url":"https://github.com/talentdeficit","followers_url":"https://api.github.com/users/talentdeficit/followers","following_url":"https://api.github.com/users/talentdeficit/following{/other_user}","gists_url":"https://api.github.com/users/talentdeficit/gists{/gist_id}","starred_url":"https://api.github.com/users/talentdeficit/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/talentdeficit/subscriptions","organizations_url":"https://api.github.com/users/talentdeficit/orgs","repos_url":"https://api.github.com/users/talentdeficit/repos","events_url":"https://api.github.com/users/talentdeficit/events{/privacy}","received_events_url":"https://api.github.com/users/talentdeficit/received_events","type":"User","site_admin":false},"created_at":"2015-02-25T01:45:05Z","updated_at":"2015-02-25T01:45:05Z","body":"this probably needs to be resolved soon if we're aiming for alpha march 1\r\n\r\ni think right now i favour solution #3 with everything being built in `ebin` and only being removed when `clean` is called but #1 is okay to me too. i'm against doing anything that doesn't follow otp conventions like a scratch dir because rebar should be facilitating erlang development not dictating it. no other tool/user is going to expect a `scratch` dir or a bunch of random `tmp` dirs spread across the file system. i'd like whatever solution to result in a directory that looks and acts like an otp app\r\n\r\ncan we maybe leverage `relx` to generate the `_build` directory with the correct libs? "}}