On Thu, 19 Apr 2007 00:47:48 +0200, Frank Benoit (keinfarbton) wrote:

> I think it can be helpful if bud would integrate into DSSS, and the user can choose via a DSSS configuration.

Yes, that makes a lot of sense.
-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
19/04/2007 9:38:05 AM

Derek Parnell wrote:
> On Wed, 18 Apr 2007 21:06:09 +0200, Frank Benoit (keinfarbton) wrote:
> 
>> Why not help DSSS instead of compete?
>> I really see no advantage in competition in a little community like this.
> 
> I have no opinion about DSSS yet. I was talking specifically about Rebuild
> only. 
> 
> But why compete, well why have GDC then? And in any case, Bud existed prior
> to Rebuild so I guess it would be unusual for me to say "Somebody has
> created another application that does the same task as mine so I better
> stop working on mine now."
> 
> As Gregor has said, he started Rebuild because he, and others, were unhappy
> that I couldn't meet their needs in the timeframe that was acceptable. I
> believe this is reasonble justification for starting up a competitive
> application.
> 
> A little healthly competition can, and probably will, provide the D
> community with two or more excellent choices, each with a particular
> feature set more suitable to one situation over another situation.
> 
> Bud is fairly mature and stable and Rebuild is getting that way quickly.
> The D community will benefit from this. At the moment, Bud supports DMD
> better than GDC and Rebuild is the other way round (I think). Bud is
> written in D and Rebuild in C++, and that might be a relevent point of
> differentiation for some users. Bud does not yet support Tango and Rebuild
> does. etc ...
> 
> Should I stop working on Bud and begin helping Gregor improve Rebuild? I
> don't think so. Not yet anyway.
> 


Hear, hear!

 - Gregor Richards

Frank Benoit (keinfarbton) wrote:
> Derek Parnell schrieb:
>> But why compete, well why have GDC then? And in any case, Bud existed prior
>> to Rebuild so I guess it would be unusual for me to say "Somebody has
>> created another application that does the same task as mine so I better
>> stop working on mine now."
> 
> Sure, i can understand that.
> 
> I think it can be helpful if bud would integrate into DSSS, and the user
> can choose via a DSSS configuration.
> 
> It would be really great (and REAL man like) if you both can cooperate
> in this point. :)
> 

Absolutely. I don't think it's good that DSSS depends absolutely on rebuild, with no alternative. But making it a bit more alternative-friendly hasn't been high on my priority list ^^

 - Gregor Richards

PS: Are you mocking my common misuse of the phrase "REAL men do <something real men don't do>"? :-P

Since many of the responses to this thread suggested that people don't understand why DSSS is useful above just a build tool like bud or rebuild. I've created a basic DSSS-by-example page, to describe why DSSS is useful, and what advantages it gives the user. It needs more work, but is a good start.

http://www.dsource.org/projects/dsss/wiki/DSSSByExample

 - Gregor Richards

Thanks, I've been looking for something like that. I didn't quite
'get' DSSS, but I do use rebuild as a bud replacement. I should
probably use DSSS for my new Lua bindings, so they are net
installable.

On 4/19/07, Gregor Richards <Richards@codu.org> wrote:
> Since many of the responses to this thread suggested that people don't
> understand why DSSS is useful above just a build tool like bud or
> rebuild. I've created a basic DSSS-by-example page, to describe why DSSS
> is useful, and what advantages it gives the user. It needs more work,
> but is a good start.
>
> http://www.dsource.org/projects/dsss/wiki/DSSSByExample
>
>   - Gregor Richards
>


-- 
Anders

Gregor Richards wrote:

> Since many of the responses to this thread suggested that people don't understand why DSSS is useful above just a build tool like bud or rebuild. I've created a basic DSSS-by-example page, to describe why DSSS is useful, and what advantages it gives the user. It needs more work, but is a good start.
> 
> http://www.dsource.org/projects/dsss/wiki/DSSSByExample
> 
>   - Gregor Richards

Thanks this documentation cleared up a lot of things.

I have a few questions thou, either this was not documented or I could not find it. Overall dsss was much more compleat than I thought.

1.
how is libs with subdirs handled?

//example directory structure
mylib/
        lib.d
        file.d
        subdir/
                somefile.d
                someother.d
        anotherdir/
                anotherfile.d

If building a .a library will the files in the subdirs be compiled, and if
so when are they included?
(if I don't import them with a version flag?)

2.
Where does dsss net deps install the deps,
current dir or globally, (configurable)?

3.
The pre/post instal/uninstal/clean are they target specific or common to the
entire file.

4.
Is it possible to build a specific target from a file instead of all of them
(as if specifying make targetname).

5.
How is library dependencies specified in the dsss file.

Thanks in advance.

Gregor Richards wrote:
> Since many of the responses to this thread suggested that people don't understand why DSSS is useful above just a build tool like bud or rebuild. I've created a basic DSSS-by-example page, to describe why DSSS is useful, and what advantages it gives the user. It needs more work, but is a good start.
> 
> http://www.dsource.org/projects/dsss/wiki/DSSSByExample
> 
>  - Gregor Richards

OK, I think I've got a clearer idea of what DSSS is for now, although I have a few questions:

1. What exactly does 'dsss install' do on Windows?  I mean, I realise that linux has standard directories for libraries and binaries, but where does it stick these things for Windows?

2. In addition, does 'dsss build' build everything all at once?  If so, is there any way to specify that you only want a particular target built?

3. I use an awful lot of version statements to control tracing code, experimental code, etc.  Can I pass version flags to the compiler from the command line (I know about buildflags in the dsss.conf file, but I don't want to have to edit that just to add some tracing code for a quick run).

4. I also noticed the bit on special build steps prefixed by a '+': do you trigger these from the command line like so: 'dsss build +foo'?

5. Related to the above, is there any way to add one of these special build steps from another one (ie: chain them together)?

6. I realise this isn't in DSSS' job description, but do you have any plans to add support for transforming files?  The major part of my work at the moment deals with source files that need to be pre-processed before being fed to the D compiler.  Having a build tool able to call the processor on-demand only when it's needed would be a *massive* help--about 80-90% of the current build time is just my crummy shell script checking to make sure no source files need to be processed...

7. Can we Windows users get a list of what command-line programs DSSS depends on?  I don't think I ever finished tracking down all the utilities DSSS kept trying to call last time I tried to use it...

DSSS is actually looking pretty close to what I'm rigging up with bud at the moment.  Plus, the whole net install thing is cool :P

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Answers posted inline. I will use some of these questions for a FAQ when I make one.

Johan Granberg wrote:
> Gregor Richards wrote:
> 
>> Since many of the responses to this thread suggested that people don't
>> understand why DSSS is useful above just a build tool like bud or
>> rebuild. I've created a basic DSSS-by-example page, to describe why DSSS
>> is useful, and what advantages it gives the user. It needs more work,
>> but is a good start.
>>
>> http://www.dsource.org/projects/dsss/wiki/DSSSByExample
>>
>>   - Gregor Richards
> 
> Thanks this documentation cleared up a lot of things.
> 
> I have a few questions thou, either this was not documented or I could not
> find it. Overall dsss was much more compleat than I thought.
> 
> 1.
> how is libs with subdirs handled?
> 
> //example directory structure
> mylib/
>         lib.d
>         file.d
>         subdir/
>                 somefile.d
>                 someother.d
>         anotherdir/
>                 anotherfile.d
> 
> If building a .a library will the files in the subdirs be compiled, and if
> so when are they included?
> (if I don't import them with a version flag?)

I've improved README.software_engineers to answer this question:

Sections creating libraries from directories will normally include all the .d
files in that directory or any subdirectory of it. You may also specify
subdirectories explicitly in dsss.conf, which will cause some .d files to be
reassigned. For example, if you have these files:
dzip/algorithm.d, foo/compression/zip.d
and a section:
[dzip]
then the produced library will include algorithm.d and zip.d.
If you have two sections:
[dzip]
[dzip/compression]
then two libraries will be produced: The library from 'dzip' will contain
algorithm.d, and the library from [dzip/compression] will contain zip.d.

> 
> 2.
> Where does dsss net deps install the deps, current dir or globally, (configurable)?

From README.use:

Some software can be used directly after building, but most software, libraries
in particular, expect to be installed somewhere. DSSS can install software to
any directory you choose, but will default to its own directory.


> 
> 3.
> The pre/post instal/uninstal/clean are they target specific or common to the
> entire file.

I've made this a bit more explicit in README.software_engineers (I hope :) ):

* prebuild, preinstall, preclean, postbuild, postinstall, postclean
  * Commands to be run before/after building/installing/cleaning the current
    section.

> 
> 4.
> Is it possible to build a specific target from a file instead of all of them
> (as if specifying make targetname).

I had neglected to mention this in README.use. It is now present:

You can build only a specified target by simply adding it to the command line:
$ dsss build dzipper


> 
> 5.
> How is library dependencies specified in the dsss file.

In general, they're not. Every package installable via DSSS-net has its list of modules well-defined, so `dsss net deps` merely needs to trace dependencies. I've made this explicit in README.software_engineers:

There is also a global setting, "requires", which may be used to explicitly
list dependencies:
requires = bintod
In general, it is NOT necessary to use this setting, as DSSS will detect
dependencies based on what is imported from the D source.

 - Gregor Richards

Answers posted inline. I will use some of these questions for a FAQ when I make one.

These questions are bizarrely similar to Johan's ... :)

Daniel Keep wrote:
> Gregor Richards wrote:
>> Since many of the responses to this thread suggested that people don't
>> understand why DSSS is useful above just a build tool like bud or
>> rebuild. I've created a basic DSSS-by-example page, to describe why DSSS
>> is useful, and what advantages it gives the user. It needs more work,
>> but is a good start.
>>
>> http://www.dsource.org/projects/dsss/wiki/DSSSByExample
>>
>>  - Gregor Richards
> 
> OK, I think I've got a clearer idea of what DSSS is for now, although I
> have a few questions:
> 
> 1. What exactly does 'dsss install' do on Windows?  I mean, I realise
> that linux has standard directories for libraries and binaries, but
> where does it stick these things for Windows?

From README.use:

Some software can be used directly after building, but most software, libraries
in particular, expect to be installed somewhere. DSSS can install software to
any directory you choose, but will default to its own directory.


> 
> 2. In addition, does 'dsss build' build everything all at once?  If so,
> is there any way to specify that you only want a particular target built?

Added to README.use:

You can build only a specified target by simply adding it to the command line:
$ dsss build dzipper


> 
> 3. I use an awful lot of version statements to control tracing code,
> experimental code, etc.  Can I pass version flags to the compiler from
> the command line (I know about buildflags in the dsss.conf file, but I
> don't want to have to edit that just to add some tracing code for a
> quick run).

From `dsss --help` (admittedly not the best place for it :) ):

All other options are passed through to rebuild and ultimately the compiler.

So just adding -version=Foo is sufficient.

> 
> 4. I also noticed the bit on special build steps prefixed by a '+': do
> you trigger these from the command line like so: 'dsss build +foo'?

Yes.


> 
> 5. Related to the above, is there any way to add one of these special
> build steps from another one (ie: chain them together)?

There is not at present any way of specifying such a dependency, no. Perhaps I should add that...


> 
> 6. I realise this isn't in DSSS' job description, but do you have any
> plans to add support for transforming files?  The major part of my work
> at the moment deals with source files that need to be pre-processed
> before being fed to the D compiler.  Having a build tool able to call
> the processor on-demand only when it's needed would be a *massive*
> help--about 80-90% of the current build time is just my crummy shell
> script checking to make sure no source files need to be processed...

I'm a bit loathe to add anything like this ... I'd recommend setting it up something like this:

A non-preprocessed source directory, which creates a preprocessed source directory. The preprocessed source directory will have an appropriate dsss.conf added to it. In the base dsss.conf:

[+preprocess]
prebuild = preprocess.d

[preprocessed]
type = subdir


> 
> 7. Can we Windows users get a list of what command-line programs DSSS
> depends on?  I don't think I ever finished tracking down all the
> utilities DSSS kept trying to call last time I tried to use it...

All the software DSSS depends on come in the DSSS binary tarball (I missed this in one release, but it should be in all the current ones), and are retrievable by running getwinbins.d (which is run automatically if you build dsss with itself).

> 
> DSSS is actually looking pretty close to what I'm rigging up with bud at
> the moment.  Plus, the whole net install thing is cool :P
> 
> 	-- Daniel
> 

 - Gregor Richards

Gregor Richards wrote:
>> 
>> 5.
>> How is library dependencies specified in the dsss file.
> 
> In general, they're not. Every package installable via DSSS-net has its list of modules well-defined, so `dsss net deps` merely needs to trace dependencies. I've made this explicit in README.software_engineers:
> 
> There is also a global setting, "requires", which may be used to
> explicitly list dependencies:
> requires = bintod
> In general, it is NOT necessary to use this setting, as DSSS will detect
> dependencies based on what is imported from the D source.
> 
>   - Gregor Richards

I'm still not clear on how does this work with external c libraries?

Otherwise your answers made it a lot clearer. If it continues like this dsss will have great documentation in no time :)