DIP11: Automatic downloading of libraries

Robert Clipsham robert at octarineparrot.com
Tue Jun 14 11:22:42 PDT 2011


On 14/06/2011 14:53, Andrei Alexandrescu wrote:
> http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
>
> Destroy.
>
>
> Andrei

This doesn't seem like the right solution to the problem - the correct 
solution, in my opinion, is to have a build tool/package manager handle 
this, not the compiler.

Problems I see:
  * Remote server gets hacked, everyone using the library now
    executes malicious code
  * Remote source changes how it is built, your code suddenly breaks and
    has to be updated, rather than being handled automatically
  * Adds a lot of unnecessary bloat and/or dependency on external modules
    + Want to compress source code? dmd now depends on decompression libs
    + Want to use git? dmd now depends on git
    + Remote code uses new compression method that an older dmd doesn't
      support
  * Remote server is down - build takes forever while waiting
    + Make dmd time out after a couple of seconds - build fails
  * Makes the assumption that the build machine is has internet
    connectivity, if it doesn't building suddenly gets a lot more
    complicated
  * Source code changes location, build breaks unless a redirect is
    possible - if it changes protocol it's useless

I could go on. I believe the real solution to this is to have (as 
discussed a lot recently) a proper D package management tool like PHP's 
pecl, ruby's gem or perl's cpan. Of course, this doesn't mean we have to 
lose the ability to list dependencies in D etc. In fact, it seems like 
the perfect opportunity to get people to switch to using D to build 
projects (everyone should, I do it and it's the best build tool I've 
*ever* used).

Hypothetical D Package Manager:
foobar
|
  ` pragma(depend, "foo", "v1.2.x");
  ` pragma(depend, "bar", "v1.4.3");

$ dpm install foobar
  -> Do packages exist locally, are they the right version?
  -> Do they exist remotely, and do the given versions exist?
  -> Get the remote packages
  -> Get the D Build Tool to build it (or use a binary, if available)
$ dbt build foobar
  -> Is there a default.dbt or foobar.dbt file?
  -> If not, attempt to build a binary, use -lib to attempt to build as
     a library
  -> If there is, pass it to dmd, it's actually a D file describing how
     to build

Of course, the dbt file would have access to some helper functions, eg 
library("myDir").build for building a library out of all the files in 
myDir (should be a way to specify the files etc). dbt would obviously 
take care of compiler flags/compiler etc.

I started implementing this the other day, got a few lines into a main() 
then realised I didn't have enough time to build the tool I wanted :>

-- 
Robert
http://octarineparrot.com/


More information about the Digitalmars-d mailing list