It turns out that `syntaxAnalyzer.UnitParser()` in global now also
needs to be synchronized. The alternative is adding `synchronizeNames = true`
in the global constructor, but that already proved unreliable in the
case of #3743 (see comment https://github.com/sbt/sbt/issues/3170#issuecomment-355218833)
When source generators write into the unmanaged source directory, bad
things can happen. Continuous builds will loop indefinitely and
compiling will fail because the generated sources get added to the
source list twice, causing the incremental compiler to complain about
compiling classes it has already seen. My two-pronged solution is to
de-duplicate the sources task and to filter out managed source files in
watch sources. The drawback to the latter is that it causes the source
generation task to be executed twice per compile.
In https://github.com/sbt/io/pull/142, I add a new api for watching for
source file events. This commit updates sbt to use the new EventMonitor
based api. The EventMonitor has an anti-entropy parameter, so that
multiple events on the same file in a short window of time do not
trigger a build. I add a key to tune it.
The implementation of executeContinuously is pretty similar. The main
changes are that shouldTerminate now blocks (EventMonitor spins up a
thread to check the termination condition) and that the
EventMonitor.watch method only returns a Boolean. This is because
the event monitor contains mutable state. It does, however, have a
state() method that returns an immutable snapshot of the state.
The existing filter caused SourceModificationWatch.watch to ignore
deleted files because !file.exists implies !file.isFile. The intention
of the filter was to exclude directories that had a name ending in
".scala".
Fixes#3849
This brings back the 0.13 logic:
```scala
def setGlobalLogLevel(s: State, level: Level.Value): State = {
s.globalLogging.full match {
case a: AbstractLogger => a.setLevel(level)
case _ => ()
}
s.put(BasicKeys.explicitGlobalLogLevels, true).put(Keys.logLevel.key, level)
}
```
Fixes#3841
This fixes console task that internally uses JLine. When `console` is started from batch mode, the tab is printed as is. This is because JLine is not initialized yet.
Calling `usingTerminal` initializes and restores the terminal afterwards.
There are just too many instances in which sbt's code relies on
the `lastModified`/`setLastModified` semantics, so instead of moving
to `get`/`setModifiedTime`, we use new IO calls that offer the new
timestamp precision, but retain the old semantics.
Previously I was seeing the error upon the first scripted test. I thought it was because Main was somehow not early enough. It might just be because scripted technically runs as part of the build.
Ref sbt/io#110
Fixes#3823
When you launch a second instance of sbt on a build, prior to this change it was displaying `java.io.IOException: sbt server is already running` on every command. This make it a bit less aggressive, and just display a warning once.
```
[warn] Is another instance of sbt is running on this build?
[warn] Running multiple instances is unsupported
```
veera venky
Antonio Cunei
eugene yokota
Øyvind Høisæther
Liu Fengyun
Seth Tisue
Ethan Atkins
Dale Wijnand
Alexey Alekhin
Jason Steenstra-Pickens
tmiyamon
Dale Wijnand
Steve Waldman
Antonio Cunei