Make dub part of the standard dmd distribution

Rikki Cattermole via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 2 03:30:47 PDT 2015


On 2/06/2015 10:15 p.m., ketmar wrote:
> On Tue, 02 Jun 2015 21:51:54 +1200, Rikki Cattermole wrote:
>
>> Essentially its compiler plugins that can add news types +
>> free-functions as if it was D code provided by source code only also
>> able to modify e.g. AST directly.
>> So while in of itself would not provide new language features, it could
>> add some very nice behavior to existing ones.
>>
>> So what you want with commands ext. would be done in a shared library.
>> It have e.g. a struct added into object.d(i).
>>
>> __CEIFileSystem.delete("./tmp/something");
>>
>> Of course adding these plugins should be pretty explicit. Package
>> maintainers for example shouldn't auto install any. There should be no
>> way to auto install them.
>>
>> Basically dmd-plugin-dub-bin would be an example package. That would add
>> dub support directly into dmd.
>>
>> ----------
>> @__CEIDub.Dependency("vibe-d", ">=0.7.22")
>> void main() {
>> 	// what have you
>> }
>> ----------
>>
>> Or:
>>
>> ----------
>> static assert(__CEIDub.dependency("vibe.d", ">=0.7.22"), "Requires
>> vibe-d 0.7.22 or newer.");
>>
>> void main() {
>> 	// what have you
>> }
>> ----------
>>
>> That way it can be used for e.g. static-if and template if.
>>
>> Of course I'm sure Walter would go nuts at such an idea, if it was
>> seriously proposed.
>> So perhaps dmd doesn't support it. Instead a new version of dmd is also
>> shipped (dmdext) with this enabled ;)
>>
>> With the community agreeing that we should try to keep as close to dmd
>> as possible and only reverting to dmdext + plugins to help newbies and
>> where it just wouldn't be possible to not have an external tool. Which
>> most likely uses multiple compilation or something else not so nice.
>
> actually, that should be doable with DDMD on non-windows systems*, i
> believe. DDMD -- to avoid writing plugins in other languages. ;-) and
> with DDMD plugins will have full access to frontend internals, including
> AST manipulation.
>
> * non-windows, as dll support on windows is still not here, i believe.

I've been able to do it a little bit already with my Web server. Haven't 
hit its limit so far. In other words as long as exceptions aren't used 
and its never unloaded, should be ok. Anyway, do you really think we 
would get that sort of support for a couple of releases?

> the downside of this approach is that it's highly compiler-specific. i.e.
> one will force to have different plugins for GDC/LDC/SDC/etc. ;-) and
> with pure CTFE API without plugins, only with external executables, it
> will be compiler-agnostic, any compiler using DMDFE will get it for free.
> only SDC will be forced to rewrite the CTFE part, but other than that all
> CTFE D code will work the same.

Yeah it is, but it would also mean better customization of the build 
process!

> i mean, 'cmon, we have such great built-in scripting engine, let's use it!

Indeed lets. But can we also not go modifying the language? I'm just 
suggesting injecting of symbols that execute compiler side actions. Your 
suggesting language changes. Even if it is a new pragma.

> your samples can be built ontop of my "subcommand" proposal, for example.
> let's say that compiler will try to automatically do static import
> "DMD.subcommands.dub" when programmer writing something like
> `DMD.dub.Dependency("vibe-d", ">=0.7.22");`, falling back to "DMD.failure
> (name, args)" if there is no "dub" subcommand package.
>
> and then subcommand can execute dub, parse it's output and do what it
> wants. or one can make a local override for subcommand -- without even
> compiling separate plugin.
>
> that's how i see it.

We really need to toy with these ideas properly and implement each. Then 
its just a matter of time to convince the higher ups that it should be 
merged.



More information about the Digitalmars-d mailing list