Currently only Visual Studio (win32/x64) but there are plans to support Xcode (ios/osx) and Ninja (linux).
No. As far as I am concerned there is no need now that we have Ninja.
Hardly any. See Ruby knowledge.
This one requires some discussion but there are three main reasons: - jaba heavily espouses the power, simplicity and flexibility of glob matching which is incompatible with automatically updating the build due to the time penalty for detecting new files. Using glob matching can make jaba definitions really clean and simple and can greatly reduce the time spent manually specifying source files, include paths and many other paths as it lets the system do the work. Of course manual specification is still possible and sometimes the best approach. A hybrid can also be used. - The writers of build systems, notably Ninja, have worked very hard to squeeze out every drop of performance for incremental builds. I don't want to hurt that by invoking jaba at the beginning of each and every build, even if the operation is 'high performance'. - Minimises risk to the build.
The down side is that jaba will need to be invoked manually when you update the build. Personally I don't find this to be a problem, indeed I prefer it, because I like to know what's changed in the build before the build starts. Jaba does not touch unmodified files so project files are not unnecessarily reloaded.
The only time this does become a problem is when project files are not checked in (probably the standard approach with build generation systems these days, although see next FAQ). This leads to the need to run jaba after a branch update to ensure the build is up to date. Mitigating this is a simple matter of using a shell script to do the update and adding a call to jaba. This could be done by continuous integration, which would also verify the build.
Its up to you. Jaba is designed to allow you to do this and does not place any absolute paths in generated build files. There are good reasons for doing this on some occasions. Firstly you know that the codebase will build out of the box without any build generation system required (if continuous integration is properly used). Secondly, and very importantly, you can see what is going on in the build via source control diffs. This is a fantastically useful tool to see what's going on and demystify things, especially when things go wrong. This is a strong case for checking in at least a few build files. I always do this and its served me well. Of course if you are targeting a lot of platforms and you are in an environment where every developer does it their own way this may be less desirable.
Absolutely not :) All paths are relative.
Generated using Redcarpet, CodeRay, Inter and FiraCode. css by Harry Denholm.