Docs: removing remaining mentions of "~="

This commit is contained in:
Mark Harrah 2013-08-30 18:34:54 -04:00
parent 11a7151af3
commit d1c68295c0
10 changed files with 32 additions and 31 deletions

View File

@ -56,8 +56,9 @@ To modify the type of the main artifact, for example:
:: ::
artifact in (Compile, packageBin) ~= { (art: Artifact) => artifact in (Compile, packageBin) := {
art.copy(`type` = "bundle") val previous: Artifact = (artifact in (Compile, packageBin)).value
previous.copy(`type` = "bundle")
} }
The generated artifact name is determined by the `artifactName` The generated artifact name is determined by the `artifactName`
@ -170,8 +171,9 @@ instead of the `.jar` file.
publishArtifact in (Compile, packageBin) := false publishArtifact in (Compile, packageBin) := false
// create an Artifact for publishing the .war file // create an Artifact for publishing the .war file
artifact in (Compile, packageWar) ~= { (art: Artifact) => artifact in (Compile, packageWar) := {
art.copy(`type` = "war", extension = "war") val previous: Artifact = (artifact in (Compile, packageWar)).value
previous.copy(`type` = "war", extension = "war")
} }
// add the .war file to what gets published // add the .war file to what gets published

View File

@ -333,8 +333,9 @@ To define extra attributes on the current project:
:: ::
projectID ~= { id => projectID := {
id extra("color" -> "blue", "component" -> "compiler-interface") val previous = projectID.value
previous.extra("color" -> "blue", "component" -> "compiler-interface")
} }
Inline Ivy XML Inline Ivy XML

View File

@ -288,7 +288,10 @@ tags applied to it. Only the first computation is labeled.
compile := myCompileTask.value compile := myCompileTask.value
compile ~= { ... do some post processing ... } compile := {
val result = compile.value
... do some post processing ...
}
Is this desirable? expected? If not, what is a better, alternative Is this desirable? expected? If not, what is a better, alternative
behavior? behavior?

View File

@ -49,7 +49,7 @@ need Saxon. By depending only on the `scalate` configuration of
classpathConfiguration in Common := CustomCompile, classpathConfiguration in Common := CustomCompile,
// Modify the default Ivy configurations. // Modify the default Ivy configurations.
// 'overrideConfigs' ensures that Compile is replaced by CustomCompile // 'overrideConfigs' ensures that Compile is replaced by CustomCompile
ivyConfigurations ~= overrideConfigs(Scalate, Saxon, Common, CustomCompile), ivyConfigurations := overrideConfigs(Scalate, Saxon, Common, CustomCompile)(ivyConfigurations.value),
// Put all dependencies without an explicit configuration into Common (optional) // Put all dependencies without an explicit configuration into Common (optional)
defaultConfiguration := Some(Common), defaultConfiguration := Some(Common),
// Declare dependencies in the appropriate configurations // Declare dependencies in the appropriate configurations

View File

@ -269,7 +269,8 @@ like a local directory.
:: ::
buildDependencies in Global ~= { deps => buildDependencies in Global := {
val deps = (buildDependencies in Global).value
val oldURI = uri("...") // the URI to replace val oldURI = uri("...") // the URI to replace
val newURI = uri("...") // the URI replacing oldURI val newURI = uri("...") // the URI replacing oldURI
def substitute(dep: ClasspathDep[ProjectRef]): ClasspathDep[ProjectRef] = def substitute(dep: ClasspathDep[ProjectRef]): ClasspathDep[ProjectRef] =

View File

@ -30,9 +30,7 @@ Dependencies in `lib` go on all the classpaths (for `compile`,
`test`, `run`, and `console`). If you wanted to change the `test`, `run`, and `console`). If you wanted to change the
classpath for just one of those, you would adjust classpath for just one of those, you would adjust
`dependencyClasspath in Compile` or `dependencyClasspath in Runtime` `dependencyClasspath in Compile` or `dependencyClasspath in Runtime`
for example. You could use `~=` to get the previous classpath value, for example.
filter some entries out, and return a new classpath value. See :doc:`more about settings <More-About-Settings>`
for details of `~=`.
There's nothing to add to `build.sbt` to use unmanaged dependencies, There's nothing to add to `build.sbt` to use unmanaged dependencies,
though you could change the `unmanagedBase` key if you'd like to use though you could change the `unmanagedBase` key if you'd like to use

View File

@ -23,7 +23,7 @@ sbt: The Core Concepts
- your build definition is one big list of `Setting` objects, where a - your build definition is one big list of `Setting` objects, where a
`Setting` transforms the set of key-value pairs sbt uses to perform `Setting` transforms the set of key-value pairs sbt uses to perform
tasks. tasks.
- to create a `Setting`, call one of a few methods on a key: `:=`, `+=`, `++=`, or `~=`. - to create a `Setting`, call one of a few methods on a key: `:=`, `+=`, or `++=`.
- there is no mutable state, only transformation; for example, a - there is no mutable state, only transformation; for example, a
`Setting` transforms sbt's collection of key-value pairs into a new `Setting` transforms sbt's collection of key-value pairs into a new
collection. It doesn't change anything in-place. collection. It doesn't change anything in-place.

View File

@ -241,13 +241,14 @@ This means that it can provide different logging based on the task that requests
:: ::
extraLoggers ~= { currentFunction => extraLoggers := {
val currentFunction = extraLoggers.value
(key: ScopedKey[_]) => { (key: ScopedKey[_]) => {
myCustomLogger(key) +: currentFunction(key) myCustomLogger(key) +: currentFunction(key)
} }
} }
Here, we take the current function for the setting `currentFunction` and provide a new function. Here, we take the current function `currentFunction` for the setting and provide a new function.
The new function prepends our custom logger to the ones provided by the old function. The new function prepends our custom logger to the ones provided by the old function.
.. howto:: .. howto::

View File

@ -98,7 +98,7 @@ Settings and Tasks
See the :doc:`Getting Started Guide </Getting-Started/Basic-Def>` for See the :doc:`Getting Started Guide </Getting-Started/Basic-Def>` for
details. details.
- `:=`, `+=`, `++=`, `~=` These - `:=`, `+=`, `++=` These
construct a `Setting <../api/sbt/Init$Setting.html>`_, construct a `Setting <../api/sbt/Init$Setting.html>`_,
which is the fundamental type in the :doc:`settings </Getting-Started/Basic-Def>` system. which is the fundamental type in the :doc:`settings </Getting-Started/Basic-Def>` system.
- `value` This uses the value of another setting or task in the definition of a new setting or task. - `value` This uses the value of another setting or task in the definition of a new setting or task.

View File

@ -86,7 +86,7 @@ You may run `sbt console`.
Build definitions Build definitions
----------------- -----------------
What are the `:=`, `+=`, `++=`, and `~=` methods? What are the `:=`, `+=`, and `++=` methods?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
These are methods on keys used to construct a `Setting` or a `Task`. The Getting These are methods on keys used to construct a `Setting` or a `Task`. The Getting
@ -393,7 +393,10 @@ basic structure of defining `onLoad`:
// Compose our new function 'f' with the existing transformation. // Compose our new function 'f' with the existing transformation.
{ {
val f: State => State = ... val f: State => State = ...
onLoad in Global ~= (f compose _) onLoad in Global := {
val previous = (onLoad in Global).value
f compose previous
}
} }
Example of project load/unload hooks Example of project load/unload hooks
@ -413,7 +416,10 @@ has been loaded and prints that number:
println("Project load count: " + previous) println("Project load count: " + previous)
s.put(key, previous + 1) s.put(key, previous + 1)
} }
onLoad in Global ~= (f compose _) onLoad in Global := {
val previous = (onLoad in Global).value
f compose previous
}
} }
Errors Errors
@ -455,17 +461,9 @@ A more subtle variation of this error occurs when using :doc:`scoped settings </
// error: Reference to uninitialized setting // error: Reference to uninitialized setting
settings = Defaults.defaultSettings ++ Seq( settings = Defaults.defaultSettings ++ Seq(
libraryDependencies += "commons-io" % "commons-io" % "1.2" % "test", libraryDependencies += "commons-io" % "commons-io" % "1.2" % "test",
fullClasspath ~= (_.filterNot(_.data.name.contains("commons-io"))) fullClasspath := fullClasspath.value.filterNot(_.data.name.contains("commons-io"))
) )
Generally, all of the setting definition methods can be expressed in terms of
`:=`. To better understand the error, we can rewrite the setting as:
::
// error: Reference to uninitialized setting
fullClasspath := fullClasspath.value.filterNot(_.data.name.contains("commons-io"))
This setting varies between the test and compile scopes. The solution is This setting varies between the test and compile scopes. The solution is
use the scoped setting, both as the input to the initializer, and the use the scoped setting, both as the input to the initializer, and the
setting that we update. setting that we update.
@ -474,9 +472,6 @@ setting that we update.
fullClasspath in Compile := (fullClasspath in Compile).value.filterNot(_.data.name.contains("commons-io")) fullClasspath in Compile := (fullClasspath in Compile).value.filterNot(_.data.name.contains("commons-io"))
// or equivalently
fullClasspath in Compile ~= (_.filterNot(_.data.name.contains("commons-io")))
Dependency Management Dependency Management
--------------------- ---------------------