Reply to Sean,

> Robert Fraser wrote:
> 
> True enough.  One of the larger projects I have worked on builds tools
> in one part of the build process (including a compiler) and uses the
> tools later in the build process.  These tools in turn may generate
> code and other data used even further on in the same build.  Then
> things are published, tested, etc.  However, this is beyond what I'd
> expect of DSSS.
> 

Ahh, that brings back memories of one of my projects.

.
.
.

Most of what I want could be had by:

Allowing repeat builds of a single app with different args
File streams w/ filters
Foreach

The first would let me build several sets of docs

The second would let me do the logging I want. As for filtering; grep, sort and uniq would be enough for a lot of power. Sed would be nice for some of the other stuff.

The foreach would run a given command on every .d file that is "used".

> Good point.  I guess solid scripting support would go a long way
> towards supporting custom build options.  Perhaps MiniD would be
> useful here.
> 
> Sean
> 


All out scripting would be nice. 

Robert Fraser schrieb:
> As it is, when I get to working on a D project, I plan to invoke DSSS from within the script to do the actual build and let the script handle the things surrounding it.

Yes, I think this also. I found the 'rake' tool to be a good scripting/gnu-make alternative which also works good on win32. From there I can call dsss.

Sean Kelly wrote:
> Robert Fraser wrote:
> 
> Good point.  I guess solid scripting support would go a long way towards supporting custom build options.  Perhaps MiniD would be useful here.
> 
> 
> Sean

Hmm.. A la SCons, perhaps?
http://www.scons.org/

SCons actually supports D already, and prior to the existance of Build/Bud that was what I used.  However, its a Python application (hence its scripting capability), and so useless if you don't have Python installed.

I'm sure with MiniD in hand we could do at least as well... and possibly even better.

-- Chris Nicholson-Sauls

Frank Benoit wrote:
> Robert Fraser schrieb:
>> As it is, when I get to working on a D project, I plan to invoke DSSS
>> from within the script to do the actual build and let the script
>> handle the things surrounding it.
> 
> Yes, I think this also. I found the 'rake' tool to be a good
> scripting/gnu-make alternative which also works good on win32.
> From there I can call dsss.

If you're referring to Tioport/SWT, FYI I'm about 115% convinced from what I've seen that DSSS can trivially do everything you're doing with rake.

 - Gregor Richards

> If you're referring to Tioport/SWT, FYI I'm about 115% convinced from what I've seen that DSSS can trivially do everything you're doing with rake.
> 
>  - Gregor Richards

how would that look like?

Frank Benoit wrote:
>> If you're referring to Tioport/SWT, FYI I'm about 115% convinced from
>> what I've seen that DSSS can trivially do everything you're doing with
>> rake.
>>
>>  - Gregor Richards
> 
> how would that look like?

Admittedly, I'm not entirely sure of everything that goes on in the rakefile, but something like this:


requires = bintod
defaulttargets = tioport dejavu

[tioport]
type = subdir

[dejavu]
type = subdir

version (linux) {
    []
    defaulttargets += swt-3.2.1-linux-gtk/src
    [swt-3.2.1-linux-gtk/src]
} else version (darwin) {
    []
    defaulttargets += swt-3.2.1-macosx/src
    [swt-3.2.1-macosx/src]
} else version (Windows) {
    []
    defaulttargets += swt-3.2.1-win32/src
    [swt-3.2.1-win32/src]
}
type = subdir
buildflags = -I../../dejavu



Mind, this doesn't include the steps for generating SWT (though I explicitly set up defaulttargets so that you could make targets for them without those targets always running), but it should allow a simple 'dsss build' to get everything that's generally useful.

 - Gregor Richards

Gregor Richards wrote:
> Mike Parker wrote:

> 
> Statements like this annoy me to no end. I create this tool that integrates and standardizes all sorts of things and makes the whole situation of using 3rd party libraries infinitely easier with D, and everybody goes, "Hey, look, it works with a build utility that works well. Let's use that and not the tool itself. I have no interest because I don't know what it does and I'm happy with copying all my libraries into the same directory as the modules for my binary in a gigantic mess of unmaintainable code. Oh, and including obnoxious and platform-specific build scripts that use rebuild rather than DSSS, a tool for making easy and cross-platform build scripts, is brilliant."

I understand what DSSS does, and for those who like it, fine. I just personally don't. I'm obviously not the target audience. I do prefer to manage the libraries I use myself. I keep them all in a nice, neat, global import directory. I can build with DMD, Tango, Rebuild, Bud, or GDC (if I set it up) without needing to muck about with any configuration files. It's a simple system and isn't broken for me, so I get no benefit from DSSS.

My intent was not to annoy you, but to let you know that I think Rebuild rocks. That's a tool I find particularly useful as it matches my needs perfectly.
> 
> This puts me into a chicken-and-egg scenario. DSSS is most useful when many available D libraries support it, but the developers for many of the D libraries continue to maintain incompatible and difficult-to-use build scripts (or, worse yet, encourage duplication), which degrades its usefulness. When I started seeing build scripts that actually used rebuild, that's when I decided I'm not going to distribute rebuild in isolation.
> 
> I don't consider people who use rebuild in isolation to be valid consumers of my code, and I'm not going to actively support that configuration. Yes, it will still work (rebuild isn't going away any time soon, it is indeed a necessary component of DSSS), but I'm not actually going to create bundles which /encourage/ people to not use the software that rebuild was built to support. Honestly, I have no idea why I was ever doing that in the first place.
> 

Too bad you feel that way. I'll continue to be an invalid user of your code, whether you make the binary available or not. A great tool is a great tool.

The short version:

The only thing dsss will provide me is "dsss net *". And that is only of use for other peoples programs which I use vary few of. Everything I want to do for my programs I can get from bud/rebuild all by it's self or can't get from dsss at all.

Reply to Mike,

> I understand what DSSS does, and for those who like it, fine. I just
> personally don't. I'm obviously not the target audience. I do prefer
> to manage the libraries I use myself. I keep them all in a nice, neat,
> global import directory. I can build with DMD, Tango, Rebuild, Bud, or
> GDC (if I set it up) without needing to muck about with any
> configuration files. It's a simple system and isn't broken for me, so
> I get no benefit from DSSS.
> 

I use bud, but we see to think a lot alike.

At this point dsss isn't for me, but it looks like a great starting poit for a tool I /would/ use. 

I've already posted my feature request list, what would dsss have to offer for you to want to use it? (anyone else chime in as well)

BCS wrote:
> Reply to Mike,
> 
>> I understand what DSSS does, and for those who like it, fine. I just
>> personally don't. I'm obviously not the target audience. I do prefer
>> to manage the libraries I use myself. I keep them all in a nice, neat,
>> global import directory. I can build with DMD, Tango, Rebuild, Bud, or
>> GDC (if I set it up) without needing to muck about with any
>> configuration files. It's a simple system and isn't broken for me, so
>> I get no benefit from DSSS.
>>
> 
> I use bud, but we see to think a lot alike.
> 
> At this point dsss isn't for me, but it looks like a great starting poit for a tool I /would/ use.
> I've already posted my feature request list, what would dsss have to offer for you to want to use it? (anyone else chime in as well)
> 
> 

Well it already does everything I need, and probably more. I think that dsss is *the* tool for building D applications/libraries at the moment.

Whenever there is a new version of it, all I have to do is to download it, unpack, run couple 'dsss net install' commands to install the needed derelict packages and I'm set. Pretty much all my coding time goes to doing the nehe tutorials, so for those I've set myself up so that I have one dsss build script for all of the tutorials. I can do 'dsss build' and it builds all of them, or 'dsss build lesson01/lesson01.d' and it builds only that lesson. At the moment I don't need anything else. When adding a new lesson I'll just add two lines to the dsss.conf and I'm ready to build it.

In the past I've done other projects and they've been a breeze to build just because dsss does all of the micromanagement for me. I don't have to waste my time with make/build/rebuild/whatnot.

Just my 2c.

O.