-
-
Notifications
You must be signed in to change notification settings - Fork 638
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error compiling code that is source compatible, but binary incompatible, across library boundaries #4596
Comments
In your second run, you'll notice that the compile of Pants does not write incremental compiles to the buildcache by default ( But you should always either 1) run zinc incremental compiles are a deal with the devil which is really only safe to make on developer machines. Whether we should invert the default and disable it by default is an open question. |
Hm, we've got |
No difference.
First
Update MyClass and then
So, am seeing the |
Interestingly, with incremental compilation off, |
Yikes. |
I'm going to pull this into an integration test to see if I can check it against other pants versions. |
got a reproduction working. Or, to be more precise, not working. |
testing on pants 1.2.1 |
Testing on pants 1.2.1. It looks like 1.2.1 doesn't exhibit the behavior. |
now trying 1.3.0.dev4 |
I've narrowed it down to a change between 1.3.0.dev16 and .dev19 |
Between .dev18 and .dev19 |
It's this one 94775d9 |
Fixed by #4607 |
Arg...too bad. Is the hope that the 1.4.0 zinc upgrade could make this a possibility again? |
Yea, hopefully. See #4477. Also, there is some movement on this upstream. |
Repro
pants.ini
:BUILD
:MyClass.scala
:MyApp.scala
:Run
./pants run :MyApp-bin
:Now edit
MyClass.scala
to add an optional 3rd argument to the method:And re-run
./pants run :MyApp-bin
:Interestingly, in futzing around with this repro, when I got a shared cache server involved, after the 2nd run's
NoSuchMethodError
, running./pants clean-all
, and then running again, the cache server had both compilations and then I could freely flip back and forth between versions ofMyClass.scala
and haverun
work fine in both cases without aclean-all
. Context here is this error put all my build agents out of commission and so thus I was exploring to what extent the shared cache server helped or hindered here.The text was updated successfully, but these errors were encountered: