DIP11: Automatic downloading of libraries

Daniel Gibson metalcaedes at gmail.com
Tue Jun 14 09:24:57 PDT 2011


Am 14.06.2011 17:41, schrieb Andrei Alexandrescu:
> 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. 

And that would be harder than getting support for this in the compiler?
(Especially since there are already tools that could be enhanced)

> 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



More information about the Digitalmars-d mailing list