On 6/15/11 3:48 PM, Mike Wey wrote:
First i didn't read all of the posts in this thread, so some of these
might already be answered.
In the first paragraph the DIP talks about Automatic downloading of
*libraries* while all the posts here talk about downloading files.
This is also reflected in the "Package case" paragraph since the
compiler / separate tool will first try to download a .di file.
Which generally is a d import or header file, which doesn't need to
include the implementation, so the compiled library should also be
downloaded or linking would fail, right?
That is correct. We need to address the scenario in which a .di file
requires the existence of a .a/.lib file.
Also the proposal doesn't do anything with versioning, while larger
updates will probably get a different url, bug fixes might still
introduce regressions that silently break an application that uses the
library.
I think this is a policy matter that depends on the URLs published by
the library writer.
And now you'll have to track down witch library introduced the
bug, and more importantly your app broke overnight and while you didn't
change anything. (other that recompiling)
To find out how downloading the files would work i did some tests with
GtkD.
Building GtkD itself takes 1m56.
Building an Helloworld app that uses the prebuild library takes 0m01.
The Helloworld app need 133 files from GtkD.
Building the app and the files it needs takes 0m24.
The source of the HelloWord application can be found here:
http://www.dsource.org/projects/gtkd/browser/trunk/demos/gtk/HelloWorld.d
Thanks for the measurements. So my understanding is that the slow
helloworld essentially compiles those 133 files from GtkD in addition to
helloworld itself?
Thanks,
Andrei
