DUB - call to arms

Russel Winder russel at winder.org.uk
Sat Apr 27 17:15:06 UTC 2019


On Fri, 2019-04-26 at 10:30 -0700, H. S. Teoh via Digitalmars-d wrote:
> 
[…]
> 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.

Yes.

> - 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.

Yes.

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

Yes.

> - 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.

Yes.

> 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.

Not all the things are part of Gradle as distributed, you have to write some
tasks. However the infrastructure is there to make writing the tasks
straightforward. This not one or two lines, but not major hackery.

[...]
> 
> 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.

This is a general problem of software, not just build systems such as Gradle.
It does seem though that Meson + Ninja are much lighter weight.

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

What are the better ones, one cannot debate without knowledge. ;-)

> 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.)

UI and UX are important, definitely. The Groovy DSL and the Kotlin DSL for
writing build are focussed on convention over configuration so as to make
things as simple as possible for the straightforward cases. But the tools are
there to configure and programme the build for complicated cases. In this
Gradle and SCons have similar capabilities though SCons lack many things built
in to Gradle.

There are probably 10x as many build requirements as there are programmers. A
single unopenable black box build system simply has no chance. 

[…]
> 
> 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.)

Gradle is JVM-based, but they have build servers and caching to make builds
faster than you might think. Clearly the bulk of build focus is on JVM-related 
stuff, but C and C++ got added because someone paid for it to be added.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20190427/82ff1968/attachment-0001.sig>


More information about the Digitalmars-d mailing list