A question about modules - suggestion for convention

[Lutger]

Myron Alexander wrote:
> Perhaps for now, we could come up with a convention such as this:
> 
> All external libraries exist under an ext directory. The ext directory 
> has the following structure:
> 
> ext/<libname>/di/<toplevel>/...
> ext/<libname>/<libname>.lib
> 
> Then with the rebuild/bud/dmd tool or whatever, you could just have an 
> option such as -import=<libname> and it would add the .di to the include 
> path, and the .lib to the link path. This is a workable solution until 
> we get binary modules.
> 
> If that works, we could go to the next level where we zip up the 
> library. Same directory structure, just zipped up and call it .dlz for D 
> library zipped. Then the rebuild/bud or library tool could unzip the 
> contents into a temp/cache directory and add those directories/.libs to 
> the paths. It does not have to be built into bud/rebuild, it could be a 
> separate library tool that creates a few environment variables to add to 
> the bud/rebuild/dmd command line.
> 
> What do you think?
> 
> Regards,
> 
> Myron.

dsss is meant for this and I still think it fulfills it's purpose 
nicely. Rather than creating another convention, it is perhaps more 
effective to discuss what you find lacking in dsss and how to improve on 
that.

Keep in mind that dsss already does what you mentioned and a lot more 
too: install over the net (with automatic dependency installs), 
documentation generation with candydoc, pre- and post build steps... 
Only thing it doesn't do is hiding .di files for closed source 
distribution, but that will require another solution altogether.

I'm not used to Java style distribution, so I may miss something 
worthwhile here, but I find the D way not so problematic. It is 
certainly a lot better than C, and C++ too. This is largely because D 
has a true module system instead of text replacement, and tools like 
dsss, rebuild and bud are very good.