Is run.d going to be expand for runtime and the phobos library?

[Andrei Alexandrescu]

On 6/13/20 8:41 AM, Seb wrote:
> On Saturday, 13 June 2020 at 09:24:52 UTC, Petar Kirov [ZombineDev] wrote:
>> On Saturday, 13 June 2020 at 03:33:14 UTC, Andrei Alexandrescu wrote:
>>>
>>> That should be killed with fire. I have seldom disliked a program 
>>> this much.
>>
>> I think the most accurate way to classify your message is as 
>> "shitposting", which according to the (5th) definition in the Urban 
>> Dictionary [1] is:
>> 1: The failure to make a constructive post
>> 2: The inability to add useful information to a forum
>> 3: Worthless overly offensive generally racists posts written in a 
>> manner which aggravates others.
>> 4: Nrom
>>
>> Andrei, please use a more professional demeanor.
>>
>> [1]: https://www.urbandictionary.com/define.php?term=shitposting
> 
> I can't agree more. I miss the "original Andrei" :/

The original Andrei, just like today's Andrei, has an appreciation for 
good engineering. I didn't feel the need to add to provide detail 
because (a) most regulars in this forum already knew what I was going to 
say, and (b) nobody save for a few would share my opinion.

But, I'll bite again, again to regret it.

The absolute minimum - and I repeat, absolute minimum, first thing, 
knee-jerk thing - that one would expect from a custom build program 
would be that it separates the data (cmdline options, file names, 
environment vars, everything that's supposed to change often and easily) 
from the code that manipulates them and deals with things like tracking 
dependencies, parsing things, etc. If all is implemented in a single 
file I'd expect the data first, rules next, details at the end. build.d 
almost seems to want to make a point to be nothing like that.

* Available rules (rootRules) nicely appear on line 40.

* Then, we have main() dealing with a lot of stuff. (Why?)

* The rules using makeRule are a confusing mix of code and data starting 
at line 249, after the reader has browsed through a bunch of 
implementation details. (An interesting side question would be what 
language features would make such things easier to write; e.g. a mixin 
string in conjunction with a DSL that implements a small subset of make 
may be nicer. But also becomes ironic - we started by going away from make.)

* Configuration file stuff is at lines 297-315.

* Hundreds of lines of rules follow. It is natural to ask oneself to 
what extent they improve on makefile (or other build tools') syntax. I 
mean is this something easy on the eyes? Did build.d attain its objective?

  582  /// BuildRule to generate man pages
    583  alias man = makeRule!((builder, rule) {
    584      alias genMan = methodInit!(BuildRule, (genManBuilder, 
genManRule) => genManBuilder
    585          .target(env["G"].buildPath("gen_man"))
    586          .sources([
    587              dmdRepo.buildPath("docs", "gen_man.d"),
    588              env["D"].buildPath("cli.d")])
    589          .command([
    590              env["HOST_DMD_RUN"],
    591              "-I" ~ srcDir,
    592              "-of" ~ genManRule.target]
    593              ~ flags["DFLAGS"]
    594              ~ genManRule.sources)
    595          .msg(genManRule.command.join(" "))
    596      );
    597
    598      const genManDir = env["GENERATED"].buildPath("docs", "man");
    599      alias dmdMan = methodInit!(BuildRule, (dmdManBuilder, 
dmdManRule) => dmdManBuilder
    600          .target(genManDir.buildPath("man1", "dmd.1"))
    601          .deps([genMan, directoryRule(dmdManRule.target.dirName)])
    602          .msg("(GEN_MAN) " ~ dmdManRule.target)
    603          .commandFunction(() {
    604              writeText(dmdManRule.target, 
genMan.target.execute.output);
    605          })
    606      );
    607      builder
    608      .name("man")
    609      .description("Generate and prepare man files")
    610      .deps([dmdMan].chain(
    611          "man1/dumpobj.1 man1/obj2asm.1 man5/dmd.conf.5".split
    612          .map!(e => methodInit!(BuildRule, (manFileBuilder, 
manFileRule) => manFileBuilder
    613              .target(genManDir.buildPath(e))
    614              .sources([dmdRepo.buildPath("docs", "man", e)])
    615              .deps([directoryRule(manFileRule.target.dirName)])
    616              .commandFunction(() => 
copyAndTouch(manFileRule.sources[0], manFileRule.target))
    617              .msg("copy '%s' to 
'%s'".format(manFileRule.sources[0], manFileRule.target))
    618          ))
    619      ).array);
    620  });

* The source files are hardcoded somewhere starting at line 1160. I wish 
I was kidding.

* A lot more support code follows, which is fine for a single-file build 
tool. I wish this were a two-files affair a la build.d and buildinfo.d, 
or if single file have an obvious separation:

/****************************************************************
     IMPLEMENTATION FOLLOWS
****************************************************************/