DUB - call to arms

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Apr 26 17:30:50 UTC 2019


On Fri, Apr 26, 2019 at 02:37:31PM +0100, Russel Winder via Digitalmars-d wrote:
> On Fri, 2019-04-19 at 14:58 -0700, H. S. Teoh via Digitalmars-d wrote:
> > 
> […]
> > Yes. I for one dumped Gradle shortly after starting my Android
> > project, because it just didn't let me do what I need to do, or at
> > least not easily.  Gradle expects your typical Java codebase with
> > standard source tree structure.  I needed D codegen and
> > cross-compilation as integral parts of my build.  The two ... let's
> > just say, don't work very well together.  It's the "my way or the
> > highway" philosophy all over again.  Yes it hides away a lot of
> > complexity, and does a lot of nice things automatically -- when what
> > you need to do happens to match the narrow use case Gradle was
> > designed to do.  But when you need to do something *other* than the
> > One Accepted Way, you're in for a long uphill battle -- assuming
> > it's even possible in the first place.  To that, I say, No Thank
> > You, I have other tools that fit better with how I work.
> > 
> 
> Gradle is definitely not rigid as implied in the above: it can work
> with any source structure. True there is a default, and "convention
> over configuration" is the main philosophy, but this can be easily
> overiden by those who need to. 
> 
> There are hooks for doing pre-compilation code generation, though I
> suspect whilst there is support for C++, there is no ready made
> support for D.

Here's a question, since you obviously know Gradle far better than my
admitted ignorance: does Gradle support the following?

- Compile a subset of source files into an executable, and run said
  executable on some given set of input files in order to produce a set
  of auto-generated source files. Then compile the remaining source
  files along with the auto-generated ones to produce the final product.

- Compile a subset of source files into an executable, then run said
  executable on a set of data files to transform them in some way, then
  invoke a second program on the transformed data files to produce a set
  of images that are then post-processed by image-processing tools to
  produce the final outputs.

- Given a set of build products (executables, data files, etc.), pack
  them into an archive, compress, sign, etc., to produce a deliverable.

- Have all of the above work correctly and minimally whenever one or
  more input files (either data files or source files) changes.
  Minimally meaning if a particular target doesn't depend on the changed
  input files, it doesn't get rebuilt, and if an intermediate build
  product is identical to the previous build, subsequent steps are
  elided.

If Gradle can support all of the above, then it may be worthy of
consideration.

Of course, the subsequent question would then be, how easy is it to
accomplish the above, i.e., is it just a matter of adding a few lines to
the build description, or does it involve major build system hackery.


> That you chose to ditch Gradle and go another way is entirely fine,
> but to denigrate Gradle as above based on what appears to be a single
> episode quickly abandoned, is a bit unfair to Gradle.

I did not intend to denigrate Gradle; I was merely relating my own
experience with it.  Clearly, it works very well for many people,
otherwise it wouldn't even be on the radar in the first place.  But it
took far too much effort than I was willing to put in to get it to do
what I need to do, esp. when I already have an SCons system that I'm
already familiar with, and can get up and running with minimal effort.
Given such a choice, it should be obvious why I decided against using
Gradle.


[...]
> The elided comments on Gradle requiring JVM and thus lots of memory
> and relatively slow startup is very fair. Much better grounds for your
> ditching of Gradle than not finding the Gradle way of doing things you
> needed to do.

See, this is the problem I have with many supposedly "modern" tools.
They are giant CPU and memory hogs, require tons of disk space for who
knows what, take forever to start up, and chug along taking their sweet
time just to get the simplest of tasks done, where supposedly "older" or
"antiquated" tools fire up in an instant, get right to work, and get the
same task done in a fraction of the time.  This in itself may have been
excusable, but then these "modern" tools also come with a whole bunch of
red tape, arbitrary limitations, and the philosophy of "follow our way
or walk there on foot yourself".  IOW they do what "antiquated" tools do
poorly, and can't even do advanced things said "antiquated" tools can do
without any fuss -- and this not because of *technical* limitations, but
because it was arbitrarily decided at some point that use cases X and Y
will not be supported, just 'cuz.

So somebody please enlighten this here dinosaur of *why* I should choose
these "modern" tools over my existing, and IMO better, ones?

This is why I'm a fan of empowering the user.  Instead of being obsessed
over how to package your software in a beautiful jewel-encrusted box
with a gold ribbon on top, (which IMO is an utter waste of time and only
attracts those with an inflated sense of entitlement), give the user the
tools to do what the software can do. Instead of delivering a magic
black box that does everything but with the hood welded shut, give them
the components within the black box with which they can build something
far beyond what you may have initially conceived.  I believe *that* is
the way to progress, not this "hand me my software on a silver platter"
philosophy so pervasive nowadays.

(The jewel-encrusted box is still nice, BTW -- but only as long as it's
not at the expense of welding the hood shut.)


> I feel Gradle is probably not a good choice for D builds now, but it
> could be.  This is because no-one is using for that purpose and so the
> easy to use, D oriented tools are not available, everything has to be
> done with the base Gradle tools. 
[...]

If Gradle is dependent on Java, then using it for D builds would be kind
of ... anticlimactic. :-D  But probably the primary issue would be the
slow startup times and heavy storage requirements that goes against the
grain of our present (cringe-worthy) fast-fast-fast slogan. I suppose
it's no coincidence that the Gradle logo is ... just as slow and mellow
as the tool itself. ;-)  (I love RL elephants, BTW, so this isn't meant
in a denigrating way. But I'd have a very hard time justifying the
order-of-magnitude increase in my edit-compile-run cycle turnaround
times.  Life is far too short to have to wait for such things.)


T

-- 
Talk is cheap. Whining is actually free. -- Lars Wirzenius


More information about the Digitalmars-d mailing list