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.
