Make dub part of the standard dmd distribution

[ketmar via Digitalmars-d]

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.


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.

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

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150602/097517e2/attachment.sig>