On 16 Feb 2014, at 4:31 pm, Luke Daley <luke.da...@gradleware.com> wrote:
> So it seems the best thing would be to post back to the forum user that this > will in effect never be “supported”, but if they want to live dangerously > then we would accept a PR to relativize the particular paths in question. > > Agree? Pretty much, except for the “never” bit. I think we’ll get to this point eventually, but it’s a long way off. > >> Adam Murdoch <mailto:adam.murd...@gradleware.com> >> 14 February 2014 1:36 am >> >> We can, yes. There are a few cases where it won’t work: >> >> - There are absolute paths in the task’s input property values (eg Test and >> BuildDashboard) >> - The task maintains any kind of incremental state that the itself (eg the >> incremental compile tasks). >> - The task output is not portable (eg absolute paths baked into native >> binaries at link time). >> >> I’m sure there are more. The first two are probably ok to ignore, as they >> just mean we end up doing more work than we should in the new workspace. The >> third is potentially quite nasty, because we would skip work that we should >> be doing, leaving the output pointing to files in the old location rather >> than the copies in the new location. This is not good from an incremental >> build point of view. >> >> The problem here is that I don’t really want to guarantee anything about >> portability, as I think there are probably better ways to solve this use >> case. We can probably make it good enough, but we’d need to know whether the >> task output is portable or not. >> >> >> -- >> Adam Murdoch >> Gradle Co-founder >> http://www.gradle.org >> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting >> http://www.gradleware.com >> >> >> >> >> Luke Daley <mailto:luke.da...@gradleware.com> >> 13 February 2014 11:14 am >> Hi, >> >> http://forums.gradle.org/gradle/topics/incremental_build_state_should_be_decoupled_from_workspace_location >> >> >> I imagine that guaranteeing that the task artifact cache is completely >> portable would be quite difficult, but could we make all paths relative? >> This might be good enough portability in some use cases (though admittedly I >> don't know much about that machinery so that could be a grossly inaccurate >> statement). > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
