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

[Jonathan Marler]

On Tuesday, 3 December 2019 at 02:02:08 UTC, mipri wrote:
> On Tuesday, 3 December 2019 at 01:28:00 UTC, bachmeier wrote:
>> On Monday, 2 December 2019 at 22:18:06 UTC, mipri wrote:
>>
>>> 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.
>>
>> If you include compiler directives inside the file, you're
>> *not* executing the code, because you're adding code to tell
>> the compiler what to do with the file.
>
> There's no operational difference. The user types ./foo, stuff
> happens. If the user edits foo and then types ./foo again,
> something different happens. The illusion break for D is that
> some invocations are slower than others due to compilation
> overhead. Python had (or has) the same effect, though less
> noticeable, with its .pyc cache files. This is bearable and
> compiler directives do not change it in any way.
>
>> You lose portability
>> once you add compilation information.
>
> This is actually an offensively ridiculous concern.
>
>>> 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?
>>
>> You can add a comment explaining how to compile the code.
>
> Comments are not code, and when you compile a script you get a
> binary, not a script. The exact same problems can arise: I have
> a problem with this binary and the source is nowhere to be
> found. Or I have a problem with this binary and the nearby
> script has a comment that may or may have not been followed to
> build it.
>
>> The
>> proposed change to rdmd would require a bunch of added
>> complexity,
>
> Adding code adds complexity. This is true.
>
>> probably introduce bugs
>
> Adding code probably adds bugs. This is also true.
>
>> duplicating Makefile functionality.
>
> Makefiles have nothing to do with scripts.
>
>> Let's leave currently
>> working tools alone.
>
> rdmd is not a "working tool" when your task requires some
> compiler flags.
>
> This level of scare-mongering about some trivial array
> manipulation is absurd to the point that I actually start to
> suspect malicious intentions. Who sent you and how much are
> they paying you?

I've had the same thoughts and feelings many times on this forum 
and in the Dlang community in general.  I've learned to spend 
less time trying to convince people so I can spend more time 
doing what I love, which is programming.  If I can't convince 
someone, or they are being unreasonable then I figure out how I 
can get what I want without their permission.  It usually means I 
must spend more time learning and possibly duplicating effort, 
but in my experience the trade-off is usually worth it.

After so much time arguing with people about rdmd, I created 
rund.  As a result, I now have a much faster and better tool that 
I've been using for over a year, and I've been spared a large 
amount of frustration.  Since I sometimes use this tool hundreds 
of times a day it was worth the investment, and I'm very happy 
with the result.  If others want to use it, improve it, or add it 
to package management systems then I'm happy to work with them 
and will be glad to see it help others as well.

P.S. you mentioned the 'noexec' issue, I noticed this a while 
back and opened an issue on it for rund 
(https://github.com/dragon-lang/rund/issues/17).  I have a few 
solutions but no one's really asked for it yet so I haven't 
chosen a solution yet.  When someone brings up a need and/or use 
case for it then I'll be implementing one of the solutions.