Skip to content

Commit

Permalink
Merge pull request #1192 from eed3si9n/wip/dependency-tree
Browse files Browse the repository at this point in the history
Document dependencyTree
  • Loading branch information
eed3si9n authored Feb 20, 2024
2 parents a8f6749 + 75b0928 commit 7108487
Show file tree
Hide file tree
Showing 4 changed files with 84 additions and 0 deletions.
1 change: 1 addition & 0 deletions src/reference/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,7 @@
- [Working with an existing build](guide/running.md)
- [Build definition basics](guide/build-definition-basics.md)
- [Library dependency basics](guide/library-dependency-basics.md)
- [Multi project basics](guide/multi-project-basics.md)
- [Build layout](guide/build-layout.md)
- [sbt with IDEs](guide/IDE.md)
- [sbt Reference]()
Expand Down
24 changes: 24 additions & 0 deletions src/reference/guide/06-Task-Graph.md
Original file line number Diff line number Diff line change
Expand Up @@ -234,6 +234,30 @@ In this way, all build dependencies in sbt are *automatic* rather than
explicitly declared. If you use a key's value in another computation,
then the computation depends on that key.

#### Defining a task that depends on other keys

`scalacOptions` is a task key used for compiler options.
Here's an example of appending a compiler option based on the `version` setting.

```scala
name := "hello"
version := "0.1.0-SNAPSHOT"
Compile / scalacOptions += {
val v = version.value
s"-Dversion=$v"
}
```

Here's how it should look on the sbt shell:

```
sbt:bar> show Compile/scalacOptions
[info] * -Dversion=0.1.0-SNAPSHOT
```

This demonstrates that the right-hand side doesn't just take
hard-coded string values.

#### Defining a task that depends on other settings

`scalacOptions` is a task key.
Expand Down
23 changes: 23 additions & 0 deletions src/reference/guide/library-dependency-basics.md
Original file line number Diff line number Diff line change
Expand Up @@ -87,3 +87,26 @@ name := "something"
libraryDependencies += toolkit
libraryDependencies += toolkitTest % Test
```

Viewing library dependencies
----------------------------

Type in `Compile/dependencyTree` in the sbt shell to show the library dependency tree, including the transitive dependencies:

```
> Compile/dependencyTree
```

This should display something like the following:

```
sbt:bar> Compile/dependencyTree
[info] default:bar_3:0.1.0-SNAPSHOT
[info] +-org.scala-lang:scala3-library_3:3.3.1 [S]
[info] +-org.scala-lang:toolkit_3:0.2.0
[info] +-com.lihaoyi:os-lib_3:0.9.1
[info] | +-com.lihaoyi:geny_3:1.0.0
[info] | | +-org.scala-lang:scala3-library_3:3.1.3 (evicted by: 3.3.1)
[info] | | +-org.scala-lang:scala3-library_3:3.3.1 [S]
....
```
36 changes: 36 additions & 0 deletions src/reference/guide/multi-project-basics.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@

[Basic-Def]: Basic-Def.html
[Scopes]: Scopes.html
[Directories]: Directories.html
[Organizing-Build]: Organizing-Build.html

Multi project basics
====================

While a simple program can start out as a single-project build,
it's more common for a build to split into smaller, multiple subprojects.

Each subproject in a build has its own source directories, generates
its own JAR file when you run `packageBin`, and in general works like any
other project.

A project is defined by declaring a lazy val of type
[Project](../../api/sbt/Project.html). For example, :

```scala
scalaVersion := "{{scala3_example_version}}"

lazy val core = (project in file("core"))
.settings(
name := "core",
)

lazy val util = (project in file("util"))
.dependsOn(core)
.settings(
name := "util",
)
```

The name of the val is used as the subproject's ID, which
is used to refer to the subproject at the sbt shell.

0 comments on commit 7108487

Please sign in to comment.