| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
Corral, shade & embed jline.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As usual, the repl will use whatever jline 2 jar on the classpath,
if there is one. Failing that, there's a fallback and an override.
If instantiating the standard `jline.InteractiveReader` fails,
we fall back to an embedded, shaded, version of jline,
provided by `jline_embedded.InteractiveReader`.
(Assume `import scala.tools.nsc.interpreter._` for this message.)
The instantiation of `InteractiveReader` eagerly exercises jline,
so that a linkage error will result if jline is missing or if the
provided one is not binary compatible.
The property `scala.repl.reader` overrides this behavior, if set to
the FQN of a class that looks like `YourInteractiveReader` below.
```
class YourInteractiveReader(completer: () => Completion) extends InteractiveReader
```
The repl logs which classes it tried to instantiate under `-Ydebug`.
# Changes to source & build
The core of the repl (`src/repl`) no longer depends on jline.
The jline interface is now in `src/repl-jline`.
The embedded jline + our interface to it are generated by the `quick.repl` target.
The build now also enforces that only `src/repl-jline` depends on jline.
The sources in `src/repl` are now sure to be independent of it,
though they do use reflection to instantiate a suitable subclass
of `InteractiveReader`, as explained above.
The `quick.repl` target builds the sources in `src/repl` and `src/repl-jline`,
producing a jar for the `repl-jline` classes, which is then transformed using
jarjar to obtain a shaded copy of the `scala.tools.nsc.interpreter.jline` package.
Jarjar is used to combine the `jline` jar and the `repl-jline` into a new jar,
rewriting package names as follows:
- `org.fusesource` -> `scala.tools.fusesource_embedded`
- `jline` -> `scala.tools.jline_embedded`
- `scala.tools.nsc.interpreter.jline` -> `scala.tools.nsc.interpreter.jline_embedded`
Classes not reachable from `scala.tools.**` are pruned, as well as empty dirs.
The classes in the `repl-jline` jar as well as those in the rewritten one
are copied to the repl's output directory.
PS: The sbt build is not updated, sorry.
PPS: A more recent fork of jarjar: https://github.com/shevek/jarjar.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Tell SBT to that we're forking an interactive process
- Automatically add `-usejavacp` so the REPL adds the classes
from the system classloader to the compilers classpath.
JLine seems to be working from within this setup.
```
% sbt
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=384m; support was removed in 8.0
[info] Loading global plugins from /Users/jason/.sbt/0.13/plugins
[info] Loading project definition from /Users/jason/code/scala2/project
[info] *** Welcome to the sbt build definition for Scala! ***
[info] This build definition has an EXPERIMENTAL status. If you are not
[info] interested in testing or working on the build itself, please use
[info] the Ant build definition for now. Check README.md for more information.
> repl/run
[info] Running scala.tools.nsc.MainGenericRunner -usejavacp
Welcome to Scala version 2.11.6-SNAPSHOT-20150528-131650-70f0b1ded8 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_25).
Type in expressions to have them evaluated.
Type :help for more information.
scala> 1 + 1
res0: Int = 2
(reverse-i-search)`1': 1 + 1
```
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I added build configuration to ask SBT to forcible override the Scala
version in the subproject to the declared bootstrap version. I did
this in response to a warning by SBT the declared `scalaVersion`
has been evicted.
However, we actually *want* the newer version. To get rid of the
warning, we need to exclude all `"org.scala-lang" % "*"` when
depending on Scala modules. This cleanly breaks the cycle.
Here's a diff of `*/dependencyClasspath` as a result of this patch:
https://gist.github.com/retronym/217c76001b1b81798042
|
| |
|
|
|
|
|
|
|
|
| |
Partest tests are defined in Integration configuration.
This means you need to run them with `test/it:test` command. We put them
in separate configuration because they are slow to run so user needs to
ask explicitly for partest to run.
Introduce a common way of setting jar location so it can be reused between
`scalaSubprojectSettings` and `partestJavaAgent`.
|
| |
|
|
|
|
|
| |
Add dependency on scaladoc in junit subproject, as required by
6e6632e (it introduced a junit test for scaladoc).
Enable assertion stack traces and info logging of each test.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
- Explicitly set [un]managed[re]sourceDirectories for all
projects to improve the import into IntelliJ
- Add partest extras project, that contains scala/scala specific
extensions to partest for use in partest and junit tests.
- Add junit project, which contains unit tests for the compiler and
library.
|
| |
|
|
|
|
|
|
| |
Common library dependencies are extracted into vals.
Those dependencies define "scala-library" as an excluded transitive
dependency so we don't get eviction warnings during `update`.
Lastly, version numbers for dependencies are obtained from
`versions.properties` file.
|
| |
|
|
|
|
|
|
| |
This way we don't need to worry about mixing classes for Scala compiler
that sbt is invoking and the one we just built. For an example of
possible problem, check out:
https://github.com/gkossakowski/scala/pull/2#issuecomment-78169188
|
| |
|
|
|
|
|
|
|
|
| |
Shell scripts are generated with `mkBin` sbt task that calls ScalaTool.
ScalaTool is defined in project/ and is a port of Ant task that lives
in scala.tools.ant.ScalaTool. While porting, we've simplified the code
significantly.
The `mkBin` task is defined in a new subproject: dist. This subproject
will become responsible for building the distribution in the future.
|
| |
|
|
|
|
|
|
|
|
|
| |
Static resources are stored along source files in our current layout.
Therefore we set resourceDirectory to be sourceDirectory but make sure
that includeFilter includes nothing by default. Subprojects like library
or compiler set their own include filters.
The include filters have been ported from the Ant build definition.
Generate properties for: library, reflect, compiler & actors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Scala artifacts (like library or compiler) are published are published
with "scala-" prefix in their name. We keep project ids short so we can
refer to projects simply by e.g. `library` and not `scala-library`.
Given that `name` settings will have a different value, we switch to
`Project.id` when constructing paths for target directories.
We had to tweak properties generation because over there we use project
name as a file name without "scala-" prefix.
Since our projects are not named uniformly (e.g., "repl" and not "scala-repl"),
add a setting for each subproject that requires special handling.
|
| |
|
|
|
|
|
| |
Add welcome message that is shown at sbt's startup. The message clearly
indicates experimental status of sbt build.
Also, add a short paragraph to README.md explaining status of sbt build.
|
| |
|
|
|
|
| |
Let's override `sources` task to return empty collections of sources to
compile. Otherwise, sbt by default would pick up sources in the root
directory which is not what we want.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Scaladoc depends on scala-xml, etc, built with the previous stable
version of Scala. This isn't ideal, but we're stuck with this for
now.
We were relying on Ivy to evict the transitive dependency on the
old version of scala-library. However, SBT treats evictions of
scala-library as suspicious and emits a custom warning.
This commit explicitly excludes the transitive dependency so
as to avoid these warnings. It also makes the output of `show update`
a little easier to read.
|
| |
|
|
|
|
| |
As suggested in sbt/sbt#1872, specify ScalaInstance manually
and use sbt's launcher as a context for Ivy resolution. This way
we avoid the circular dependency problem described in the issue.
|
| |
|
|
|
|
| |
Mirror ant by disabling docs and publishing tasks in these subprojects.
Class files are included by merging `mappings`: the `package` task
uses it to determine which class files should end up in a jar file.
|
| |
|
|
|
|
|
|
|
| |
Put library class files to scaladoc's classpath when documenting the library.
TODO: why is this needed? Bug in scaladoc?
Pass `src/library-aux` to scaladoc using `-doc-no-compile` option.
To mimic ant, output docs into `buildDirectory/scaladoc/$name`.
|
| |
|
|
|
|
|
|
| |
As they are forks of external Java projects, don't document/publish them.
TODO: move them out of the repo
As in ant, pass -g, -source and -target options to javac to get
byte-identical outputs for Java files between Ant and sbt builds.
|
| |
|
|
|
| |
Move most of `commonSettings` to `subprojectSettings` and keep
`commonSettings` truly minimal.
|
| |
|
|
|
|
|
|
|
|
|
| |
This settings determines location of where class files, jars, and other
build products will go. By default, it's `./build-sbt`. It makes it easier
to compare what Ant and sbt builds do.
Also, changed `SettingKey` to `settingKey`. The latter is a macro that
automatically determines `label` of a setting and takes a description as
argument. Before that, `SettingKey("my desc")` would create a setting key
with `label` set to "my desc". Not what we wanted.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, Project.base was set to ./$name and we tweaked manually the
`baseDirectory` setting to point at `.`. This was confusing sbt and its
plugins. We are setting Project.base to ./src/$name and leave
`baseDirectory` intact (so it will point at `./src/$name`.
Adapt settings that depend on `baseDirectory` accordingly.
Refactor configuration as a subproject into a common method.
Given that `baseDirectory` is pointing at `src/$name`, we don't have to
worry about `sourcesInBase`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an sbt task that generates .properties files that are packaged
into jars. The properties file contains Scala version in various
formats.
The task is registered as a resource generator so sbt can properly
track generated files and make sure they are included in packaged
jars.
The implementation of generateVersionPropertiesFile contains a note
on arbitrary order of written properties. We could consider using
https://github.com/etiennestuder/java-ordered-properties
to guarantee a stable order. Or simply ditch using Properties class
and generate a String. Our property files are simple enough that
nothing more fancy is needed.
|
| |
|
|
|
|
|
|
|
|
|
| |
Override default location for jars to be build/pack/lib. This turned out
to be a bit more involved than I expected. Check the diff for details.
Strip down the -version suffix from jar names.
For now we're trying to mimic Ant's build as closely as possible. Ant does
not embed version numbers in jar names it creates in build/pack/lib
directory.
|
|
|
It mimics the ant build as closely as necessary to compare the produced
artifacts between the two builds, to build confidence in the transition:
- all projects are built into the same directories in build/quick
- include legacy projects: forkjoin, asm, actors
- TODO: Include forkjoin & asm into library & compiler jars, respectively.
We don't carry over ant's built-in bootstrapping process;
this will be scripted outside of the build, publishing layers locally.
NOTE: the root project cannot be named `scala`:
it shadows the `scala` package in e.g., `projectConsole`.
|
