DUB - call to arms

[Gilter]

On Friday, 26 April 2019 at 17:30:50 UTC, H. S. Teoh wrote:
> 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.

Not sure what you find difficult about this. You create 2 tasks, 
one task generates the executable. The second task runs the 
executable, add the first task as a dependency of the second 
task. It really just boils down to, do this task before this 
other task and a task should be able to be just a command you can 
run. Which is basically what every build system supports.

https://docs.gradle.org/current/userguide/more_about_tasks.html#sec:adding_dependencies_to_tasks

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

This really is just a task where you run a command. Signing is 
different for basically every system, and depending on the system 
it can be different based on what program you are using to sign. 
If you expect the build system to know how to sign an executable 
by just doing "sign: true" then you aren't going to find a build 
system like that unless it only works on one system.

For zip files you can easily archive them:

https://docs.gradle.org/current/userguide/working_with_files.html#sec:archives

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

This has been around for quite a while, since 2.5 by the looks of 
it. You have to specify the input and output files so it can 
detect if they were changed.

https://docs.gradle.org/2.5/userguide/more_about_tasks.html#sec:up_to_date_checks

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

What build systems do you know that support the above. Like I 
said somethings are kind of unreasonable, like expecting a build 
system to be able to sign your executables with just a simple 
flag. The signing process I have to do doesn't actually allow us 
to automate it. For some reason it won't work, you have to be 
physically be at the server for it to sign the executable. Seems 
like it might be a security feature, can't even remote into the 
server to sign it manually like that either.

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

Imagine that, learning something new takes a lot more effort than 
using something you already know. Who would have thought?

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

What do you consider giant CPU and memory hogs that require a ton 
of disk space? Cause from my experience the people here complain 
about VS taking up so much space, end up doing development work 
on some shitty tablet with 32 GB of HDD space.

I just use a python script, I don't feel like bothering with 
things like SCons. I execute exactly what I need and it is easy 
to see what it is doing and what is happening. It doesn't take 
long to compile either though, I usually only need to re-compile 
one component as well.

Use whatever you want, just don't go condemning something cause 
you never bothered to learn how to use it.