On 13 Feb 2014, at 1:16 am, Radim Kubacki <radim.kuba...@gradleware.com> wrote:
> On Thu, Feb 13, 2014 at 2:14 AM, Luke Daley <luke.da...@gradleware.com> wrote: > 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). > > I agree that we should make paths relative where possible. Relative to > project dir or gradle_user_home or gradle installation. Remaining parts are > external dependencies. Some of them are expected (system header files, JDK > installation) the rest should often be avoided. > > BTW the motivation for the topic comes from that problem with build pipelines > on CI server: how to reuse results from one build job in another one. Making > paths relative can help in some cases. If will not help if I build & unit > test my app on one OS and then start functional tests on Linux/Win/Mac and > avoid rebuilds. One idea is to play with dependencies - my local run of > funcTest can depend on source build (main sourceSet) and CI server will pass > a flag to change it to a dependency on an artifact built by previous job. > Does it makes sense? Is it something what we want to promote? Yes, this is how I would like to solve the use case. It’s kind of awkward at the moment, though. This is something we will address as part of the component dependency management stuff we’re doing for native and Android components (and JVM components too). -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
