So a few things noticed. First the kodestudio thing, other than being amazingly slow and memory heavy for a text editor, outputs some *.cbp project file for building, and I know of not a single tool that can build that on the command line. It also outputs an odd android setup that seemingly has no way to compile to an apk:

build/android:

build/android-build:
korefile.js  Sources

build/android-resources:
files.json                 painter-colored.vert.essl  painter-image.vert.essl  painter-text.vert.essl   painter-video.vert.essl
painter-colored.frag.essl  painter-image.frag.essl    painter-text.frag.essl   painter-video.frag.essl

and it seems to have no cross-compiler from linux->windows. This makes it exceedingly difficult to add to a X-less build system (especially as the cbp file crap requires codeblocks, which is also a horrible ide, and requires an X server even if the system, such as a build server, has no such thing).

As a comparison compiling and spitting out an end product (apk, binary, exe, whatever) is but a single command each from a raw git checkout in haxeflixel. Why is the build system here endlessly convoluted with entirely non-standard cbp and whatever things and no android build system to speak of at all?

Oh, because I like it that way.

@Robert said:

Oh, because I like it that way.

Cool, so 'how' do I compile on the build server then?

node /path/to/Kha/make --compile

@Robert said:

node /path/to/Kha/make --compile

undefined:3
let project = new Project('New Project');
^^^

SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode
    at Function (native)
    at module.exports (/usr/share/haxe/kha/16,1,2/Tools/khamake/ProjectFile.js:10:16)
    at exportKhaProject (/usr/share/haxe/kha/16,1,2/Tools/khamake/main.js:344:13)
    at exportProject (/usr/share/haxe/kha/16,1,2/Tools/khamake/main.js:451:3)
    at Object.exports.run.callback [as run] (/usr/share/haxe/kha/16,1,2/Tools/khamake/main.js:539:2)
    at Object.<anonymous> (/usr/share/haxe/kha/16,1,2/Tools/khamake/khamake.js:376:23)
    at Module._compile (module.js:434:26)
    at Object.Module._extensions..js (module.js:452:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)

Build server throws this with an otherwise 'new' project that just draws a triangle. I'm used to dealing with the build systems of C++ (make/cmake), elixir (mix), java (sbt/gradle/maven), and a couple minor others, but that does not include node's in any form (I try to avoid javascript...) so this is a bit unusual, especially as I've not seen anything node related to haxe projects in any other form (I try to minimize dependencies, and node was an awfully huge dependency to add to the build server docker image)...

For note:

$ node -v
v4.2.6

EDIT1: Also, the build server base docker image was upgraded to ubuntu/16.04.

EDIT2: And this when I add "use strict"; to the top of the khafile.js oddity:

Creating Kha project.
undefined:10
resolve(project);
^

ReferenceError: resolve is not defined
    at eval (eval at <anonymous> (/usr/share/haxe/kha/16,1,2/Tools/khamake/ProjectFile.js:10:16), <anonymous>:14:1)
    at module.exports (/usr/share/haxe/kha/16,1,2/Tools/khamake/ProjectFile.js:10:47)
    at exportKhaProject (/usr/share/haxe/kha/16,1,2/Tools/khamake/main.js:344:13)
    at exportProject (/usr/share/haxe/kha/16,1,2/Tools/khamake/main.js:451:3)
    at Object.exports.run.callback [as run] (/usr/share/haxe/kha/16,1,2/Tools/khamake/main.js:539:2)
    at Object.<anonymous> (/usr/share/haxe/kha/16,1,2/Tools/khamake/khamake.js:376:23)
    at Module._compile (module.js:434:26)
    at Object.Module._extensions..js (module.js:452:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)

EDIT3: The git master is doing:

$ node ../Kha/make --compile
Requires Node.js version 6 or higher.

Which is interesting because the Getting Started page says node v4 or higher, and this is the version that was in the repo...

EDIT4: As per the above linked Getting Started page I ran:

sudo npm cache clean -f
node --version
sudo npm install -g n
sudo npm stable
node --version

And it reports version:

v4.2.6

EDIT5: Also, I have to ask, node? Really? Isn't the node packaging system one of the absolutely horrible ones out there? That people can remove code from and more? I far more prefer the hex packaging system (Elixir/Erlang), or the cargo packaging system (Rust), you have 10 minutes to undo an upload then it is permanent and immutable, as it should be. Node.js is a highly questionable system to base anything on...

Uh, Android target spits out gradle files - you can build and deploy apk using those with a single command.

Thanks, I updated the Getting Started page, the switch to Node.js 6 just happened this week.
If you want to discuss any of Kha's tech details, you'll have to be less rude about it. I'm sorry but I can't take your style of writing seriously.

@Robert said:

Thanks, I updated the Getting Started page, the switch to Node.js 6 just happened this week.
If you want to discuss any of Kha's tech details, you'll have to be less rude about it. I'm sorry but I can't take your style of writing seriously.

I'm sorry about that, was quite sick yesterday and not normally like that, got frustrated after not being able to find build instructions. So essentially it is not going to be able to be used on build server docker images, especially with node 6 without manually building one. I would recommend getting rid of node, that is definitely a rather odd choice for a build system...

ok then, two things about Node.js...
We don't use npm aka Node's packaging system, so those problems do not apply (and by the way, Kha mostly avoids haxelib because it suffers from the same problems - I recently wrote a blog post about it at http://kode.tech/dependencies-and-robustness).
There is no need to install Node.js. You can just grab an archive at https://nodejs.org/en/download/current/ and fetch the node binary inside, put it wherever and call that one instead of a global node installation. That is actually one of the features which convinced me it's a good choice for a build system (the others are high execution speed and easy integration with vscode). Have a look at Kha's .travis.yml file for an example of how to handle Node on a build server.

We don't use npm aka Node's packaging system, so those problems do not apply (and by the way, Kha mostly avoids haxelib because it suffers from the same problems - I recently wrote a blog post about it at http://kode.tech/dependencies-and-robustness).

Fascinating, I wonder why the haxelib system is not immutable either, immutability is highly important with package storage. Definitely agree with your blog post, same thing that I've been mentioning for years. That is one of the reasons that Rust has grabbed my attention as of late, getting surprised by dependency changes is... infuriating at time, and rusts build system (cargo) is immutable, as is Elixir's (Hex), which is a VM that I've been using for over a decade (via Erlang). I tend to hold those two as prime examples of immutable packaging systems.

There is no need to install Node.js. You can just grab an archive at https://nodejs.org/en/download/current/ and fetch the node binary inside, put it wherever and call that one instead of a global node installation. That is actually one of the features which convinced me it's a good choice for a build system (the others are high execution speed and easy integration with vscode). Have a look at Kha's .travis.yml file for an example of how to handle Node on a build server.

Thanks much for the references. All my past experiences with node involved needing to install very large packages, interesting to see that it can be slimmed down. I was curious as to the choice of build system, I looked back a bit in the project history and noticed the javascript build system tended to be more serialized and now it is more declarative (any build system worth anything is declarative in my opinion as well, and I can go on a long rant as to why, so that was nice to see).

And for some reason I always neglect to look at the .travis.yml file, I know it details a lot but I just never think of it due to it being invisible and not on my mind.... >.>

The primary reason for the relatively complex build system is the cross-platform support for assets and shaders and shuffling stuff around for more obscure targets (like for example the Unity target). You can get away without that when you only target OpenGL/GLSL (not very portable) and just load pngs and jpegs (not very fast) but that's just not what Kha is about.
So Kha is indeed very non-standard in how it works. But there are reasons for it.
The build system was originally a C++ thing but I got bored of continually compiling a piece of software that doesn't need any low level optimizations, so I looked for a VM that is fast and easy to handle. Neko isn't fast. Java or Mono are not easy to handle (can't distribute them as one file AFAIK).
So, sorry for the troubles. I do take note of such things though to figure out how to make it less troublesome in the future.

@Robert said:

The primary reason for the relatively complex build system is the cross-platform support for assets and shaders and shuffling stuff around for more obscure targets (like for example the Unity target). You can get away without that when you only target OpenGL/GLSL (not very portable) and just load pngs and jpegs (not very fast) but that's just not what Kha is about.
So Kha is indeed very non-standard in how it works. But there are reasons for it.
The build system was originally a C++ thing but I got bored of continually compiling a piece of software that doesn't need any low level optimizations, so I looked for a VM that is fast and easy to handle. Neko isn't fast. Java or Mono are not easy to handle (can't distribute them as one file AFAIK).
So, sorry for the troubles. I do take note of such things though to figure out how to make it less troublesome in the future.

I think in this case it was just a partial lack of and a partical out-of-sync documentation issue, easy to fix.

Ah C++, now that is a low level thing for a build system (though I admit that I would probably enjoy it more than I should). Hmm, for a build system that is decently fast (which v8 is), not a bad choice, the big choices would have been either javascript via v8/node or lua via lujit (which is includeable as a single file), neither are typed. A language is not immediately jumping to mind that would make a good typed non-long-compile language and the node dependency standalone is not a bad one. Haskell certainly compiles fast and can make native files, and its compiler is includeable, but that is definitely a language that many people would not know. Elixir's escripts are a recent invention but would make for a standalone file, too late for them though (plus dialyzer for type checking is not too fast). Interesting to think about anyway, node is not a bad choice considering, just, untyped...

khamake itself is nowadays written in typescript though.

Ahh that is definitely a lot better, compiler catches a lot of bugs then.