Compilation procedure

[AndreVanDelft]

The README.md says for contributors:

Compilation procedure

In a correctly configured SubScript project (see Getting Started guide to see what it is), the following happens when you run sbt compile:

This should also state in what directory to run the command. When I do it in the subscript folder, I get

[info] Set current project to subscript (in build file:/Users/andrevandelft/Documents/workspaces/scala-subscript/subscript/) [success] Total time: 0 s, completed 30-jan-2016 0:09:29

So that does not do anything. In the framework folder, the command ends in error:

[info] Loading project definition from /Users/andrevandelft/Documents/workspaces/scala-subscript/subscript/framework/project [info] Updating {file:/Users/andrevandelft/Documents/workspaces/scala-subscript/subscript/framework/project/}framework-build... [info] Resolving org.fusesource.jansi#jansi;1.4 ... [info] Done updating. /Users/andrevandelft/Documents/workspaces/scala-subscript/subscript/framework/build.sbt:47: error: overloaded method value settings with alternatives: (ss: sbt.Def.Setting[]*)sbt.Project => Seq[sbt.Def.Setting[]] cannot be applied to (Seq[sbt.Def.Setting[]]) .settings(commonSettings) ^ /Users/andrevandelft/Documents/workspaces/scala-subscript/subscript/framework/build.sbt:73: error: overloaded method value settings with alternatives: (ss: sbt.Def.Setting[])sbt.Project => Seq[sbt.Def.Setting[]] cannot be applied to (Seq[sbt.Def.Setting[]]) .settings(commonSettings) ^ /Users/andrevandelft/Documents/workspaces/scala-subscript/subscript/framework/build.sbt:56: error: overloaded method value settings with alternatives: (ss: sbt.Def.Setting[])sbt.Project => Seq[sbt.Def.Setting[]] cannot be applied to (Seq[sbt.Def.Setting[_]]) .settings(commonSettings) ^ sbt.compiler.EvalException: Type error in expression at sbt.compiler.Eval.checkError(Eval.scala:384) at sbt.compiler.Eval.compileAndLoad(Eval.scala:183) at sbt.compiler.Eval.evalCommon(Eval.scala:152) ... at xsbt.boot.Boot$.main(Boot.scala:17) at xsbt.boot.Boot.main(Boot.scala) [error] sbt.compiler.EvalException: Type error in expression [error] Use 'last' for the full log. Project loading failed: (r)etry, (q)uit, (l)ast, or (i)gnore? q

[anatoliykmetyuk]

Compilation procedure is for projects that use SubScript. For the compilation and deployment of SubScript itself, see Development Procedure. But it wouldn't work for you anyway - seems you're using an old version of SBT that doesn't have the required API to process the build files correctly. I've updated the repo with the config files that enforce SBT 0.13.9, so you should do git pull and try to follow the Development Procedure.

[AndreVanDelft]

I am updating the compiler, but it does not seem be picked up by the eyetest compilation. The Ivy2 repository was cleaned: find ~/.ivy2/ -type d -name "*subscript*" -print0 | xargs -0 rm -rf (cd plugins/; sbt publish-local) published the new preprocessor:

published subscript-core_2.11 to 
    /Users/andrevandelft/.ivy2/local/org.subscript-lang/subscript-core_2.11/
          3.0.1-SNAPSHOT/poms/subscript-core_2.11.pom

(cd framework/; sbt publish-local) used that preprocessor well, and published the framework

But in eyetest, sbt clean compile appears to use the old preprocessor.

[anatoliykmetyuk]

Just change the version of SubScript in Eye Test to 3.0.1-SNAPSHOT. Search its build.sbt for this line: "org.subscript-lang" %% "subscript-swing" % "3.0.1" And also change the version in project/build.sbt of Eye Test.

[AndreVanDelft]

Thanks. Could you write this in the applicable README.md's? At least there should be some mentioning in https://github.com/scala-subscript/subscript.

[anatoliykmetyuk]

Ok, will address this tomorrow.

[AndreVanDelft]

Should the build.sbt's be in the .gitignore? Then that should also be documented. Just like the .idea files that need some clarification. You could mention that you can import the entire scala-subscript in one go into IntelliJ.

[anatoliykmetyuk]

No. Build.sbt files are the core of an SBT project. They specify the dependencies, particularly on SubScript libs. From them we apply the preprocessor. Scala version, project version, its name etc - all go here. SubScript projects won't run without build.sbt files.

IDE specific files, in contrast, can contain information about windows positions in the IDE, other IDE-specific metadata. They are not vital to the project.

[AndreVanDelft]

Are you absolutely sure? The presence of SNAPSHOT does not do harm to passers by who want to try out the project?

[anatoliykmetyuk]

Yes. SNAPSHOT is an intermediate version not meant for the public use, only for the development. Once no more issues left, we'll release 3.0.2, push it to Maven, and the examples will depend on it.

[AndreVanDelft]

The SNAPSHOT 'fix' is still not documented in the README.md...

[anatoliykmetyuk]

The SNAPSHOT is not a fix, this is how versioning works.

1. SubScript is versioned in semantic versioning style
2. All the examples depend on the latest release version
3. When you make some changes and want to test them without releasing, you append -SNAPSHOT to the SubScript version and publish it locally
4. Any project that you want to test with that version should have its subscript dependency prefixed with -SNAPSHOT too

So that's not really a fix, this is just a special case of versioning. You can make the project depend on the older 3.0.0 version of SubScript and it will be used. Or you can make it depend on your local 3.0.1-SNAPSHOT.

The end user doesn't need to know this unless they are a developer, since we should update our github example repos so that they depend on the latest release version all the time.

[AndreVanDelft]

Still, this need to be documented in the README.md, section "Getting Started for contributors". Will you do that?

[anatoliykmetyuk]

I have added the section to the readme. Is it ok? If so, can we close this issue?

[AndreVanDelft]

Ok, thanks. I'll correct a few 'bugs' of your English article usage :-)