The name hashing seems to be stable enough for sbt to use it by default
now. It also greatly improves incremental compilation experience for
people working on sbt sources.
This commit implements an Ant-style incremental compilation mode. This mode
emulates what Ant's scalac command does. It recompiles just changed source
files and does not perform any invalidation of dependencies.
This is a very naive mode of incremental compilation that very often leads
to broken binaries.
The Ant-style mode is being introduced because Scala team needs it for
migration of Scala compiler to sbt. The name hashing algorithm doesn't
work well with Scala compiler sources due to deep inheritance chains.
There's a plan to refactor compiler's code to use more composition instead
of inheritance.
Once Scala compiler sources are refactored to work well with name hashing
algorithm, Ant-style mode will be deleted immediately.
Add an option that enables (to be implemented) Ant-style mode of
incremental compilation.
This option is unsupported and may go away at any point in the future.
NOTE: Either `antStyle` or `nameHashing` mode can be enabled. This is
being enforced with runtime assertion.
Add pending test for Ant-style incremental compilation. In that mode
incremental compiler will recompile only the source files that were changed
by the user and won't try to invalidate any dependencies.
Once Ant-style incremental compilation is implemented this test should be
passing.
This does the following:
* Fragments loading into two stages: Discovery + Resolution
* Discovery just looks for .sbt files and Projects, while
loading/compiling them.
* Resolution is responsible for taking discovered projects and
loaded sbt files and globbing everything together. This includes
feeding the project through various manipulations, applying
AutoPlugin settings/configurations and ordering all the settings.
* Add a bunch of docs
* Add direct DSL `enablePlugins` and test
* Add direct DSL `disablePlugins` and test.
* Create new DSLEntry type for settings so we can categorize what we parse
* Use DSLEntry to help solve the Setting[_] vs. Seq[Setting[_]] implicit fun.
* Hack away any non-Setting[_] DSLEntry for now.
* Add test in build.sbt to make sure the new DSL works.
* Modify scripted task parser to allow "pagination" of globs
e.g. "*1of3" will create three pages and run page 1.
* Modify travis definition to fragment long-running test groups
into pages so we stay under the 50 minute limit.
1) non-default derived settings, if they produce anything, the settings
they produce must supersede previous assignents (in the settings seq)
to the same key.
2) even if a derived setting is scoped at a higher scope (e.g.
ThisBuild) the settings it produces are scoped at the intersection of
that (the defining) scope and the scope of the triggering dependency.
2 is particularly nice as it enables this behaviour:
derive(b in ThisBuild := a.value + 1)
a in project1 := 0
// a could be defined in all projects
==>
Now (b in project1).value == (a in project1).value + 1 == 1
and similarly in all other projects
all with a single derived setting
Eugene Yokota
Grzegorz Kossakowski
Josh Suereth
Martynas Mickevicius
xuwei-k
Jarek Sacha
rschatz
Dan Sanduleac
Dan Sanduleac