On 6/14/11 10:26 AM, Daniel Gibson wrote:
One additional file. I don't think having one file would be a burden to
the programmer, not much more than adding pragmas in his code.
But if there's central metadata repository even this additional file
isn't needed - neither are pragmas - (the build-tool will ask that repo
where to find the lib/module), unless the lib is kind of obscure or
brand-new and thus not known by the metadata repo. And in that case:
it's just a single file.
(Of course it would be possible to periodically or via "build-tool
update" - like apt-get update - fetch the metadata, so the server
doesn't have to be asked each time.)
I agree that a build tool is an alternative. The problem is that it's
front-heavy - we need to design the config file format, design the tool
to deal with various dependency issues etc. Many of these issues are
solved by design or don't even exist with the pragma, for example
there's no need for a config file format or for config files in the
first place (although they can be easily defined as small .d files
consisting of pragmas).
One thing I like about the pragma is that it's mostly mechanism and very
little policy, while at the same time fostering very simple,
straightforward policies. Source files can carry their own dependencies
(but they don't need to), transitivity just works, (re|in)direction and
central repos are possible without being required.
One other interesting aspect is that the string literal can be
CTFE-constructed, i.e. may include a path to a library depending on the
OS, version, etc. An external tool would need to give up on that (and
use multiple configuration files) or invent its own string manipulation
primitives.
Andrei
