Change cbt shell script to Scala script (bash and bat scripts)

[mchav]

http://stackoverflow.com/questions/6671913/scala-scripts-in-windows-batch-files http://alvinalexander.com/scala/scala-shell-script-example-exec-syntax

Step towards moving the code into the typed world and getting it to work with windows shell as well.

[cvogt]

be aware that some of the code in the cbt shell script needs to run before bootstrap_scala even downloaded scala jars. And other stuff needs to be fast. Starting up a fresh JVM and classloading the scala jars is probably slower than bash. Speed matters for the script because it is paid on every single run.

[hntd187]

@cvogt I'm trying right now to write an equivalent batch script to do what the cbt shell script does, but suffice to say batch script does not have features like bash does. I think it might be wise to for general purpose builds have a general purpose wrapper like what gradle does and then if you want to eat your own dog food on linux/osx you can, but windows support for everything it does in just batch scripts seems like it would be a trial.

[cvogt]

@hntd187 we can easily start with a batch script that does less, even not run via nailgun and then step-wise improve from there. I'd be also happy if the bash code logic moved into a portable, ideally type-checked format. What's the wrapper in gradle, can you point to it?

[hntd187]

@cvogt it's pretty much what your shell script, scala_bootstrap and some other tools are doing right now. Basically the idea is that when you generate the project you generate a wrapper with it, and the wrapper is basically a jar that handles all the delegation to an installation of the build tool. That way people can build on the same version of you and not worry about having the same version so on and so forth, they basically just check it out and run that wrapper and it's good to go. And since the wrapper is just a pure java jar you can change versions and it's quick to download and use. The wrapper keeps compiled distros of the build tool on the local machine too so you don't have to download it every time, but it also makes upgrading a painless process and the idea behind this was so that the shell script could be massively simplified, windows batch support would be a breeze too and if you dont' necessarily want a compiler that recompiles itself you can use cbt without having to compile it yourself. You can just jump into using it.

I also think it's worth us including a distro of nailgun with cbt, so we can control a bit more about how it's built and it's pathing. but let's work on this idea first.

https://docs.gradle.org/current/userguide/gradle_wrapper.html https://github.com/gradle/gradle/tree/master/subprojects/wrapper

[hntd187]

@cvogt my idea for this was basically to port over a lot of this pretty simple java to scala and create cbt inside hopefully just a distributable jar, does this all sound like a good idea to you?

[cvogt]

@hntd187 I think several of us at NEScala wanted to explore distribution as source first, before considering distributing binaries. Source had a lot of advantages like easy contribution, no need to publish binaries, etc.

However I could see replacing the cbt shell script with a tiny one, that only compiles a java file and runs it as long as the runtime (excluding compile time) is not slower than the shell script right now, which is actually possible. In my tests pure JVM startup was about 0.1 second on my machine if I am not mistaken.

[cvogt]

(I might have misunderstood what your plan with the wrapper is tough. If you put a quick mock implementation together, that may make it clearer)

[hntd187]

@cvogt No I think your understanding of it is fine I'm gonna just bite the bullet and do a Windows batch script and we can look into the wrapper for later functionality I already have a good bit of it worked out so I think I can have it wrapped up soon.

[cvogt]

@hntd187 Or you try to implement the same logic in Java and use this on windows and see how it performs :). With a conditional re-compile step like the cbt script does in several places

[hntd187]

@cvogt Doesn't writing java kind of defeat the purpose of this whole thing? :-p

[cvogt]

You mean because of Scala or because of nailgun :)? Would be just for the launcher obviously.

[hntd187]

@cvogt I meant for the shell scripts, but sometimes you gotta do what you gotta do. I'll at least get a windows batch script going so I can actually compile things on windows, right now I can't even get cbt going until I get my linux machine from work on Monday.

[hntd187]

@cvogt bringing this back up, you had mentioned you were implementing some new features and to hold off a bit on the refactoring of that shell script. Are you at a point where I can mess with it again? Also, since bash is coming to windows we could ignore writing a .bat file yay!

[cvogt]

Bash is coming to windows. 10 years ago that would have been a good joke ;). All changes I intended to do to the launching part are in this PR https://github.com/cvogt/cbt/pull/87, which I intend to merge in one of the next few days once two remaining smaller issues are out. If you base your refactorings on that branch, you should be good. As you can see bootstrap_scala is gone there for a more elaborate downloading process in the launcher, which also allows to get zinc early, etc. And stage1 is compile from within Java land.

[mchav]

Wrote a batch version of the batch script and it works without realpath. Quite usable till July.

https://gist.github.com/ChavXO/92c293f72da67c5a79a56e958d43c494