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