I'm working with a huge project with lots of subprojects, some of them with subprojects of their own. On top of that, I'd like some of them to be dynamic - given a List somewhere in the project build, I'd like to create one project for each of the elements.
For those reasons, having to define a lazy val for each project in build.sbt is very cumbersome. Is there other way to declare projects, like a addProject-like method we could call anywhere? Is there some SBT plugin that helps with that?
Sbt uses macros to turns top level vals into projects, so I don't think you will be able to escape that part. However, you can define all you build in Project => Project functions: (note that you also composability "for free" with function composition)
def myConf: Project => Project =
_.enablePlugins(ScalaJSPlugin)
.settings(scalaVersion := "2.12.0")
Then simply use project.configure(myConf) for single line project definitions:
lazy val subProject1 = project.configure(myConf)
lazy val subProject2 = project.configure(myConf)
lazy val subProject3 = project.configure(myConf)
lazy val subProject4 = project.configure(myConf)
...
Related
In my build.sbt (nothing fancy) ....
val common: Project =
project
.in(file("common"))
.enablePlugins(...)
.settings(libraryDependencies ++= ...)
val root =
project
.in(file("."))
.enablePlugins(...)
.dependsOn(common)
.aggregate(
common,
....
)
.settings(...)
Problem
common does not compile before root, and so the compilation fails complaining that it cannot find those classes (in common)
FYI
I have tried a multitude of things that I came across when searching some information on this problem (google, documentation, github issues etc.) No luck.
sbt v1.4.9 (Play project sbt-play v2.7.9)
The build.sbt is much bigger than what you see above (dependencies, tasks etc.). Otherwise, I don't think if there's anything special or tricky about it.
Help much appreciated!
To avoid initialisation problems try declaring projects as lazy vals
lazy val common = ...
lazy val root = ...
instead of strict vals
val common = ...
val root = ...
As a side note use dependsOn to establish ordering between subprojects, and not aggregate, because aggregate will not modify classpaths.
I'd agree with Mario Galic on using lazy val. In fact, I'd recommend using lazy val at all times in build.sbt.
If there is a cycle, like common referring back to root, one technique you can use is to use LocalProject("project name"), like LocalProject("root"):
lazy val common = (project in file("common"))
.settings(
Test / test := (LocalProject("root") / Test / test).value
)
I have a bunch of SBT 0.13 project definitions that look like this:
lazy val coreBase = crossProject.crossType(CrossType.Pure).in(file("core"))
.settings(...)
.jvmConfigure(_.copy(id = "core"))
.jsConfigure(_.copy(id = "coreJS"))
lazy val core = coreBase.jvm
lazy val coreJS = coreBase.js
(Mostly because I'm resentful about having to maintain Scala.js builds and don't want to have to type the JVM suffix every time I'm changing projects, etc.)
This doesn't compile in SBT 1.0 because Project doesn't have a copy method now.
Okay, let's check the migration guide.
Many of the case classes are replaced with pseudo case classes generated using Contraband. Migrate .copy(foo = xxx) to withFoo(xxx).
Cool, let's try it.
build.sbt:100: error: value withId is not a member of sbt.Project
.jvmConfigure(_.withId("core"))
^
So I asked on Gitter and got crickets.
The links for the 1.0 API docs actually point to something now, which is nice, but they're not very helpful in this case, and trying to read the SBT source gives me a headache. I'm not in a rush to update to 1.0, but I'm going to have to at some point, I guess, and maybe some helpful person will have answered this by then.
(This answer has been edited with information about sbt 1.1.0+ and sbt-crossproject 0.3.1+, which significantly simplify the whole thing.)
With sbt 1.1.0 and later, you can use .withId("core"). But there's better with sbt-crossproject 0.3.1+, see below.
I don't know about changing the ID of a Project, but here is also a completely different way to solve your original issue, i.e., have core/coreJS instead of coreJVM/coreJS. The idea is to customize crossProject to use the IDs you want to begin with.
First, you'll need to use sbt-crossproject. It is the new "standard" for compilation across several platforms, co-designed by #densh from Scala Native and myself (from Scala.js). Scala.js 1.x will allways use sbt-crossproject, but it is also possible to use sbt-crossproject with Scala.js 0.6.x. For that, follow the instructions in the readme. In particular, don't forget the "shadowing" part:
// Shadow sbt-scalajs' crossProject and CrossType from Scala.js 0.6.x
import sbtcrossproject.{crossProject, CrossType}
sbt-crossproject is more flexible than Scala.js' hard-coded crossProject. This means you can customize it more easily. In particular, it has a generic notion of Platform, defining how any given platform behaves.
For a cross JVM/JS project, the new-style crossProject invocation would be
lazy val coreBase = crossProject(JVMPlatform, JSPlatform)
.crossType(CrossType.Pure)
.in(file("core"))
.settings(...)
.jvmConfigure(_.copy(id = "core"))
.jsConfigure(_.copy(id = "coreJS"))
lazy val core = coreBase.jvm
lazy val coreJS = coreBase.js
Starting with sbt-crossproject 0.3.1, you can simply tell it not to add the platform suffix for one of your platforms. In your case, you want to avoid the suffix for the JVM platform, so you would write:
lazy val coreBase = crossProject(JVMPlatform, JSPlatform)
.withoutSuffixFor(JVMPlatform)
.crossType(CrossType.Pure)
...
lazy val core = coreBase.jvm
lazy val coreJS = coreBase.js
and that's all you need to do!
Old answer, applicable to sbt-crossproject 0.3.0 and before
JVMPlatform and JSPlatform are not an ADT; they are designed in an OO style. This means you can create your own. In particular, you can create your own JVMPlatformNoSuffix that would do the same as JVMPlatform but without adding a suffix to the project ID:
import sbt._
import sbtcrossproject._
case object JVMPlatformNoSuffix extends Platform {
def identifier: String = "jvm"
def sbtSuffix: String = "" // <-- here is the magical empty string
def enable(project: Project): Project = project
val crossBinary: CrossVersion = CrossVersion.binary
val crossFull: CrossVersion = CrossVersion.full
}
Now that's not quite enough yet, because .jvmSettings(...) and friends are defined to act on a JVMPlatform, not on any other Platform such as JVMPlatformNoSuffix. You'll therefore have to redefine that as well:
implicit def JVMNoSuffixCrossProjectBuilderOps(
builder: CrossProject.Builder): JVMNoSuffixCrossProjectOps =
new JVMNoSuffixCrossProjectOps(builder)
implicit class JVMNoSuffixCrossProjectOps(project: CrossProject) {
def jvm: Project = project.projects(JVMPlatformNoSuffix)
def jvmSettings(ss: Def.SettingsDefinition*): CrossProject =
jvmConfigure(_.settings(ss: _*))
def jvmConfigure(transformer: Project => Project): CrossProject =
project.configurePlatform(JVMPlatformNoSuffix)(transformer)
}
Once you have all of that in your build (hidden away in a project/JVMPlatformNoSuffix.scala in order not to pollute the .sbt file), you can define the above cross-project as:
lazy val coreBase = crossProject(JVMPlatformNoSuffix, JSPlatform)
.crossType(CrossType.Pure)
.in(file("core"))
.settings(...)
lazy val core = coreBase.jvm
lazy val coreJS = coreBase.js
without any need to explicitly patch the project IDs.
I am trying to accomplish something like this:
lazy val customFlag = settingKey[Boolean]("My custom flag")
lazy val depOne = project ...
lazy val depTwo = project ...
lazy val myproject = project
.settings(
customFlag := false)
.dependsOn(if (customFlag) depOne else depTwo)
The idea being, that I could then use set customFlag := true in the sbt console in order to change whether project myproject depends on sub-project one or two.
I have a hunch at this point that the answer is that this is not possible. But it would be nice to get confirmation or an alternative to accomplish something similar.
No. It's not possible to use setting key in the dependsOn.
I have a bunch of sub-project that I define as follows (actually generated by a project/meta.sbt):
lazy val Top = (project in file("."))
.aggregate(common, p1, p2, tests, scripts)
.dependsOn(common, p1, p2, tests, scripts)
lazy val common = project
lazy val p1 = project.dependsOn(common % "compile->compile;test->test")
lazy val p2 = project.dependsOn(common % "compile->compile;test->test")
lazy val tests = project.dependsOn(common % "compile->compile;test->test")
lazy val scripts = project
AFAICT (so maybe that's wrong), both the aggregate and the dependsOn at the top make sense: the first to run tasks in all sub-projects, and the second to make it convenient to debug stuff.
Now, the thing is that tests contains just a bunch of tests, and scripts is a script that is used as a publishing step -- so I need to somehow make it avoid making jar files only for them. I still want compile/test/etc to be aggregated including them.
My understanding from the docs is that this should be done by setting the aggregate key in Top, and indeed adding something like
.settings(aggregate in clean:= false)
prevents clean from being aggregated -- but I want to do that for package and I don't want to drop it completely, just not package those two sub-projects. Using something like aggregate in (tests, packageBin) is my best guess, but that doesn't seem to make an impression on SBT: looks like packageBin is wrong, and also combining it with tests doesn't work.
Is that possible? Actually, given that SBT is just a tiny bit overengineered, it's always possible, so rephrase: How can I do that?
Update:
Thanks to this answer I found a workaround -- add:
.settings(Keys.`package` := file(""))
to the definitions of subprojects that shouldn't be packaged. That works for avoiding generation of jar files, but it's obviously not an answer for the actual question (which I'm probably going to run into again).
I am building compound API docs using the sbt-unidoc plugin. I am linking to various projects on GitHub using sbt's RootProject constructor with URIs.
One of these projects has mutually exclusive sub-projects:
val foo = RootProject(uri("git://github.com/Foo/Bar.git#v1.0.0"))
That is, in this project foo, there are two sub-modules foo-db1 and foo-db2, which contain the same types but are built against different dependency library versions.
Now when I try to run unidoc, it fails because a type is defined twice from unidoc's perspective. From the documentation, I can see there is a filter function:
unidocProjectFilter in (ScalaUnidoc, unidoc) := inAnyProject -- inProjects(app)
But how do I create an identifier for a sub-module from my RootProject?
In other words, how would I do this:
unidocProjectFilter in (ScalaUnidoc, unidoc) := inAnyProject --
inProjects(foo).SELECT_SUB_PROJECT(foo-v1)
?
The answer is found in this entry: Instead of using RootProject, one creates a number of ProjectRef instances.
import UnidocKeys._
val fooURI = uri("git://github.com/Foo/Bar.git#v1.0.0")
val fooDb1 = ProjectRef(fooURI, "foo-db1") // sub-module I don't want
val fooDb2 = ProjectRef(fooURI, "foo-db2") // sub-module I want
val root = (project in file("."))
.settings( ... )
.settings(unidocSettings: _*)
.settings(site.settings ++ ghpages.settings: _*)
.settings(
unidocProjectFilter in (ScalaUnidoc, unidoc) :=
inAnyProject -- inProjects(fooDb1)
)
.aggregate(fooDb2)
Note that putting only fooDb2 in the aggregate and leaving fooDb1 out, does not have any effect. It seems that unidoc always includes all sub-modules, no matter, so one has to use the unidocProjectFilter to explicitly remove projects, even if they don't appear in the aggregate.