The use case is you have a collection of D scripts within the same directory subtree (maybe a git repo) that all share some common configuration. Maybe they all require extra search paths to find source/libraries, or they all throw exceptions to the user and should be compiled with debug symbols so exceptions print their full stacktrace, etc.  Rather then requiring the user to call the script in a particular way or wrapping all the scripts with yet another tool, what about adding support in rdmd for configuration files?  The configuration file could live in any parent directory of the script being ran:

FileSystem:
  /a/b/c/myscript.d

Shell:
/a/b/c> rdmd myscript.d

rdmd checks for /a/b/c/rdmd.config
rdmd checks for /a/b/rdmd.config
rdmd checks for /a/rdmd.config
rdmd checks for /rdmd.config

The rdmd.config file would apply to all rdmd scripts in all subdirectories on the file system.  It works similar to how git determines whether or not it lives in a repository (searches all parent directories for the .git directory).

Additionally, allowing rdmd to be configured through files makes more complicated configurations more reasonable.  For example, if your scripts depend on a dub package, you could do this easily in a configuration file, whereas doing this on the command line would be a nightmare.

Supporting this type of configuration could easily be implemented in a wrapper around rdmd (rdmdc?), however, if this idea is generally useful then it should be added to rdmd itself so everyone benefits.  The question is, is this feature general and useful enough to justify adding to rdmd itself, or is this only useful in rare cases meaning it should live inside an rdmd wrapper?

On Thursday, 11 August 2016 at 18:47:05 UTC, Jonathan Marler wrote:
> The use case is you have a collection of D scripts within the same directory subtree (maybe a git repo) that all share some common configuration. Maybe they all require extra search paths to find source/libraries, or they all throw exceptions to the user and should be compiled with debug symbols so exceptions print their full stacktrace, etc.  Rather then requiring the user to call the script in a particular way or wrapping all the scripts with yet another tool, what about adding support in rdmd for configuration files?  The configuration file could live in any parent directory of the script being ran:
>
> FileSystem:
>   /a/b/c/myscript.d
>
> Shell:
> /a/b/c> rdmd myscript.d
>
> rdmd checks for /a/b/c/rdmd.config
> rdmd checks for /a/b/rdmd.config
> rdmd checks for /a/rdmd.config
> rdmd checks for /rdmd.config
>
> The rdmd.config file would apply to all rdmd scripts in all subdirectories on the file system.  It works similar to how git determines whether or not it lives in a repository (searches all parent directories for the .git directory).
>
> Additionally, allowing rdmd to be configured through files makes more complicated configurations more reasonable.  For example, if your scripts depend on a dub package, you could do this easily in a configuration file, whereas doing this on the command line would be a nightmare.
>
> Supporting this type of configuration could easily be implemented in a wrapper around rdmd (rdmdc?), however, if this idea is generally useful then it should be added to rdmd itself so everyone benefits.  The question is, is this feature general and useful enough to justify adding to rdmd itself, or is this only useful in rare cases meaning it should live inside an rdmd wrapper?

In my opinion, adding this complexity to rdmd is overkill. When you need to use this, IMHO, you should write a little shell script that calls rdmd passing the correct arguments. It's very easy, just a couple of lines of shell script. Maybe even a one-liner.

In file rdmd_wrapper.sh:
rdmd -my-special -command-line -parameters $*

When you call it this way:
./rdmd_wrapper mymodule.d

It will execute this:
rdmd -my-special -command-line -parameters mymodule.d

If you need the same configuration really often, you can add the wrapper to the path, so you can call it from everywhere.

But this is just my opinion, many may disagree.

On Thursday, 11 August 2016 at 20:44:12 UTC, Lodovico Giaretta wrote:
> On Thursday, 11 August 2016 at 18:47:05 UTC, Jonathan Marler wrote:
>> ...
>> Additionally, allowing rdmd to be configured through files makes more complicated configurations more reasonable.  For example, if your scripts depend on a dub package, you could do this easily in a configuration file, whereas doing this on the command line would be a nightmare.
>>
>
> In my opinion, adding this complexity to rdmd is overkill. When you need to use this, IMHO, you should write a little shell script that calls rdmd passing the correct arguments. It's very easy, just a couple of lines of shell script. Maybe even a one-liner.
>
> In file rdmd_wrapper.sh:
> rdmd -my-special -command-line -parameters $*
>
> When you call it this way:
> ./rdmd_wrapper mymodule.d
>
> It will execute this:
> rdmd -my-special -command-line -parameters mymodule.d
>
> If you need the same configuration really often, you can add the wrapper to the path, so you can call it from everywhere.
>
> But this is just my opinion, many may disagree.

I don't necessarily agree or disagree with you, thanks for providing your opinion.  A wrapper script would certainly solve the simple cases.  The con is that it adds an extra layer to the script and every application will have their own solution which makes a project more isolated.  The wrapper script was the first solution that came to my mind but as I thought about configuration files, they seemed worth considering.

I'm curious what you think about the more complex operations that configuration files could facilitate. The example I gave was that this could enable a script to use dub package dependencies that are automatically downloaded and built by rdmd, but I'm sure there are other interesting use cases.  An argument could be made that this should go in an external tool rather then rdmd though, but that thought seemed a bit odd since rdmd is already a wrapper around dmd itself, but maybe that's ok.  Do you have any new features rdmd could support if it had configuration files?

On Thu, 11 Aug 2016 20:44:12 +0000, Lodovico Giaretta wrote:
> In file rdmd_wrapper.sh:
> rdmd -my-special -command-line -parameters $*
> 
> When you call it this way:
> ./rdmd_wrapper mymodule.d

You can add parameters inside the file itself:

#!/usr/bin/rdmd --shebang -m32 -d -I/opt/vibed/source
void main() {}

Maybe not ideal but it works.

On Thursday, 11 August 2016 at 21:58:35 UTC, Chris Wright wrote:
> On Thu, 11 Aug 2016 20:44:12 +0000, Lodovico Giaretta wrote:
>> In file rdmd_wrapper.sh:
>> rdmd -my-special -command-line -parameters $*
>> 
>> When you call it this way:
>> ./rdmd_wrapper mymodule.d
>
> You can add parameters inside the file itself:
>
> #!/usr/bin/rdmd --shebang -m32 -d -I/opt/vibed/source
> void main() {}
>
> Maybe not ideal but it works.

This does work when you use rdmd myscript.d does it?  Only when you run ./myscript.d?

On Thursday, 11 August 2016 at 21:33:24 UTC, Jonathan Marler wrote:
> On Thursday, 11 August 2016 at 20:44:12 UTC, Lodovico Giaretta wrote:
>> On Thursday, 11 August 2016 at 18:47:05 UTC, Jonathan Marler wrote:
>>> [...]
>> [...]
>
> I don't necessarily agree or disagree with you, thanks for providing your opinion.  A wrapper script would certainly solve the simple cases.  The con is that it adds an extra layer to the script and every application will have their own solution which makes a project more isolated.  The wrapper script was the first solution that came to my mind but as I thought about configuration files, they seemed worth considering.

I agree that a custom wrapper script has the drawbacks you said.
But I fear that a configuration-file-based system would either only solve simple cases or would become very complex and difficult to master in order to accomodate to most special uses, thus becoming less appealing than a simple script.
A config file format is one more thing to know and to look up: "how do I do this with rdmd-config?", while the Internet is full of tutorials on "how to do this with bash". The same happens to DUB: it allows to do many things when building the project, so people asks "how can I do this with DUB?" while it would probably be easier to just write a shell script that calls DUB and then (or before) does the other thing.
We should avoid reinventing the wheel.

> I'm curious what you think about the more complex operations that configuration files could facilitate. The example I gave was that this could enable a script to use dub package dependencies that are automatically downloaded and built by rdmd, but I'm sure there are other interesting use cases.  An argument could be made that this should go in an external tool rather then rdmd though, but that thought seemed a bit odd since rdmd is already a wrapper around dmd itself, but maybe that's ok.  Do you have any new features rdmd could support if it had configuration files?

I think that many reasonable but not-trivial things can already be done with DUB, which allows custom compiler and linker flags, custom commands before and after the build, different configurations and so on. It is already a very complex configuration system, and can also do the job of rdmd ("dub run" executes the project, using a cached compiled file if available and up to date, as rdmd).
DUB also allows to have single-source packages, where the DUB configuration and dependencies are embedded in a comment at the beginning of the source, which would be a great solution for your example, as it doesn't even require a configuration file.

On Thursday, 11 August 2016 at 22:14:35 UTC, Lodovico Giaretta wrote:
> [...]

I didn't know about that last feature, that's pretty cool. Maybe dub is the right way to go, thanks for the input.

On 08/11/2016 06:04 PM, Jonathan Marler wrote:
> On Thursday, 11 August 2016 at 21:58:35 UTC, Chris Wright wrote:
>> On Thu, 11 Aug 2016 20:44:12 +0000, Lodovico Giaretta wrote:
>>> In file rdmd_wrapper.sh:
>>> rdmd -my-special -command-line -parameters $*
>>>
>>> When you call it this way:
>>> ./rdmd_wrapper mymodule.d
>>
>> You can add parameters inside the file itself:
>>
>> #!/usr/bin/rdmd --shebang -m32 -d -I/opt/vibed/source
>> void main() {}
>>
>> Maybe not ideal but it works.
>
> This does work when you use rdmd myscript.d does it?  Only when you run
> ./myscript.d?

And only on posix, not windows.