54 ms·

We use gradle at work with c++ projects. It's hilarious how slow it is. Why do people use it?

by dave2000 11y ago

MaulingMonkey 11y ago
Because it's faster than ANT. (Used it via nVidia CodeWorks for Android when doing a mostly C++ project which also had some Java in it for Android.)
- dave2000 11y ago
  What's wrong with just using a makefile?
  - deleted 11y ago
    [deleted]
  - MaulingMonkey 11y ago
    1) You're stepping outside of the boundaries of what every 3rd party API documents configuring ('add this to your gradle config') when I'm already too much of a bottleneck for figuring out build configuration. 2) You're replacing something that... mostly works out of the box, with something you have to configure entirely yourself. 3) Requires intimate knowledge of the entire Android build chain to properly set up. I might know about ~90% of it after some nasty debugging sessions involving flaky USB connections and commands which return 'successfull' exit codes / stdout spam when they fail - so we'll call the bus factor of that setup 0.9 as my coworkers frankly did not want to know, for which I don't even remotely blame them. 4) Yet another build dependency to install on every dev and build machine (make. *nix isn't an answer either: too many Windows specific toolchains for gamedev to make non-Windows remotely feasible as a primary dev environment.) 5) Not actually solving the remaining bottlenecks. Switching to Gradle got us down to ~5 seconds / build / project for the Java and APK packaging portion of the build, which looked mostly like it was dependency scanning, zipping, and code signing - just like I'd need my Makefile to be doing anyways. I was skeptical that I could do much better. Next, I switched linkers and saved closer to 90 seconds / build / project for even the simplest typo fix in the C++ side of things. And that's just what's wrong with replacing gradle with a makefile. If we wanted to replace the entire build pipeline and build our C++ with makefiles too: 6) Would need to replace extensive existing MSBuild configurations entirely, or duplicate work between two different build setups. Would need to learn other platform build chains sufficiently as well (XB1, PS4, Win8 Apps... I don't recall seeing full docs on this when I still had access, although over the years I pieced together a distressingly large chunk of the pie. We'll optimistically call it 70% of the pie, for a bus factor of 0.7.) 8) Even with dependency files and substitution magic, make will rebuild more than VS with the right settings. I've also only ever done it with GCC - trying to figure out how to coax a proper dependency file out of MSVC's compiler doesn't sound fun. Mixing and matching compilers sounds like an even worse idea - a great way to introduce subtle rebuild bugs due to built-in #define differences. No, I'm not going to try and target XB1 with clang. 9) Poorer VS integration. Simple things like Ctrl+F7ing to compile / syntax check single files won't work without setting up your own keybindings to (ab)use e.g. "External Commands". That might be most of what's wrong for my use cases.
- smrtinsert 11y ago
  This is a laughable generalization.
  - MaulingMonkey 11y ago
    In response to a similarly laughable generalization, with added parentheticals explaining the rather specific case I found this to be true within.
bpodgursky 11y ago
In my extremely biased opinion... because it lets you do terrible things in free-form code which opinionated tools like Maven don't allow. (I'm not a fan)
smrtinsert 11y ago
In a about a day of building with gradle, I could have manually downloaded and verified myself every jar my project will need, as compared to say, ant. The amount of time I lose to it is criminal especially considering it is supposed to improve our productivity. Gradle is a horrible thing that lets people do whatever they want - and people who think freedom == productivity flock to it for that reason only. History of course teaches otherwise.
on_and_off 11y ago
I use gradle for Android projects. We replaced ant with gradle when we switched to Android studio. How to import a library with some resources with ant ? -copy paste it somewhere accessible in your project. It makes importing and more importantly updating the support lib (or most libs really) a pain in the ass. How does it work with gradle ? compile "com.android.support:appcompat-v7:23.2" Between this and flavors, I might not love gradle, but it is still a big step up from ant.

We use gradle at work with c++ projects. It's hilarious how slow it is. Why do people use it?

Because it's faster than ANT. (Used it via nVidia CodeWorks for Android when doing a mostly C++ project which also had some Java in it for Android.)

dave2000 11y ago
What's wrong with just using a makefile?
- deleted 11y ago
  [deleted]
- MaulingMonkey 11y ago
  1) You're stepping outside of the boundaries of what every 3rd party API documents configuring ('add this to your gradle config') when I'm already too much of a bottleneck for figuring out build configuration. 2) You're replacing something that... mostly works out of the box, with something you have to configure entirely yourself. 3) Requires intimate knowledge of the entire Android build chain to properly set up. I might know about ~90% of it after some nasty debugging sessions involving flaky USB connections and commands which return 'successfull' exit codes / stdout spam when they fail - so we'll call the bus factor of that setup 0.9 as my coworkers frankly did not want to know, for which I don't even remotely blame them. 4) Yet another build dependency to install on every dev and build machine (make. *nix isn't an answer either: too many Windows specific toolchains for gamedev to make non-Windows remotely feasible as a primary dev environment.) 5) Not actually solving the remaining bottlenecks. Switching to Gradle got us down to ~5 seconds / build / project for the Java and APK packaging portion of the build, which looked mostly like it was dependency scanning, zipping, and code signing - just like I'd need my Makefile to be doing anyways. I was skeptical that I could do much better. Next, I switched linkers and saved closer to 90 seconds / build / project for even the simplest typo fix in the C++ side of things. And that's just what's wrong with replacing gradle with a makefile. If we wanted to replace the entire build pipeline and build our C++ with makefiles too: 6) Would need to replace extensive existing MSBuild configurations entirely, or duplicate work between two different build setups. Would need to learn other platform build chains sufficiently as well (XB1, PS4, Win8 Apps... I don't recall seeing full docs on this when I still had access, although over the years I pieced together a distressingly large chunk of the pie. We'll optimistically call it 70% of the pie, for a bus factor of 0.7.) 8) Even with dependency files and substitution magic, make will rebuild more than VS with the right settings. I've also only ever done it with GCC - trying to figure out how to coax a proper dependency file out of MSVC's compiler doesn't sound fun. Mixing and matching compilers sounds like an even worse idea - a great way to introduce subtle rebuild bugs due to built-in #define differences. No, I'm not going to try and target XB1 with clang. 9) Poorer VS integration. Simple things like Ctrl+F7ing to compile / syntax check single files won't work without setting up your own keybindings to (ab)use e.g. "External Commands". That might be most of what's wrong for my use cases.
smrtinsert 11y ago
This is a laughable generalization.
- MaulingMonkey 11y ago
  In response to a similarly laughable generalization, with added parentheticals explaining the rather specific case I found this to be true within.

bpodgursky 11y ago

In my extremely biased opinion... because it lets you do terrible things in free-form code which opinionated tools like Maven don't allow. (I'm not a fan)

smrtinsert 11y ago

In a about a day of building with gradle, I could have manually downloaded and verified myself every jar my project will need, as compared to say, ant. The amount of time I lose to it is criminal especially considering it is supposed to improve our productivity. Gradle is a horrible thing that lets people do whatever they want - and people who think freedom == productivity flock to it for that reason only. History of course teaches otherwise.

on_and_off 11y ago

I use gradle for Android projects. We replaced ant with gradle when we switched to Android studio. How to import a library with some resources with ant ? -copy paste it somewhere accessible in your project. It makes importing and more importantly updating the support lib (or most libs really) a pain in the ass. How does it work with gradle ? compile "com.android.support:appcompat-v7:23.2" Between this and flavors, I might not love gradle, but it is still a big step up from ant.