Make dub part of the standard dmd distribution

[Rikki Cattermole via Digitalmars-d]

On 2/06/2015 9:32 p.m., ketmar wrote:
> On Tue, 02 Jun 2015 21:12:14 +1200, Rikki Cattermole wrote:
>
>> I say wow.
>>
>> Okay not really I know it is possible and not all the hard. Personally I
>> think it is a rather an awesome possibility.
>
> adding some CTFE functions is not that hard at all. it's not documented,
> but one can look at "import()" and "pragma()" to see how they're doing
> their things and do the same. that's what i did, and it took me one day
> to write a working PoC.
>
> i promised to make a series of articles on that for TWiD, but still
> didn't done that. mea maxima culpa.
>
>
>> Really what I want is to add the ability to add on the compiler side
>> symbols that can be CTFE'd.
>> Registered at start of runtime.
>
> i'm afraid i didn't get it. can you provide a sample?
>
>
>> Add on shared library support and wamo. You can add stuff like this
>> pretty arbitrary :)
>
> you mean adding symbols with plugin-like system? i'm not sure that it
> will be easy. anyway, with well-defined CTFE API to access file system
> and execute commands (with restrictions, of course, so D programs will
> not go wild doing "rm -rf ~/" ;-) one can write modules that contains
> functions that acts like "filters", executing external binaries and
> massaging input/output.
>
> with some hooks added (like "call this CTFE function (if it present) when
> module importing fails") and ability to add -I/-J pathes in that hooks
> (restricted to some "library root dir") one can write "CTFE rdmd with
> automatic package downloading".
>
> i think i have to make a draft and PoC for that, so people can try it and
> see how k00l it is. ;-)
>

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.