DSSS 0.69 released.

[BCS]

Reply to Gregor,

> 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.
> 

As for using dsss as a build tool for my stuff; nothing
As for using it with 3rd party stuff; "dsss net" is useless on that systems 
and the only thing you could do about it is add something that would let 
me cache stuff on a thumb drive or something. That is a rare enough situation 
that I don't expect you to fix it.

>> 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.
> 

Well I hadn't tried it lately but last time I tried dsss, this didn't work:

download
extract
add to path
dsss net ...  ;gives error of some sort

>> 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/ ?
> 

 downloading now...

>> 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.
> 


Ahh... I was looking at that part more from the user standpoint. Maybe I'm 
strange but I really don't like using systems that I don't know what they 
are doing.

OTOH if dsss is going to rely take off, a user should be able to be using 
it 5min after first hearing that it exists. *Everything* they need to set 
up should be listed on the download page. If they forget to set it up, the 
error should tell them how to set it up and what it is.

I'm no half wit and every time I try dsss I get fed up with it before I figure 
it out (mostly because I can get everything but the net dependencies in shell 
scripts and that is easy enough for me that I get fed up really quick).

>> 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?

it's part of building the docs

> 
>> --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?

I get about 200 lines of output per build, lots of this fall into the TODO 
list, some of it is there to tell me what template are getting built, some 
of it is notes.

I want this output so tuning it off is not an option. But to use it I need 
to filter it to make stuff easier to find.

> 
>> --generate a list of functions selectively imported from std.* (find,
>> grep, sed, sort)
>> 
> ... why is this part of your build?

I want to known when I use new function (I'm trying to avoid gratuitous 3rd 
party dependencies)

> 
>> --build list of asserts without messages
>> 
> ... why is this part of your build?

I want to never use then

> 
>> --build list of debug sections without debug identifiers
>> 
> ... why is this part of your build?

I want to never use then (turn on all debug and I get ~1MB output per run)

> 
>> --build a command file that will turn on all debugging
>> 
> What do you mean by "command file" in this context?
> 

dmd @cmdfile

<file>
-debug=DebugFunctionFoo
-debug=DebugFunctionBar
...
</file>

>> --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.
> 

Would I have to call back into dsss? It would be nice to be able to say "also 
run a build with these args". This would also get the test version issue 
from below

>> --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?

some of each (and I want 2 executables every time, e.i. you can't build only 
one version)

> 
>> --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.
>> 

The reason for most of this is that I want to run the analysis etc. *every 
time*. I want to know when things break before the build's finished running 
(even when it's just forgetting a coding standard). I want the doc's to be 
up to date as of the last build *every time*.

This all boils down to "one step build" (I'd have the unittests and regression 
tests in there but they take to long to run). When I start having distros, 
I'll have the rpm/zip/tar.gz generation as part of that script (or DSSS if 
it can)

> 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.

If I don't need the analysis then the build step is:

build -v1 -full main.d

and dsss give me next to nothing. I want the "building the executable" step 
to be that simple. If it starts getting more complicated, I'll work hard 
to get it back to that. So dsss (for me from a developers standpoint) would 
end up being a fix for an error on my part.

Where dsss has the most to offer me is in the "other stuff" area.