https://pantsbuild.org/ logo
Powered by
#general
  • b

    bright-apartment-76721

    02/07/2017, 7:30 PM
    aha, so assuming all 100k scala files are in a single target, my colleague would need to rebuild all of them
  • b

    bright-apartment-76721

    02/07/2017, 7:30 PM
    if I broke it down better, he'd hate his life less
  • w

    witty-crayon-22786

    02/07/2017, 7:30 PM
    brb
  • w

    witty-crayon-22786

    02/07/2017, 7:30 PM
    correct
  • b

    bright-apartment-76721

    02/07/2017, 7:30 PM
    but what if I also shared the .pants.d folder?
  • b

    bright-apartment-76721

    02/07/2017, 7:31 PM
    (just trying to refine my understanding)
  • b

    bright-apartment-76721

    02/07/2017, 7:42 PM
    (not saying a persistent share, since as you say it's mutable, but I mean if I just shipped it over to his machine)
  • w

    witty-crayon-22786

    02/07/2017, 7:59 PM
    it might work? but a lot of stuff under .pants.d is not portable (another difference from the shared cache)
  • w

    witty-crayon-22786

    02/07/2017, 8:00 PM
    @bright-apartment-76721 : a safer working strategy is: ask him to do a clean build on a branch nearby your branch (say, master)
  • w

    witty-crayon-22786

    02/07/2017, 8:00 PM
    then 
    .pants.d
    is populated with classfiles and analysis for those inputs
  • w

    witty-crayon-22786

    02/07/2017, 8:00 PM
    then, switch to the branch and build again
  • w

    witty-crayon-22786

    02/07/2017, 8:01 PM
    you will miss the cache, but the state from the previous build will be there, and zinc will execute an incremental build relative to that previous clean build
  • b

    bright-apartment-76721

    02/07/2017, 8:02 PM
    main thing I'm trying to avoid (hypothetically) is compiling most of those 100k files more than once
  • b

    bright-apartment-76721

    02/07/2017, 8:02 PM
    my understanding is that your clean build thing would still require him to build most of them
  • b

    bright-apartment-76721

    02/07/2017, 8:02 PM
    and then it would only build what's changed when I move my state over to his
  • b

    bright-apartment-76721

    02/07/2017, 8:03 PM
    is that correct?
  • b

    bright-apartment-76721

    02/07/2017, 8:03 PM
    not really going to do this in practice if .pants.d doesn't have a stable format
  • b

    bright-apartment-76721

    02/07/2017, 8:04 PM
    just trying to sort through what sorts of things end up in which
  • b

    bright-apartment-76721

    02/07/2017, 8:05 PM
    also curious what a configurable --pants-supportdir is for. As I understand it, that folder contains things like a default ivy.xml
  • w

    witty-crayon-22786

    02/07/2017, 8:17 PM
    @bright-apartment-76721 : a clean build on master should hit a shared cache, assuming you build it somewhere useful
  • w

    witty-crayon-22786

    02/07/2017, 8:17 PM
    in particular, our CI writes to a remote cache
  • w

    witty-crayon-22786

    02/07/2017, 8:18 PM
    so the only time something isn't in the cache is when it hasn't been CId
  • w

    witty-crayon-22786

    02/07/2017, 8:18 PM
  • b

    bright-apartment-76721

    02/07/2017, 8:19 PM
    oh!
  • b

    bright-apartment-76721

    02/07/2017, 8:19 PM
    so I guess I'm just still not clear what falls under the zinc "not shared" bucket and what does
  • w

    witty-crayon-22786

    02/07/2017, 8:20 PM
    a clean build is cached. a zinc incremental build is not cached.
  • w

    witty-crayon-22786

    02/07/2017, 8:20 PM
    so on a clean build, the zinc analysis and class files are stored
  • w

    witty-crayon-22786

    02/07/2017, 8:21 PM
    if you hit the cache in one run, change a file, and then run again, the second run will not be written to the cache
  • w

    witty-crayon-22786

    02/07/2017, 8:21 PM
    because the second run will be incremental based on the first.
  • b

    bright-apartment-76721

    02/07/2017, 8:23 PM
    hmm
1...162616271628...2420Latest