If I define an SBT config with
val MyConfig = config(\"my\") extend Test
is that basically the same as doing
val MyConfig = config(\"m
No, calling extend
method is not the same thing as calling inConfig
. extend
just returns a new configuration with passed in configurations prepended extendsConfigs
, and it will not introduce any new settings.
When you add MyConfig
into the project, it becomes part of the scoped key resolution path:
val MyConfig = config("my") extend Test
val root = (project in file(".")).
configs(MyConfig)
Suppose you type my:test
in the sbt shell. Since test
task is not found under my
configuration, it will traverse extendsConfigs
and check if the tasks are available under them. The first one it's going to hit is Test
since we prepended it. You can check this by running inspect my:test
:
root> inspect my:test
[info] Task: Unit
[info] Description:
[info] Executes all tests.
[info] Provided by:
[info] {file:/Users/eugene/work/quick-test/sbt-so/}root/test:test
[info] Defined at:
[info] (sbt.Defaults) Defaults.scala:365
[info] Delegates:
[info] my:test
[info] test:test
[info] runtime:test
[info] compile:test
[info] *:test
[info] {.}/my:test
[info] {.}/test:test
[info] {.}/runtime:test
[info] {.}/compile:test
[info] {.}/*:test
[info] */my:test
[info] */test:test
[info] */runtime:test
[info] */compile:test
[info] */*:test
[info] Related:
[info] test:test
"Provided by" says it delegated to root/test:test
. This mechanism allows you to share some of the settings but override others, but you still have to know the inner wiring of the settings scoped to tasks etc, so it's tricky business. You probably already know, but I'll link to Additional test configurations, which specifically discusses configurations for testing.