scalacOptions do not follow the delegation rules about sbt HOT 6 CLOSED

It seems we did not set scalacOptions for X.

sbt's default compile task is implemented by JvmPlugin, and unfortunately I think it needs to inject scalacOptions at the subproject level for various reasons, for example

Test / scalacOptions as the first one, and we also see Zero / Test / scalacOptions. Aren't they are the same scope?

I think the first one means ProjectRef(uri("file:/Users/liufengyun/Documents/sbt-bug/"), "X") / Test / scalacOptions, but we omit the subproject part when we display it.

from sbt.

Hi @liufengyun!

Your example is probably hitting Rule 1 - https://www.scala-sbt.org/1.x/docs/Scope-Delegation.html#Rule+1%3A+Scope+axis+precedence

Rule 1: Scope axes have the following precedence: the subproject axis, the configuration axis, and then the task axis.

Anything on subproject Zero would be ignored for scalacOptions because there's an existing value in the subproject X. I plan to change the semantic of the bare settings in sbt 2.x to address this issue - dbaa34b

from sbt.

Thank you for the quick response @eed3si9n .

there's an existing value in the subproject X

Could you elaborate more about it? It seems we did not set scalacOptions for X. In particular, I would expect scalacOptions and foo to behave the same.

When I inspect the delegates precedence, it lists Test / scalacOptions as the first one, and we also see Zero / Test / scalacOptions. Aren't they are the same scope?

sbt:X> inspect X / Test / scalacOptions
[info] Task: scala.collection.Seq[java.lang.String]
[info] Description:
[info] 	Options for the Scala compiler.
[info] Provided by:
[info] 	ProjectRef(uri("file:/Users/liufengyun/Documents/sbt-bug/"), "X") / Test / scalacOptions
[info] Defined at:
[info] 	(sbt.Defaults.configTasks) Defaults.scala:975
[info] 	(sbt.Defaults.configTasks) Defaults.scala:982
[info] 	(sbt.Classpaths.compilerPluginConfig) Defaults.scala:4205
[info] 	(sbt.plugins.SemanticdbPlugin.configurationSettings) SemanticdbPlugin.scala:72
[info] 	(sbt.plugins.SemanticdbPlugin.configurationSettings) SemanticdbPlugin.scala:80
[info] Dependencies:
[info] 	Test / settingsData
[info] 	Test / semanticdbEnabled
[info] 	Test / configuration
[info] 	Test / autoCompilerPlugins
[info] 	Test / scalacOptions / streams
[info] 	Test / fileConverter
[info] 	Test / buildDependencies
[info] 	Test / exportPipelining
[info] 	Test / scalaVersion
[info] 	Test / thisProjectRef
[info] 	Test / earlyOutput
[info] 	Test / sbtPlugin
[info] 	Test / update
[info] 	Test / semanticdbOptions
[info] Reverse dependencies:
[info] 	Test / bspBuildTargetScalacOptionsItem
[info] 	printTask
[info] Delegates:
[info] 	Test / scalacOptions
[info] 	Runtime / scalacOptions
[info] 	Compile / scalacOptions
[info] 	scalacOptions
[info] 	ThisBuild / Test / scalacOptions
[info] 	ThisBuild / Runtime / scalacOptions
[info] 	ThisBuild / Compile / scalacOptions
[info] 	ThisBuild / scalacOptions
[info] 	Zero / Test / scalacOptions
[info] 	Zero / Runtime / scalacOptions
[info] 	Zero / Compile / scalacOptions
[info] 	Global / scalacOptions
[info] Related:
[info] 	Zero / Test / scalacOptions
[info] 	Test / doc / scalacOptions
[info] 	Compile / scalacOptions
[info] 	Global / scalacOptions
[info] 	Compile / doc / scalacOptions

from sbt.

Thank you for the explanation @eed3si9n !

Now I see the resolution rules are observed. For end users, the rules are seemingly violated due to the implicit injections.

It would be nice to have an injection mechanism that can avoid such surprises. It will be more natural to users if the injection only intercepts and transforms the resolution result in a reasonable way --- such that the resolution rules would "seem" to be effective in spite of the injection.

I see it's a complicated design problem, it's already beyond the reach of most build tools.

from sbt.

Yea with dbaa34b (https://eed3si9n.com/simplifying-sbt-with-common-settings/),

scalacOptions := scalacOptions.value.filter(_ != "-Ysafe-init-global")

would be injected into all subprojects in sbt 2.x.

from sbt.

https://eed3si9n.com/simplifying-sbt-with-common-settings/

That sounds like a very good design --- it solves both simple and complex problems with low cognitive load. Yet it's still easy to explain to experts simply by saying they are "automatic subproject-level settings".

One minor detail: I guess users can still specify the axis of the common settings, right? That would make advanced use cases possible.

from sbt.