DIP11: Automatic downloading of libraries

[Nick Sabalausky]

"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).

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