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

Petar Petar
Tue Dec 3 09:46:59 UTC 2019

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. You lose portability 
> once you add compilation information.

On the contrary. Without compiler directives or a tool that has 
them built-in, like dub or rdmd/rund you don't have any 
portability, because you have no idea how run build the script. 
It's ridiculous to expect just the right set dependencies to be 
magically installed on the system where the script will run. 
Instead good scripts should contain all the necessary information 
to be run in a self-sufficient and cross-platform manner. This 
can include the compiler version (e.g. DMD 2.085.0 or LDC 
1.19.0-beta2), the build tool (e.g. dub 1.16.0), the build flags 
(e.g. -dip1000) and any libraries that they depend on (e.g. 
phobos 2.089.0, mir-algorithm 3.7.2).

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

A mechanically verifiable and executable directive is infinitely 
better ;)

> The proposed change to rdmd would require a bunch of added 
> complexity, and probably introduce bugs, all in the name of 
> duplicating Makefile functionality. Let's leave currently 
> working tools alone.

IMO these use cases already solved by dub and rund, so I think 
there's no need to duplicate the functionality. The functionality 
is very much worth it there.

More information about the Digitalmars-d mailing list