Dub integrated into the compiler?

Kyoji Klyden via Digitalmars-d digitalmars-d at puremagic.com
Sun Oct 26 21:34:40 PDT 2014


On Monday, 27 October 2014 at 02:33:18 UTC, Tofu Ninja wrote:
> I don't think this is a new idea but it would be pretty awesome.
>
> So the idea is that the compiler could check dub for libraries 
> that it can't find and automatically download and integrate 
> them. It would essentially make all of dub seem like it was a 
> part of the standard lib and make integrating dub into projects 
> seamless.
>
> Something like "import derelict.opengl3.gl3;" could 
> automatically trigger dub if the import was not found on any 
> local path.
>
> It also might need some special syntax for version 
> specifications.
>
> It would require some work on both sides. Obviously the 
> compiler would need to change but dub would have to as well, I 
> don't think currently there is any way to look up a dub package 
> by an import statement alone.
>
>
>
> Pros:
> Greatly increase ease of dub use.
> Greatly increase libraries that "seem" to be a part of the std 
> lib.
> Would solve the large vs small stdlib dilemma.
>
> Cons:
> Could degrade perceived quality of stdlib if bad dub packages 
> got in.
> Would mean some things could not be compiled without an 
> internet connection.
>
> My answers to those cons would be
>
> 1)
> It might require some policing to make sure quality stays high.
> Maybe even with votes on what dub packages could automatically 
> be picked up by this similar to how packages get into phobos 
> but with a much lower bar.
>
> Also maybe a different import syntax for these imports to 
> clearly differentiate them so that we can draw a line between 
> the standard lib and dub. (personally I don't like that idea, I 
> like the idea of seamless integration)
>
> 2)
> Normal code would still compile like normal, this would only 
> open up the option of automatic library download for basically 
> the 99% of people who always have an internet connection.
>
>
>
>
> So yeah...
> Thoughts?

I'm against it. dub already tracks down libraries for you if need
them, and dub already calls dmd for you. So all this seems like
to me is calling dmd on the command line would just essentially
be calling dub.
I much rather have a clean distinction between the toolkit and
the compiler. Anyways, automating things just for the sake of
automating them isn't a very good idea. I'm mainly offset by the
idea that my compiler is chatting away with some server in hopes
of finding a missing library or file. Downloading whatever I need
and properly calling it is cleaner, safer, and more organized.

The idea sounds like in the end it would primarily just help
hobbyist or someone looking to just quickly prototype something.
So instead of fancying up/complicating dmd a better solution
would be to improve dub in someway, make a new tool, or if we
really have to do something to dmd then the solution that would
make the most people the happiest would be to allow plugins to
dmd or something, so if people want something like this then they
can add it and then grumpy people like me won't be bothered by it
;P


More information about the Digitalmars-d mailing list