"Nick Sabalausky" <a@a.a> wrote in message news:it8kkv$20hr$1...@digitalmars.com... > "Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message > news:it7pd2$2m07$1...@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". > > >