have a file external to build.sbt that makes per-machine build setting adaptations possible

[Simon Leischnig]

Adaptations have to be applied after everything in build.sbt is processed, don't forget default behavior if no such file is present.

[Simon Leischnig]

sbt.org/0.13/docs/Setting-Initialization.html

val localSbtFile = file("local.sbt")
lazy val rootSettingSets =
    Seq(sbt.AddSettings.allDefaults) ++ (
        if (localSbtFile.exists)
            Seq(sbt.AddSettings.sbtFiles(localSbtFile))
        else
            Seq.empty
    )

and then

lazy val opal = Project(
    id = "OPAL" [...]
)
.settingSets(rootSettingSets:_*)

see PR https://bitbucket.org/delors/opal/pull-requests/434

[Michael Eichberg]

interessting-why does it work? do we have to make changes to local.sbt? (aren‘t the settings just merged?)

[Simon Leischnig]

to answer your second question first: No changes to local.sbt are necessary -- if what follows makes any sense.

Why does it work, settings merging:

Settings get merged in any case, but I think it means "ordering the merged expressions somehow into the graph". The word "merge" just says "without any specific order". The expressions don't get changed but are immutable atoms in the sbt graph construction.

":=", "+=", "-=" and the like construct expressions and if they get ordered (by some mechanism we had not exerted control over nor is the order specified anywhere) it can be that you have "-=" and "+=" in a different order than we as the user want it. e.g. we specify "+= assertions" and "-= assertions", the ordering (among the fixed scalac default) specifies what will happen, not our specification. With the .settingSets arguments specifying the "local.sbt" expressions be applied last, ( http://www.scala-sbt.org/0.13/docs/index.html ), we have the control we need to for the local.sbt to have the "last word".

I have gotten good results on my machine where it achieved the desired behavior, whilst without it the local.sbt did not do what we intend. Since there are reported cases where the current local.sbt with "-= assertions" does indeed disable the assertions in scalac compilation, but in other environments it doesnt (e. g. on mine), I cannot yet be sure that it works. Just good reason to believe it as per the sbt article on settings initialization order.

One paragraph there was a bit disheartening though:

The order which sbt uses to load settings is configurable at a project level. 
This means that we can’t control the order of settings added to Build/Global 
namespace, but we can control how each project loads, e.g. plugins and .sbt files. [...]

This sounded like that the evaluation order of specifically ThisBuild setting expressions (like our assertions += and -=, they are in ThisBuild) could not be controlled via that method. My reasoning against that:

• Does sbt really set up a filter to fish out any specifically ThisBuild-scoped expressions or "specifically not order them the same way the other expressions are ordered"?
• Rather, this paragraph could mean that it is not possible to specify the order of expressions that origin from "everything but e.g. plugins and .sbt files" --> ThisBuild scoped setting reordering in "e.g. plugins and .sbt files" is doable and also all we need for this issue.
• experimentation on my machine changed the behavior from bad to good, the output of "> show scalacOptions" made sense for a variety of assignment/addition/substraction expressions.

[Michael Eichberg]

fixed by commit https://bitbucket.org/delors/opal/commits/aba864b1b81028fe5faff6f7335e2cd55bd16c51

[Michael Eichberg]

fixed by commit #aba864b1b81028fe5faff6f7335e2cd55bd16c51

[Michael Eichberg]

Removing version: 0.8.16 (automated comment)

[Simon Leischnig]

With sbt 1.0.x, the solution taken to this issue is not valid anymore. Plan: resolve this by using non-sbt text files for initialization

[Simon Leischnig]

See PR https://bitbucket.org/delors/opal/pull-requests/464

[Simon Leischnig]

Closed as per PR #464