DIP11: Automatic downloading of libraries

[Nick Sabalausky]

"Nick Sabalausky" <a at a.a> wrote in message 
news:it8kkv$20hr$1 at digitalmars.com...
> "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
> news:it7pd2$2m07$1 at digitalmars.com...
>> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
>>
>> Destroy.
>>
>
> After all that talk about how we need to be very cautious about adding new 
> features to the compiler and work with the existing language whenever 
> possible, only a few days later now we're seriously considering adding an 
> entire *build system* to the compiler? And let's not fool ourselves: in 
> order for this not to be half-baked, it would have to completely take over 
> all the roles handled by a full-featured build-and-package-management 
> system.
>
> Just off the top of my head:
>
> - Putting it in the compiler forces it all to be written in C++. As an 
> external tool, we could use D.
>
> - By default, it ends up downloading an entire library one inferred source 
> file at a time. Why? Libraries are a packaged whole. Standard behavior 
> should be for libraries should be treated as such.
>
> - Are we abandoning zdmd now? (Or is it "dmdz"?)
>
> - Does it automatically *compile* the files it downloads or merely use 
> them to satisfy imports? If the latter, then the whole proposal becomes 
> pointless - you'll just need to tie it in with RDMD anyway, so you may as 
> well just keep it outside the compiler. If the former, then you're 
> implicitly having DMD creep into RDMD's territory - So either be explicit 
> about it and take it all the way putting all of rdmd into there, or get 
> rid of it and let the build tools handle package-management matters.
>
> - Does every project that uses libX have to download it separately? If not 
> (or really even if so), how does the compiler handle different versions of 
> the lib and prevent "dll hell"? Versioning seems to be an afterthought in 
> this DIP - and that's a guaranteed way to eventually find yourself in dll 
> hell.
>
> - How do you tell it to "update libX"? Not by expecting the user to 
> manually clear the cache, I hope.
>
> - With a *real* package management tool, you'd have a built-in (and 
> configurable) list of central data sources. If you want to use something 
> you don't have installed, and it exists in one of the stores (maybe even 
> one of the built-in ones), you don't have to edit *ANYTHING AT ALL*. It'll 
> just grab it, no changes to your source needed at all, and any custom 
> steps needed would be automatically handled. And if it was only in a data 
> store that you didn't already have in your list, all you have to do is add 
> *one* line. Which is just as easy as the DIP, but that *one* step will 
> also suffice for any other project that needs libX - no need to add the 
> line for *each* of your libX-using projects. Heck, you wouldn't even need 
> to edit a file, just do "package-tool addsource http://...". The DIP 
> doesn't even remotely compare.
>
> - I think you're severely overestimating the amount of extra 
> dmd-invokations that would be needed by using an external build tool. I 
> beleive this is because your idea centers around discovering one file at a 
> time instead of properly handling packages at the *package* level. 
> Consider this:
>
> You tell BuildToolX to build MyApp. It looks at MyApp.config to see what 
> libs it needs. It discovers LibX is needed. It fetches LibX.config, and 
> finds it's dependencies. Etc, building up a dependency graph. It checks 
> for any problems with the dependency graph before doing any real work 
> (something the DIP can't do). Then it downloads the libs, and *maybe* runs 
> some custom setup on each one. If the libs don't have any custom setup, 
> you only have *one* DMD invokation (two if you use RDMD). If the libs do 
> have any custom setup, and it involves running dmd, then that *only* 
> happens the first time you build MyApp (until you update one of the libs, 
> causing it's one-time setup to run once more).
>

Also, if you do want to throw away the "*.config" file (which might not be a 
good idea) and truly have "no editing needed" by inferring library 
dependencies from dmd's deps output, you still don't need a lot of extra dmd 
invokations: Just one extra deps-gathering invokation each time a 
deps-gathering invokation finds unsatisfied depenencies, and *only* the 
first time you build.

> I think this proposal is a hasty idea that just amounts to chasing after 
> "the easy way out".
>
>
>