pantsbuild #general

@plain-sundown-25537 understood. What I'd like to know is what you're using the jar for. The assumption the pants team had was that jars would only be used for 2 purposes: 1 to deploy a binary via

./pants binary

- which produces a fat jar to dist/ or

./pants bundle

which produces an application archive containing jars to dist/ 2. to publish a jar to a local or remote maven repo for sharing - in the local case using

./pants publish.jar --local=/some/path/I/know

and thus depositing the jars in a known location

enough-analyst-54434

11/21/2016, 3:23 PM

As such, we expected the

./pants jar

goal to be un-used by users, and in which case the error was exposing it in the list of

./pants goals

👍 2

plain-sundown-25537

11/21/2016, 6:51 PM

got it. This jar is as of a plugin of other system, hence the publish semantic is more likely what I want. Especially if publish.jar supports —local flag, this can solve my(workflow) problem immediately

plain-sundown-25537

11/21/2016, 6:52 PM

Well it does support —local ./pants publish.jar —local=dist foo/project1::

plain-sundown-25537

11/21/2016, 6:52 PM

so problem solved 🙂

rough-minister-58256

11/21/2016, 7:59 PM

Copy code

ERROR] Invalid option 'name_hashing' under [compile.zinc] in …

rough-minister-58256

11/21/2016, 8:00 PM

hrm

full-kilobyte-93429

11/21/2016, 8:37 PM

@rough-minister-58256 that's no longer supported with new zinc

rough-minister-58256

11/21/2016, 8:38 PM

rgr, found the commit history

full-kilobyte-93429

11/21/2016, 8:46 PM

@limited-country-20626 my apologies, should have waited for your review on the zinc upgrade, pls let me know if we should prioritize the perf issue

full-kilobyte-93429

11/21/2016, 8:47 PM

it's mostly for incremental compile for certain targets, root cause unclear cc @ancient-stone-50795

ancient-stone-50795

11/21/2016, 8:49 PM

@full-kilobyte-93429 how can I be of service? Square doesn't use incremental compilation, FWIW

full-kilobyte-93429

11/21/2016, 8:50 PM

then that change should not affect you 🙂 the non-incremental compile should be on par

limited-country-20626

11/21/2016, 8:53 PM

no apologies needed. I try to keep up with you all, but the review queue can get large.

limited-country-20626

11/21/2016, 8:54 PM

I have turned it off but I may not get a good idea on the performance hit of just this change, since it is landing alongside some significant build time improvements I made

limited-country-20626

11/21/2016, 8:55 PM

I am testing it now...I can perhaps run an apples-to-apples test across our build cluster overnight

full-kilobyte-93429

11/21/2016, 8:58 PM

as it turns out there is indeed an option on the zinc side https://github.com/sbt/zinc/blob/936b08454bc233ad04fcdccb2ccb60b840495e5f/internal/compiler-interface/src/main/datatype/incremental.json#L106

full-kilobyte-93429

11/21/2016, 8:59 PM

so my previous statement it is not supported by zinc is wrong.

full-kilobyte-93429

11/21/2016, 9:00 PM

so the tradeoff is whether we want to support two formats for the transition period

full-kilobyte-93429

11/21/2016, 9:02 PM

@limited-country-20626 let me how the test goes

limited-country-20626

11/21/2016, 9:06 PM

is there a high-level doc about this available publicly? Transition period is, I guess, now. And we are transitioning from 1.0.0 to ?

limited-country-20626

11/21/2016, 9:06 PM

I don't need nitty gritty level doc, just general road map would be nice

limited-country-20626

11/21/2016, 9:07 PM

or even just TLDR

full-kilobyte-93429

11/21/2016, 9:09 PM

from 0.13.x to 1.0.0, name hashing is probably the main thing, for us it's a few zinc patches that we really need

full-kilobyte-93429

11/21/2016, 9:11 PM

this is the primary one https://github.com/sbt/zinc/pull/94 so the analysis file could end up in a corrupted state