A relaxed chat room about sbt (the interactive build tool). Also good for sbt help: Stack Overflow, or Lightbend subscription. https://www.scala-sbt.org/support.html has advice on where to go.
ah, here it is: sbt/sbt#2943
I'm setting the
scalacOptions in the globalSettings of an autoPlugin. Order matters for other thing messing with scalacOptions, right?
I believe SBT is setting scalacOptions for both the
Compile and Test configurations at the project level.
I'm guessing SBT is doing this after my globalSettings, because my options are being picked up.
and also make sure you have
override def requires = plugins.JvmPlugin
so your stuff comes after sbt's default settings (which themselves are also auto plugins)
I think I'm getting away with this because I'm not specifying the requirement of the JvmPlugin, and it's running after me, and not before.
which I'm inclined to correct if that's the case.
if the auto plugin doesn't declare dependency it would be placed randomly
and it should go at the project-level
so doing anything at the buildSettings or globalSettings won't work
I'm going to try to figure out how/why.
but somehow my global settings of scalacOptions are making their way all the way up to project/compile:compile::scalacOptions
I'm close to saying "it works, forget about it." but I'll hunt further if anyone has ideas. Once bitten by curiosity, I like to see these things through.
is there a way to get the cross-module dependencies in a multiproject? e.g. for something like
val foo = project.in(file(...)).dependsOn(bar, quux), i am trying to write a Task that when in foo gives bar and quux. i've chased it down to using the thisProject key which gives me http://www.scala-sbt.org/0.13.15/api/index.html#sbt.ResolvedProject on which i can call dependencies but the information given in a ProjectRef is not enough to reconstruct the actual sbt project ref
i think
no i didnt i lied
@eed3si9n ah ok so maybe i just need to be able to get a list of all projects in the build - do I still need to use BuildStructure to get that information?
i'm basically trying to find the transitive closure of source dependencies using sbt-dependency-graph. i have the graph for a given project, now i just need to prune out the source dependencies which i can do if i have all projects in the build by just filtering
i have to go soon, but you could try hacking around basedon this imple - https://github.com/sbt/sbt/issues/3030#issuecomment-295828118
will take a look, thanks!
Okay, I'm back home again, and thinking of this puzzle one last time. Here's where I'm confused. the JvmPlugin according to "sbt -debug" is running before my plugins, and according to the source, it appears to be setting project/compile:scalacOptions and project/test:scalacOptions. Then my plugins after the fact set project/*:scalacOptions, which has a lower precedence in the delegation chain. Why aren't these settings lost?
Yeah, someone pointed me to this earlier, and I think upon a second read, it answers my question: http://www.scala-sbt.org/0.13/docs/Scope-Delegation.html
I think I've been hobbling with a really messed up denotation of how the DSL works. I assumed order dependence of settings, but there's only order dependence when there's no delegation (the "old" value is lexically earlier on the page or from a previous plugin). When there's delegation, the order of the settings doesn't matter. Something delegated to can be defined later lexically, or by a downstream plugin.
