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?
