The DUB package manager

Sönke Ludwig sludwig at outerproduct.org
Sun Feb 17 02:58:27 PST 2013


Am 17.02.2013 11:21, schrieb Peter Sommerfeld:
> Am 17.02.2013, 10:24 Uhr, schrieb Russel Winder:
>> On Sun, 2013-02-17 at 09:12 +0100, Sönke Ludwig wrote:
>>
>>> I agree about the non-optimal syntax, but it comes down to nicer syntax
>>> (where JSON at least is not _too_ bad) vs. standard format (familiarity,
>>> data exchange, proven design and implementation). And while data
>>> [...]
>>
>> Peter's point is more important than the above response indicates.
> 
> I think so too. And I don't believe that it will stay by a few lines
> only because the demands will increase in the course of time. Think
> about including C/C++ compiler, a project manager etc.

If I were to vote for anything, that would be to never support C/C++ or
any other foreign language builds. There are enough tools for that and I
don't see enough value for the huge complexity that this route would add
(just consider autotools or cmake).

Not sure what you mean by project manager, but right now, I see no
reason why it shouldn't be possible to keep the package/build
description very compact. If something gets complex anyway, maybe it
should be broken up into multiple packages (e.g. one with the C/C++
stuff + bindings and one using the C++ stuff).

> 
> With a syntax as I suggested or something similar everything is mapped
> direct onto an AA and is easily scanned by the build system or other
> tools.
> 
> Regarding json: It is designed for data exchange between different
> sources, not to be edited by people. It is too annoying and error-
> prone to wrap each string into quotes. And people have to edit the
> configuration file. Better to start in a well suited format.

This is just wrong. JSON is just JavaScript, which is meant for human
editing just as D or a custom DSL is. There definitely are nicer
syntaxes, but this is putting it out of proportion, IMO. I'm surely not
against using a different format, but all arguments must be weighted
against each other here.


More information about the Digitalmars-d mailing list