cbt
cbt copied to clipboard
cvogt
Compile CBT itself with Scala Native
Porting CBT to Scala Native would potentially allow an entire tool chain independent of the JVM, including the build tool, which is a very important component of a tool chain. At the moment, Scala Native still needs the JVM, since it is built by SBT.
Update by @cvogt: @densh and I expect Scala Native support might make CBT's permanently running background process unnecessary and further reduce the 100-200ms runtime overhead.
current dependencies, that would need to be made optional or ported to Scala Native:
dependencies:
- scala.xml
- "org.eclipse.jgit", "org.eclipse.jgit", "4.2.0.201601211800-r" on OSX for native file change watching
- jna
from JDK io, nio, nio.charset, reflection, security, util.jar, net, util.concurrent.HashMap, javax.xml.bind.annotation.adapters.HexBinaryAdapter
for git, we may be able to just drop in the command line tool instead of jgit
FWIW, nio.Buffer & Co, and nio.charset.*, can be copy-pasted from Scala.js. There's nothing JS-specific in their implementation. There's also already a lot of the abstract and in-memory Streams and Reader/Writers of java.io.*.
https://facebook.github.io/watchman/docs/install.html may allow replacing barbary watch service by combining cbt with an external tool rather than letting it be aware of file watching see https://gitter.im/cvogt/cbt?at=579787637c9324e20effd586
Porting CBT to Scala Native would potentially allow an entire tool chain independent of the JVM, including the build tool, which is a very important component of a tool chain. At the moment, Scala Native still needs the JVM, since it is built by SBT.
Can scala native compile itself? Otherwise a tool chain independent of the JVM is long way away, I think.
@Jasper-M We can compile pretty much anything, but we can't always link what was compiled due to missing symbols in java.* namespace.
@densh so a native Scala Native compiler will (relatively) soon be possible?
@Jasper-M Yep, that's not a blocker. We've just merged initial File I/O (java.io.*) and there is ongoing effort to support java.nio.*and Zip/Jar I/O in the works.
Regarding scala-xml, it was somewhat recently ported to scala.js, so I imagine a native port wouldn't be difficult. But in order to get it in a release, it may be good to get things started sooner rather than later.
On the other hand, I don't know the progress of the dotty effort, but it sounds like XML string interpolation may be added as a library in favor of supporting XML literals (I don't know how much of an issue this is for CBT, and maybe the rest of Scala-XML will still be useful in CBT). If this library were possible to backport to Scala 2.11+ without much effort, that might be the more forward-facing route.
