On 03/11/2010 12:11 PM, Ellery Newcomer wrote:
So I'm toying with a prototype, which is proving nice enough, but there be a few things that I'm not quite sure which way to go with.
I was eagerly waiting for you to get back regarding this project. Thank you!
Currently I have the general pattern dmdz [global flags] foo1.zip [foo1 local flags] foo2.zip [foo2 local flags] ... although when given multiple zips it just compiles them independently. My thought was when fooi.zip compiles a lib file, the result should be made available to all subsequent zip files, so you could do something like dmdz lib1.zip lib2.zip main.zip where lib2 can depend on lib1 and main can depend on either lib. But then most if not all of lib1's flags need to be forwarded to lib2 and main. The other alternative I thought of is all the zip files get extracted and then all compiled at once. Or is multiple zip files even a good idea?
To me this looks like a definite V2 thing honed by experience. For now the focus is distributing entire programs as one zip file.
For the more specific case dmdz [global flags] foo.zip [local flags] it expects all the relevant content in foo.zip to be located inside directory foo, and doesn't extract anything else unless you explicitly tell it to.
I don't understand this. Does the program foo.zip have to contain an actual directory called "foo"? That's a bit restrictive. My initial plan revolved around expanding foo.zip somewhere in a unique subdir of the temp directory and considering that a full-blown project resides inside that subdir.
Also, there can be a file 'cmd' (name?) inside foo.zip which contains additional flags for the compile, with local flags overriding global flags overriding flags found in cmd. At least for dmdz flags.
How about dmd.conf?
dmd flags get filtered out and forwarded to dmd. The current strategy for compiling just involves giving every compilable thing extracted to dmd. There's also an option to compile each source file separately (which I put in after hitting an odd Out of Memory Error). Comments?
That sounds about right. One thing I want is to stay reasonably KISS (e.g. like rdmd is), i.e. not invent a lot of arcana. rdmd has many heuristics and limitations but has the virtue that it gets a specific job done without requiring its user to learn most anything. I hope dmdz turns out similarly simple.
Also, are there any plans for std.zip, e.g. with regard to ranges, input/output streams, etc? The current api seems a smidge spartan.
I've hoped to rewrite std.zip forever, but found no time to do so. Andrei
