DSSS 0.69 released.

[Gregor Richards]

BCS wrote:
> I hear you; I'd love to use DSSS as described. However a few issues arise
> 
> 1. My primary dev systems are not connected to the internet (Not your 
> issue)
I fail to see what this has to do with anything.

> 2. The documentation is slim
I'm not good at documentation. There's really nothing I can do about 
that lack in my own person. Most documentation requests I've received, 
however, are for documentation that already exists.

> 3. Setting things up to use it isn't easy
Extract. Add to PATH. Make two-line dsss.conf file (for most stuff). 
You're right, complicated.

> 4. I want to do a lot more than just build apps and libs
> 
> For #2, I've tried it several times and can't seem to make it work. A 
> lot of this comes from the fact that I'm not totally clear on what how 
> it's supposed to work. A page with a how-to would be REALY nice.

http://www.dsource.org/projects/dsss/wiki/DSSSByExample ... I guess what 
you want is sort of a walkthrough?

http://www.codu.org/dsss_tutorials/ ?


> I'd 
> want one starting with "download this" and going though things like "put 
> filse ot build in line 27 of dsss.conf", "look at c:\foobar for you 
> libs" and "set setting baz to the directory where you want stuff to show 
> up".

Egad, you must think DSSS is incredibly complex >_O. Of all the 
dsss.conf files I've written, MAYBE one is 27 lines long - most are 
about two. You rarely have to list all of the files at all, and you 
never have to dig around somewhere to find libs.


> Ideally each step would include a section on what is happening and 
> such. That would also cover a lot of #3
> 
> as to #4, here is a list of things that my build scripts do that I 
> haven't heard DSSS can

First let me point out that DSSS has hooks (preinstall/postinstall, 
prebuild/postbuild, etc) to run any command at any point during the build.


> --run dimple to build import graphs

... why is this part of your build?


> --sort pragma(msg,"") output into memo, notice, error, diagnostic and 
> other categories (this is done with about 6 passes through grep/grep 
> -v/sort)

... why is this part of your build?


> --generate a list of functions selectively imported from std.* (find, 
> grep, sed, sort)

... why is this part of your build?


> --build list of asserts without messages

... why is this part of your build?


> --build list of debug sections without debug identifiers

... why is this part of your build?


> --build a command file that will turn on all debugging

What do you mean by "command file" in this context?


> --build full docs twice (.html + index and .tex + aggregator file)

DSSS can build DDoc documentation automatically. Other forms of docs can 
be built with a postbuild hook.


> --build test version of app

Not sure precisely what you mean by this - with a specific version flag 
to have testing stuff enabled, or with debug/unittests/etc enabled?


> --log most of this to a time stamped file
> 
> All of this is done with a build script that runs some stuff in the 
> background, ignores errors from some things, generates a return 
> condition for others. It is all a bash script that makes extensive use 
> of the "()" and "&" structures and a bunch f other stuff.

It sounds like the vast majority of your build script has nothing 
whatsoever to do with building, so having it in your build script is a 
bit ludicrous. It ought to be relegated to some sort of analysis script. 
Then, your (now-DSSS'd) build script would be platform-compatible and 
your analysis script, though not portable, wouldn't need to be.


> 
> It is also totally un-portable. If dsss could duplicate all of that and 
> be portable I would write you a testimonial that will make you look like 
> a saint (ok I exaggerate a little).
> 
> 

  - Gregor Richards