I would now like to invoke the Zero One Infinity
Rule(http://en.wikipedia.org/wiki/Zero_one_infinity_rule).
Supporting one format makes sense - DUB can simply use the set of
functions and data structures provided by Phobos or by external
libraries for using this format.
Supporting two formats will require two sets of functions and
data structures, and to decide a point where the two code-paths
will be joined to a single representation of the build
configuration. According to the ZOI rule, you might as well take
the extra step and support infinity formats!
This is my idea - the point of entry will remain "dub.json". For
a project to use SDL for build configuration, "dub.json" will
look something like this:
{
"import" : [
{
"file": "dub.sdl",
"parser": "dub-sdl"
}
]
}
When DUB sees this, it'll download the "dub-sdl" package from the
DUB repository(unless it already downloaded it) and use it to
parse "dub.sdl".
There can be a number of ways to do this - maybe DUB will load a
dynamic library from "dub-sdl" and use the functions directly, or
maybe "dub-sdl" will convert "dub.sdl" into JSON format that DUB
can parse directly, or maybe it'll parse it into a binary format
so it'll be more efficient to serialize and parse it.
It doesn't matter how it ends up done - the point is that DUB
will decide the method for getting that data and the parser
packages will have to conform to it. Once the framework is in
place, we can have "dub-sdl", "dub-ason", "dub-yaml" etc.
This mechanism can also be used for splitting the build file -
which can be useful if you want to have parts of it updated
regularly by automatic tools, or to put only parts of the build
configuration under source control. For this, different file
names can be put in the "file" field even if they all use the
same format, and "parser" can be omitted to read JSON files.
