I've used ninja and gyp for building Android apps. It is 1 to 2 orders of magnitude faster than Gradle.
Do you have an example gyp file for Android that you could share ?
Ninja – A small build system with a focus on speed
21–30 of 30 posts
Re: Ninja – A small build system with a focus on speed
#22I've used ninja and gyp for building Android apps. It is 1 to 2 orders of magnitude faster than Gradle.
Decimal magnitude?
Re: Ninja – A small build system with a focus on speed
#23Jeez, can't you kids just quit this square-wheel churn and just buckle down and learn to write makefiles? It's really not that hard.
Sigh. As far as I can tell ninja is primarily used as a cmake backend. Mostly because the people who wrote cmake never learned to write Makefiles and as a result using ninja with cmake is much faster.
If you need a multi-platform build system that runs on Windows, OSX, Linux, supports the platform's native compilers, and that also works for IDEs, GNU make is simply not an option. Then add cross-compiling to Android, iOS, emscripten, NaCl, game consoles etc... and cmake suddenly looks really nice. I've been using manually written makefiles years ago (around end of the 90's), but then also had to support Visual Studio projects, so I wrote a Tcl script which could generate makefiles and Visual Studio project files from the same project description, this soon became a problem because I also wanted to use Xcode and Linux IDEs, and also because Visual Studio project files change between versions. Cmake does the same and much more (there are also other, similar systems like scons or premake, but cmake seems to have "won"). CMakeFiles ain't pretty, but I never encountered a build problem (including more complex stuff like code generation or running custom build steps) I couldn't solve without pulling my hair out, and everything works automatically across IDEs and platforms.
[edit: typos]
Re: Ninja – A small build system with a focus on speed
#24I use ninja everyday with cmake and it's just perfect - never had a problem with it.
Re: Ninja – A small build system with a focus on speed
#25Here is the blog post about it from the author. It goes into the motivations behind building it and the fact that it was fun project over the weekend
http://neugierig.org/software/chromium/notes/2011/02/ninja.h...
I've used ninja only during my experiments with chromium and I found it blazing fast.
Re: Ninja – A small build system with a focus on speed
#26I've used ninja and gyp for building Android apps. It is 1 to 2 orders of magnitude faster than Gradle.
About all that can be said for Gradle is that it makes Maven seem tolerable.
I don't really get the hype about Gradle.
For those of us without XML phobia, it doesn't offer any benefit and is slow as molasses.
Re: Ninja – A small build system with a focus on speed
#27Earlier quoted context omitted.
About all that can be said for Gradle is that it makes Maven seem tolerable.
I don't really get the hype about Gradle. For those of us without XML phobia, it doesn't offer any benefit and is slow as molasses.
You can speed it up somewhat by tweaking ~/.gradle/gradle.properties and adding org.gradle.daemon=true
and org.gradle.parallel=true. That way at least it doesn't have to re-read all the build files each time and will run some parts in parallel.
The benefit wrt the old Ant-based build is the way it lets you specify 3rd party dependencies. Being able to just add in say Timber, ButterKnife and Guava with a few lines of config, rather than downloading the jars, faffing with paths, making sure the pre-processing bits are in place, etc, is really a big benefit. Maybe Maven would have been a more sensible choice, since Gradle/Groovy seems pretty niche and not really used that much outside Android.
Re: Ninja – A small build system with a focus on speed
#28Earlier quoted context omitted.
Sigh. As far as I can tell ninja is primarily used as a cmake backend. Mostly because the people who wrote cmake never learned to write Makefiles and as a result using ninja with cmake is much faster.
Kitware have a lot to apologise for.
I disagree, and think they've done a great job. The CMake devs have always been really responsive to bigish projects that find CMake to be almost-but-not-quite good enough for their project, adding in missing autotools features or other semi-commonly used bits and bobs.
They manage to keep up with all the churn in the world of compiled software, whereas it would be so easy to let a tool like CMake bitrot. Old mistakes have sensible deprecation policies too, so they have managed to avoid the accumulation of cruft that could have brought it to a standstill.
Re: Ninja – A small build system with a focus on speed
#29Earlier quoted context omitted.
I don't really get the hype about Gradle. For those of us without XML phobia, it doesn't offer any benefit and is slow as molasses.
You can speed it up somewhat by tweaking ~/.gradle/gradle.properties and adding org.gradle.daemon=true and org.gradle.parallel=true. That way at least it doesn't have to re-read all the build files each time and will run some parts in parallel. The benefit wrt the old Ant-based build is the way it lets you specify 3rd party dependencies. Being able to just add in say Timber, ButterKnife and Guava with a few lines of…
> ... since Gradle/Groovy seems pretty niche and not really used that much outside Android.
This is the only reason I am now forced to deal with it.
On our enterprise Java projects it is all about Ant and Maven.
Re: Ninja – A small build system with a focus on speed
#30Jeez, can't you kids just quit this square-wheel churn and just buckle down and learn to write makefiles? It's really not that hard.
A Ninja file is probably no easier to write than a Makefile. But Ninja is a lot faster than make, which is the reason for using it. To see this, configure Chromium to build with Xcode, make, and ninja, and compare the build times.
Adding to this, from what I understand, ninja was designed to be generated by another more feature-full build tools. For example in chromium, its generated from gyp (generate your projects) files. The fact that its human readable is just a plus.
Makefiles I presume, will be hard to write by hand when:
1. Your project code base is large 2. It take large amount of time or very powerful machines to build sub-modules (V8 for e.g in chromium) so, you don't want to do it all the time 3. Conditional inclusion of sub-modules (for iOS vs Android if you have two separate set of files etc) 4. Sub-modules are pulled in from 3rd parties into your code base