[gsoc] DUB - Ideas

[sarn]

On Friday, 1 March 2019 at 01:38:13 UTC, H. S. Teoh wrote:
> On Thu, Feb 28, 2019 at 12:45:56PM -0500, Nick Sabalausky 
> (Abscissa) via Digitalmars-d wrote:
>> - This following workflow needs to be a BASIC STANDARD 
>> FULLY-ROBUST use-case with the same priority and importance as 
>> running "dub" to build a project: I have a non-DUB project and 
>> I want to include a library (say, Vibe.D) via DUB. I have my 
>> CLI command(s) to invoke the compiler, and all I have to do to 
>> use Vibe.d (or whatever) is insert this as part of my compiler 
>> invocation:
>> 
>> dmd blah blah `dub include vibe-d:~0.8.3` blah blah
>> 
>> And boom, -I... paths, libs, Have_vibe_d, etc., all guaranteed 
>> working, correct and ready to go.
>> 
>> At one point, I did a lot of work to make that happen, and I 
>> made some progress, but it was just so contrary to the way dub 
>> wanted to work I finally gave up.
> [...]
>
> I tried doing a non-dub project with dub dependencies before, 
> and ended up with so much frustration that I threw in the towel 
> and resorted to the hack of creating an empty dummy dub project 
> in a subdirectory, whose sole purpose was to declare dub 
> dependencies. I'd only run dub from the subdirectory when one 
> or more dependencies need to be updated, but the actual 
> compilation / linking is done by a different, sane build system 
> that pulls in the objects dub built.

I've also had this use case, and also ended up hacking around it 
using a dummy empty project.

I wrote a tool that parsed the output of "dub describe", but it 
only mostly works because that stuff is a confusing mess.