-
Notifications
You must be signed in to change notification settings - Fork 0
/
notes
62 lines (53 loc) · 3.71 KB
/
notes
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
Issues moving Launcher to 2.8:
creating an Array requires a Manifest, which brings in 40k of classes in scala.reflect
scala.package$ is 3k (import scala.collection.immutable.List) and brings in scala.xml
RichInt 2k. scala.collection.mutable.StringBuilder.ensureCapacity uses it (max), which is needed for string concat
scala.xml brings in 50k of classes
scala.math brought in 30k, can't remove because RichInt apparently uses it
100k additional size adds 50ms to startup time (on my faster machine)
difference between classpaths a) just launcher jar b) current directory + launcher jar is that b) is 50 ms slower than a)
was able to return to old size by enabling optimize/obfuscate phases of ProGuard
- script tasks (in 'scripts' branch). To use:
1) add implementation of jsr223 to project/build/lib, declare in project/plugins, or add to sbt startup classpath
2) Mix sbt.scripts.Scripts into your project definition
3) Create project/scripts/name.ext
4) Run as 'name'
5) To work with dependencies, get the task from the scriptedTasks map by name. Ex:
lazy val myTask = task { ... } dependsOn scriptedTasks("myscript").
- added experimental 'sbt-update version [output.jar]' command enabled by mixing in UpdateSbt trait. It probably doesn't work on Windows, but confirmation either way would be helpful.
Changes 'sbt.version' after verifying the version is valid by downloading that version of sbt.
Updates the current launcher jar or the location specified in the second argument with either a downloaded sbt-launch-<version>.jar if available or a copy of the current launcher jar that uses <version> by default when starting new projects.
TODO:
- tasks as promises
- aggressive recompilation
- API API. Read, write, search API.
- source build system
- launcher interface versioning
- allow comments in datatype definition file
- tests for API extractor
- have background triggered commands (~sync)
Task engine
- method tasks will be normal tasks that pull the command line from a CommandLine task
- per task configuration, including logging (e.g. 'task compile log debug')
- unnamed tasks log to parent task
- better control over parallel logging. Approach undecided. Some possibilities:
+ optionally one task always logging
+ log each task to a file
+ interactive control over logging (might require tasks that use console to be explicit in their dependence on the console)
- should be able to connect one preprocessor to another
- Interfaces subproject that depends on no other project and defines interfaces in package xsbti. They are written in Java and cannot refer to Scala classes (compileOrder = JavaThenScala). These interfaces can be used to pass objects across ClassLoader boundaries.
- launcher/main interface is not static (no system properties should be used past the static entry point)
- simple, well-defined ClassLoaders
- use Exceptions instead of Option/Either
- every component gets its own subproject
- can use any version of compiler/Scala that is source compatible with the compiler-interface component
- build xsbt using normal cross-build conventions
- compiler: raw interface (no dependency analysis, but still in same jvm) or with dependency analysis
- compiler: can specify scala-library.jar and scala-compiler.jar + version instead of retrieving the ClassLoader
- compiler: new phase that extracts API defined in sources (classes, their members, and all type information)
- minimal dependence on main xsbt logger from subcomponents: use thin interface for subcomponents
Dependency Management
- resolvers are completely defined in project definition (use Resolver.withDefaultResolvers)
- configurations completely defined within project (use ModuleConfiguration.configurations)
Launcher
- see launch.specification