Module-level build settings #18
Comments
|
I just hit this. I need custom scalaOptions, because scalajs wants me to add the equivalent of (in sbt) |
|
Thanks. Good to know there is a valid use case for this. |
|
I feel like having a go at this! |
|
Perfect. It is all yours. While working on #29, I realised we should copy the project/module settings also to the platform-specific modules. So as part of loading the build file, this module: [module.macros]
targets = ["jvm", "js"]
compilerDeps = [["org.scalamacros", "paradise", "2.1.1", "full"]]would get translated to: [module.macros.jvm]
compilerDeps = [["org.scalamacros", "paradise", "2.1.1", "full"]]
[module.macros.js]
compilerDeps = [["org.scalamacros", "paradise", "2.1.1", "full"]]The upside is that it would simplify the generation logic because we will only have to check one module (and its dependencies). |
|
@megri Have you already started working on this issue? If not, I could take it over and implement the changes next week. |
Centralise the logic for inheriting settings defined on the project level or on base modules. Inheritance is now performed during loading of build files. As a consequence, many functions do not need to be aware of the project or the parent module anymore which greatly simplifies the code for generating Bloop and IDEA configurations. Also, several missing fields which were only available on the project-level were added to `Module`. Closes #18.
|
@tindzk Oh sorry, I totally missed the notification on this. I started experimenting but didn't get too far, and then day job came between. Great to see progress :) |
Centralise the logic for inheriting settings from the project section and base modules. The inheritance step is now performed when build files are loaded. As a consequence, many functions do not need to take a reference to the project definition or parent modules anymore. This greatly simplifies the code for generating Bloop/IDEA configurations, and makes the logic less error-prone. The build's project section is now entirely optional and its fields can be set on modules instead. Now, Scala options can be extended in platform modules, for example to set additional flags required by the Scala.js compiler such as `-P:scalajs:sjsDefinedByDefault`. Furthermore, every module is compiled with the Scala version and the options it was defined with. Therefore, it is not possible to depend on modules which have an incompatible Scala version. For example, including a 2.12 module in a 2.13 module will trigger an error. Closes #18.
Centralise the logic for inheriting settings from the project section and base modules. The inheritance step is now performed when loading the build file. As a consequence, many functions do not need to take a reference to the project definition or parent modules anymore. This greatly simplifies the code for generating Bloop/IDEA configurations, and makes the logic less error-prone. The build file's project section is now entirely optional and its values can be set on modules instead. Now, Scala options can be extended in platform modules, for example to set additional flags required by the Scala.js compiler such as `-P:scalajs:sjsDefinedByDefault`. Furthermore, every module is compiled with the Scala version and the options it was defined with. Therefore, it is not possible to depend on modules anymore which have an incompatible Scala version. For example, including a 2.12 module in a 2.13 module will trigger an error. Closes #18.
Various build settings such as the resolvers, compiler versions (Scala, Scala.js, Scala Native), compiler flags and test frameworks are defined only on the project level.
seed.model.ModuletooparseBuildTomlshould returnEither[Codec.Error, Map[String, Build.Module]]seed.model.BuildSee also #15 (comment).
The text was updated successfully, but these errors were encountered: