How do people feel about putting source compiler directives inside rdmd?

[mipri]

On Monday, 2 December 2019 at 21:43:17 UTC, bachmeier wrote:
> On Monday, 2 December 2019 at 20:04:17 UTC, aliak wrote:
>
>> Dub is painfully slow for scripting
>
> Dub is painful for everything else so I'm not surprised to hear
> it's painful for scripting.

I have a bash script that uses 'dub run' to invoke dfmt, and the
chief problem with that is that any random use of dfmt may
trigger a slow library upgrade. If shebang uses of dub work like
this as well, that's a big problem for scripting. In the more
limited use of dub scripts that I've used, they're fine. Caching
is very similar to rdmd.

I'm not fond of /tmp as a default (it's often noexec) but
there's no variation here in the tooling.

>> if you require a makefile whenever someone wants to write a
>> script then python it is.
>
> If that's all it takes for someone to use Python, they'll be
> using Python regardless. I can understand the idea of rdmd if
> you can use it without configuration. If you're going to add
> compiler configuration information to your "script", you no
> longer have a script, you have something really confusing for
> Python users.

A script is a file with source code in it that you can execute.
The essential feature of scripts is that the source code is what
you're executing.

In deployed systems, on servers, in other people's code, when
you come across a binary that you have a problem with, it can be
a long adventure to find the source of that binary, and then you
may still have not found *the* source to *the* binary, but just
*some* source that could create similar binaries. For example,
if you find a repo link in a near by document, what commit to
that repo was used to build the binary that you have?

With a script, the source is always there. This helps enormously
in troubleshooting, especially hands-on kind of troubleshooting
where you temporary modify the program to see how this affects
what you're investigating. If someone has coded in an ill-advised
restriction, you can temporarily bypass it. If there's a bug and
the fix can't be deployed for whatever reason, you can tell
people about a sed oneliner that fixes the script in situ on
machines where they need the fix. You may not even have access
to see the repo that the script's source is in, but since you
have the script you can fix a problem and email the author a
patch.

The documentation is also often always there, as it can be
inline with the script. You may be able to 'perldoc
/root/bin/special_sysadmin_thing' and get more detailed notes
about the exact version of the exact thing at hand.

Compiler configuration flags change nothing at all about this.