* use normal TypeTree constructor
* remove unnecessary 'with Singleton' in macro utility
* integrate changes suggested by @xeno-by
* add refVar back and call asTypeConstructor instead of asType to refer to a type variable
* use normal TypeTree constructor
* remove unnecessary 'with Singleton' in macro utility
* integrate changes suggested by @xeno-by
* add refVar back and call asTypeConstructor instead of asType to refer to a type variable
* use normal TypeTree constructor
* remove unnecessary 'with Singleton' in macro utility
* integrate changes suggested by @xeno-by
* add refVar back and call asTypeConstructor instead of asType to refer to a type variable
1. KList[M[_]] now instead of KList[HL <: HList, M[_]]
a. head, tail work properly in this variant
b. disadvantage is that full type not easily transformed to new type constructor
2. AList abstracts on K[L[x]], a higher order type constructor.
A. Instances written for:
a. KList
b. Seq[M[T]] for a fixed T
c. TupleN
d. single values
e. operate on one type constructor when nested
B. Main disadvantage is type inference. It just doesn't happen for K[L[x]].
This is mitigated by AList being used internally and rarely needing to construct a K.
* split several source files
* move base settings sources (Scope, Structure, ...) into main/settings/
* breaks cycles. In particular, setting system moved from Project to Def
1. KList[M[_]] now instead of KList[HL <: HList, M[_]]
a. head, tail work properly in this variant
b. disadvantage is that full type not easily transformed to new type constructor
2. AList abstracts on K[L[x]], a higher order type constructor.
A. Instances written for:
a. KList
b. Seq[M[T]] for a fixed T
c. TupleN
d. single values
e. operate on one type constructor when nested
B. Main disadvantage is type inference. It just doesn't happen for K[L[x]].
This is mitigated by AList being used internally and rarely needing to construct a K.
* split several source files
* move base settings sources (Scope, Structure, ...) into main/settings/
* breaks cycles. In particular, setting system moved from Project to Def
* must start with val, lazy val, or def (no modifiers currently)
* visible only within the same .sbt file
* multiple definitions allowed without being separated by blank lines
* no blank lines allowed within a definition
Project.autoSettings accepts a sequence of AddSettings, instances of which
are constructed from methods in AddSettings. The configurable settings
are per-user settings (from ~/.sbt, for example), settings from .sbt files,
and plugin settings (project-level only). The order in which these instances
are provided to autoSettings determines the order in which they are appended
to the settings explicitly provided in Project.settings.
For .sbt files, defaultSbtFiles adds the settings from all .sbt files in the
project's base directory as usual. AddSettings.sbtFiles accepts a sequence
of Files that will be loaded according to the standard .sbt format. Relative
Files are resolved against the project's base directory.
Plugin settings may be included on a per-Plugin basis by using the plugins
method and passing a Plugin => Boolean. The settings controlled here are
only the automatic per-project settings. Per-build and global settings will
always be included.
because Mac OSX doesn't have a realpath binary.
This solves the issue where if you symlink to sbt, it
won't be able to locate the bash library and launcher anymore.
You'd want to do that so you can symlink just sbt to /usr/local/bin
without having to put a bash library file there as well.
In particular, this is what we'd like for Mac homebrew.
An organization that has had to fork sbt is likely to change the version
slightly. The code is intended to match 0.12.1-foo as a 0.12.1 version,
but in fact without this change does not.
Mark Harrah
Eugene Vigdorchik
Benjy
Josh Suereth
Bart Schuller
Johannes Rudolph
Eric Bowman
James Ward