www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: DIP11: Automatic downloading of libraries

reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Andrei Alexandrescu Wrote:

 http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
 
 Destroy.
 
 
 Andrei

I'm in agreement with those saying it doesn't belong in the compiler/language. In order for it to make sense in this location it would need to take on of a build tool role, which has already be stated to add cause more confusion when something goes wrong. How confusing is it to say, DMD downloads required modules for you, but will fail to build an executable because you must tell it to use those files. Sure using rdmd is to provide a seamless experience, but this results in more back and forth between compiler and build tool. Then there is the caching issue. The proposal has no solution on this, and for good reason. The goal isn't to cache it is to install the library, meaning it is persistent and usable by other projects. Installing a library can involve many things, and especially for D can mean compiling C or installing libraries. This solution is looking at a smaller scope, but I don't think it really saves on a "configuration" file. On a note about build tools. I'm like you and Walter in that they always seem so complicated and very fragile. And personally go with simple Makefiles. I'm not really familiar with the problems many of these tools are trying to solve. I was reading up on redo, and whether it was intended or not, I found one idea that really stuck with me. File transformation operations. Make does a really nice job of dependency resolution and I think this idea of taking a list of dependencies and transforming them into another file makes simple files. So to do an incremental build for D: .o: .d dmd -c $2 : .o dmd -of$3 $2 mytarget: target.d depended.d on.d files.d Ok, I haven't gone into depth with what build tools should also be solving, or how to get it working. but this is just my initial "hey I want that."
Jun 14 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/14/11 1:14 PM, Jesse Phillips wrote:
 Andrei Alexandrescu Wrote:

 http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11

 Destroy.


 Andrei

I'm in agreement with those saying it doesn't belong in the compiler/language. In order for it to make sense in this location it would need to take on of a build tool role, which has already be stated to add cause more confusion when something goes wrong. How confusing is it to say, DMD downloads required modules for you, but will fail to build an executable because you must tell it to use those files. Sure using rdmd is to provide a seamless experience, but this results in more back and forth between compiler and build tool.

I agree that if this makes it through, we need to have a means to instruct dmd to also include the module in the build.
 Then there is the caching issue. The proposal has no solution on this, and for
good reason. The goal isn't to cache it is to install the library, meaning it
is persistent and usable by other projects.

I used "caching" informally and I mentioned the liabilities of using e.g. /tmp/ for it. CPAN uses a similar technique, it puts installed libraries in a dir dictated by PERL5LIB. We should devise a similar method.
 Installing a library can involve many things, and especially for D can mean
compiling C or installing libraries. This solution is looking at a smaller
scope, but I don't think it really saves on a "configuration" file.

I agree there are libraries that won't be automatically installable with this feature.
 On a note about build tools. I'm like you and Walter in that they always seem
so complicated and very fragile. And personally go with simple Makefiles. I'm
not really familiar with the problems many of these tools are trying to solve.

 I was reading up on redo, and whether it was intended or not, I found one idea
that really stuck with me. File transformation operations. Make does a really
nice job of dependency resolution and I think this idea of taking a list of
dependencies and transforming them into another file makes simple files. So to
do an incremental build for D:

 .o: .d
      dmd -c $2

 : .o
      dmd -of$3 $2

 mytarget: target.d depended.d on.d files.d

 Ok, I haven't gone into depth with what build tools should also be solving, or
how to get it working. but this is just my initial "hey I want that."

I use rdmd in conjunction with small makefiles too. I think the proposal complements such approaches. Andrei
Jun 14 2011