Chris Nicholson-Sauls wrote:
> 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

I was going to suggest that as well. I haven't used it before, but it does fit what Sean was looking, since its configuration files are python sripts.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:

> Chris Nicholson-Sauls wrote:
>> 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
> 
> I was going to suggest that as well. I haven't used it before, but it does fit what Sean was looking, since its configuration files are python sripts.
> 

I personally liked A-A-P better, also implemented in Python. It has a simple and powerful syntax for the common build tasks, but can also have inline Python code. It (together with SCons) never caught on for D due to the Python dependency. I suppose this would translate to using MiniD code inline in dsss scripts.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Lars Ivar Igesund wrote:

> Bruno Medeiros wrote:
> 
>> Chris Nicholson-Sauls wrote:
>>> 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
>> 
>> I was going to suggest that as well. I haven't used it before, but it does fit what Sean was looking, since its configuration files are python sripts.
>> 
> 
> I personally liked A-A-P better, also implemented in Python. It has a simple and powerful syntax for the common build tasks, but can also have inline Python code. It (together with SCons) never caught on for D due to the Python dependency. I suppose this would translate to using MiniD code inline in dsss scripts.
> 

When I do C/C++ development I usually use premake[1]. It's a neat little program that generates 1) a Makefile, 2) a MSVC project or 3) a Code::Blocks project from a Lua script.

I've always liked Lua, and having a complete scripting system available makes it really flexible. For example it's really easy to add custom command line options, or you can generate config header files etc. Not that I've really needed it for DSSS yet, but something similar could probably be a pretty useful addition.

[1]: http://premake.sourceforge.net/

Gregor Richards wrote:
> Mike Parker wrote:
>> Gregor Richards wrote:
>>
>>>
>>> As of 0.69, I will no longer be delivering binaries of rebuild alone - I have decided that doing so is backstabbing my own strategy. Instead, I'm providing a "light" binary of DSSS with no net support on Windows, where there are necessary prerequisite binaries for net support. It's only 300K bigger than the binary release of rebuild.
>>
>> Awww! I really have no interest in DSSS or any sort of DSSS-lite. I think Rebuild rocks, though. Having the binary available for download has been a great convenience. I wish you'd reconsider!
> 

The following rant caught my interest, because I don't exactly understand what is the usefulness of it (other than the rebuild component), so I decided to look into it.

> I wrote rebuild as a utility for use by DSSS. That was its primary purpose in existence. The fact that it can be useful in isolation is irrelevant.
> 
> 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've read:
http://svn.dsource.org/projects/dsss/trunk/docs/README.overview
and indeed the Building component (handled by rebuild I presume?) is definitely useful, as I'm sure there is no doubt.

As for the Installation component, well in either two cases:
If you just want to use the software (the binaries, not the source code), then OS facilities should be used to install/uninstall the software, not something as specific as DSSS.
If you want to use the software's source code, then you should be able to "install" it just by unpacking an archive file, and "unistall" it by deleting said archive/folder. As for dependencies, see bellow:

As for the Acquisition component (note, I'm not familiar with Perl's CPAN or Ruby's Gems) :
Again, if you just want to use the software, then OS-specific facilities should be used, otherwise it's just reinventing the wheel (is this even an intended use-case?)
If it's to mess around with the source, I am of the opinion that a given project distribution should have all of it's dependencies in the distribution as well (headers + binary libraries). For example my last C++ project had SDL, DevIL, GLUT, GLEW and some other deps all bundled in. It's just simpler that way. The only problem I see with this approach is redundant disk space, which is hardly significant.
The only scenerio I'm seeing where DSSS could be useful, is when I have project that *I* am developing (ie, not a third part project), that has a lot of dependencies, *and* where I would want to update those dependencies often during the course of development. And even then, it might be just as easy to have a shell script that downloaded the latest versions of said dependencies, and unpacked them.
So explain to me a scenario where DSSS is useful. :)

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Gregor Richards wrote:
>> Mike Parker wrote:
>>> Gregor Richards wrote:
>>>
>>>>
>>>> As of 0.69, I will no longer be delivering binaries of rebuild alone - I have decided that doing so is backstabbing my own strategy. Instead, I'm providing a "light" binary of DSSS with no net support on Windows, where there are necessary prerequisite binaries for net support. It's only 300K bigger than the binary release of rebuild.
>>>
>>> Awww! I really have no interest in DSSS or any sort of DSSS-lite. I think Rebuild rocks, though. Having the binary available for download has been a great convenience. I wish you'd reconsider!
>>
> 
> The following rant caught my interest, because I don't exactly understand what is the usefulness of it (other than the rebuild component), so I decided to look into it.
> 
>> I wrote rebuild as a utility for use by DSSS. That was its primary purpose in existence. The fact that it can be useful in isolation is irrelevant.
>>
>> 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've read:
> http://svn.dsource.org/projects/dsss/trunk/docs/README.overview
> and indeed the Building component (handled by rebuild I presume?) is definitely useful, as I'm sure there is no doubt.
> 
> As for the Installation component, well in either two cases:
> If you just want to use the software (the binaries, not the source code), then OS facilities should be used to install/uninstall the software, not something as specific as DSSS.

Okay, so you're volunteering to maintain the Debian packages for dmd and flectioned? :P

Eventually, I'll agree with you. But currently D is probably not popular enough to get maintainers for most Linux distributions. It's convenient to have a tool that works on any distro, even Windows, and contains only D packages (and a good selection of those) -- it's advertising as well as distribution.

> If you want to use the software's source code, then you should be able to "install" it just by unpacking an archive file, and "unistall" it by deleting said archive/folder. As for dependencies, see bellow:

That's slower than typing 'dsss net mango'. Most archives have a single folder in their root, but some are nasty and spew out a bunch of files into your current directory. Cleaning that up can be nasty. DSSS doesn't do that.

> As for the Acquisition component (note, I'm not familiar with Perl's CPAN or Ruby's Gems) :
> Again, if you just want to use the software, then OS-specific facilities should be used, otherwise it's just reinventing the wheel (is this even an intended use-case?)
> If it's to mess around with the source, I am of the opinion that a given project distribution should have all of it's dependencies in the distribution as well (headers + binary libraries). For example my last C++ project had SDL, DevIL, GLUT, GLEW and some other deps all bundled in.

This makes sure you always have compatible versions, but it means bugfixes don't get propagated in a timely fashion. That's why we have shared libraries on UNIX. (Windows has dlls, but every program seems to have all its dependencies with it, which results in things like Java exploits being impossible to secure against -- you have to update Java, and Lotus Notes, and a dozen other programs that bring their own JVM. Though I'm sure Lotus Notes wouldn't run on any JVM but the version that comes with it.)

DSSS solves this problem with less work for the package maintainers.

> It's just simpler that way. The only problem I see with this approach is redundant disk space, which is hardly significant.
> The only scenerio I'm seeing where DSSS could be useful, is when I have project that *I* am developing (ie, not a third part project), that has a lot of dependencies, *and* where I would want to update those dependencies often during the course of development. And even then, it might be just as easy to have a shell script that downloaded the latest versions of said dependencies, and unpacked them.
> So explain to me a scenario where DSSS is useful. :)
> 

Advertising. 'dsss net list' shows me a bunch of D software that I may not have heard of.

When I don't want to manually muck about with installing libraries. I use Linux; I am used to being coddled by package managers.

When I don't want to write an installer myself. Rebuild means my makefile's default rule can be one line; DSSS means that I don't have a makefile, and the dsss.conf file is much shorter. About as good as automake, but with a simpler syntax and shorter invocation. I don't type 'autoreconf -i; ./configure; make'; I just type 'dsss build'. And I only need the dsss.conf file, not configure.ac and Makefile.am.

When I want the installer to be portable. I don't use Windows at home; for me, a portable installer would be telling Windows users to install MinGW or Cygwin before installing my package. Or writing a C# application to do it, and that's too much work. Windows users probably have a majority here; just ignoring them isn't a good idea.

Responses inline. Beware extreme sarcasm.

Bruno Medeiros wrote:
> Gregor Richards wrote:
>> Mike Parker wrote:
>>> Gregor Richards wrote:
>>>
>>>>
>>>> As of 0.69, I will no longer be delivering binaries of rebuild alone - I have decided that doing so is backstabbing my own strategy. Instead, I'm providing a "light" binary of DSSS with no net support on Windows, where there are necessary prerequisite binaries for net support. It's only 300K bigger than the binary release of rebuild.
>>>
>>> Awww! I really have no interest in DSSS or any sort of DSSS-lite. I think Rebuild rocks, though. Having the binary available for download has been a great convenience. I wish you'd reconsider!
>>
> 
> The following rant caught my interest, because I don't exactly understand what is the usefulness of it (other than the rebuild component), so I decided to look into it.
> 
>> I wrote rebuild as a utility for use by DSSS. That was its primary purpose in existence. The fact that it can be useful in isolation is irrelevant.
>>
>> 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've read:
> http://svn.dsource.org/projects/dsss/trunk/docs/README.overview
> and indeed the Building component (handled by rebuild I presume?) is definitely useful, as I'm sure there is no doubt.
> 
> As for the Installation component, well in either two cases:
> If you just want to use the software (the binaries, not the source code), then OS facilities should be used to install/uninstall the software, not something as specific as DSSS.

In the rare case that that's easy and generic. That rare case being true, oh, 0% of the time.

There really is not an OS facility for installation that isn't a PITA. You notice that Makefiles just install with 'install', which makes non-uninstallable installations. Weeh. DSSS may maintain the manifest itself, but at least it /maintains the manifest/.


> If you want to use the software's source code, then you should be able to "install" it just by unpacking an archive file, and "unistall" it by deleting said archive/folder. As for dependencies, see bellow:

God I hate this logic. I've seen it so many times, and it doesn't get any less sensible.

1) Have fun doing that with tioport. Awesome for every SWT app to take ten minutes to compile because we're living in the pre-library stone ages.
2) Have fun doing that with derelict components. SDL-somefeature and SDL magically merge into one library, and without going and looking up which files are which, you can only uninstall the whole blob.
3) Have fun doing that with twenty dependencies. Lesse, this one is in a 'src' directory, this one is over in this corner but oh that actually needs to be installed from this directory, not that one, this one is -- ahh, fuck it, I just won't use any dependencies, I'll write the entire thing without using anything. OR, if those libraries used DSSS, I could either `dsss net deps` or build and install them in a CONSISTENT WAY. Consistency? Yes. Consistency. It's impossible to make tool builds and installs consistent with scripts or the "copy-and-paste to install" mindset.

Yes, in some limited cases this works. But it's hardly a generic solution - the generic solution should work for both simple and complex libraries, for both few and many dependencies. Boy, I wish somebody would write a tool like that! Oh yeah, somebody did - DSSS.


> 
> As for the Acquisition component (note, I'm not familiar with Perl's CPAN or Ruby's Gems) :
> Again, if you just want to use the software, then OS-specific facilities should be used, otherwise it's just reinventing the wheel (is this even an intended use-case?)

In the rare case that they're available, yes. It's primarily for libraries.


> If it's to mess around with the source, I am of the opinion that a given project distribution should have all of it's dependencies in the distribution as well (headers + binary libraries).

I'm inclined to respond with an insult. But I won't, because that's mean and a lot of D developers seem to be trapped in this ridiculous mindset. While I know you're never going to change your stance, I'm hoping that other readers will go "Oh, that makes sense" and not disown my methods because I'm a jerk.

Have fun maintaining ten branches because you're unwilling to handle dependencies properly. Oh, <X> fixed some file foo.d so that it works on Mac OS X now, I should retry <Y>! ARGH! Now I have to delete the version in the maintainer's archive, copy in the --- damn it, which derelict libraries were in there? Boy, I'm glad he just copies and pastes dependencies, makes my life a beautiful living hell.


> For example my last C++ project had SDL, DevIL, GLUT, GLEW and some other deps all bundled in.

Wow, that's disgusting and unmaintainable. Have fun following the changelogs for all of those and re-duplicating.


> It's just simpler that way.

Oh yeah, and also disgusting and unmaintainable. But yeah, simple.


> The only problem I see with this approach is redundant disk space

Sooo, maintaining what is effectively a zero-modification branch just takes disk space, no developer time or effort. Got it.


> , which is hardly significant.
> The only scenerio I'm seeing where DSSS could be useful, is when I have project that *I* am developing (ie, not a third part project),

So, not useful for the third party who would just like to build against the latest, presumably-least-buggy versions? Got it.


> that has a lot of dependencies, *and* where I would want to update those dependencies often during the course of development. And even then, it might be just as easy to have a shell script that downloaded the latest versions of said dependencies, and unpacked them.

$ dsss net deps
$ wc -l stupid_downloader_script.sh
103765


> So explain to me a scenario where DSSS is useful. :)
> 

Yeesh.

[Note to spectators: Gregor is not a crotchety old man. He is mean and sarcastic, but lives a happy life and is an optimist :P ]

 - Gregor Richards

"Bruno Medeiros" <brunodomedeiros+spam@com.gmail> kirjoitti viestissä news:f9hhen$18n8$1@digitalmars.com...
> I've read:
> http://svn.dsource.org/projects/dsss/trunk/docs/README.overview
> and indeed the Building component (handled by rebuild I presume?) is definitely useful, as I'm sure there is no doubt.
>
> As for the Installation component, well in either two cases:
> If you just want to use the software (the binaries, not the source code), then OS facilities should be used to install/uninstall the software, not something as specific as DSSS.
> If you want to use the software's source code, then you should be able to "install" it just by unpacking an archive file, and "unistall" it by deleting said archive/folder. As for dependencies, see bellow:
>
> As for the Acquisition component (note, I'm not familiar with Perl's CPAN or Ruby's Gems) :
> Again, if you just want to use the software, then OS-specific facilities should be used, otherwise it's just reinventing the wheel (is this even an intended use-case?)
> If it's to mess around with the source, I am of the opinion that a given project distribution should have all of it's dependencies in the distribution as well (headers + binary libraries). For example my last C++ project had SDL, DevIL, GLUT, GLEW and some other deps all bundled in. It's just simpler that way. The only problem I see with this approach is redundant disk space, which is hardly significant.
> The only scenerio I'm seeing where DSSS could be useful, is when I have project that *I* am developing (ie, not a third part project), that has a lot of dependencies, *and* where I would want to update those dependencies often during the course of development. And even then, it might be just as easy to have a shell script that downloaded the latest versions of said dependencies, and unpacked them.
> So explain to me a scenario where DSSS is useful. :)

[sarcasm]
And I bet version control should be done by tarring up the directory the code resides in and renaming it to <something>-<some version number>.tar[|.bz2|gz]. There's no way a program like CVS or SVN could be useful... and if they were useful, you shouldn't use them anyway, but depend on what the OS provides, if it provides any versioning capabilities at all...
[/sarcasm] 

Reply to Bruno,

> I've read:
> http://svn.dsource.org/projects/dsss/trunk/docs/README.overview
> and indeed the Building component (handled by rebuild I presume?) is
> definitely useful, as I'm sure there is no doubt.
> As for the Installation component, well in either two cases:
> If you just want to use the software (the binaries, not the source
> code), then OS facilities should be used to install/uninstall the
> software, not something as specific as DSSS.

Yes, at that point dsss isn't the right tool. (don't get me started, today’s installers are all jokes in one way or another)

> If you want to use the software's source code, then you should be able
> to "install" it just by unpacking an archive file, and "unistall" it
> by
> deleting said archive/folder. As for dependencies, see bellow:
> As for the Acquisition component (note, I'm not familiar with Perl's
> CPAN or Ruby's Gems) :
> If it's to mess around with the source, I am of the opinion that a
> given
> project distribution should have all of it's dependencies in the
> distribution as well (headers + binary libraries).

DSSS uses svn to download stuff. Unless you want to require that all svn repositories have all dependencies in them (bad idea) then you need to also do svn co on the decencies and that what DSSS does.

BCS wrote:
> Reply to Bruno,
> 
>> If it's to mess around with the source, I am of the opinion that a
>> given
>> project distribution should have all of it's dependencies in the
>> distribution as well (headers + binary libraries).
> 
> DSSS uses svn to download stuff. Unless you want to require that all svn repositories have all dependencies in them (bad idea) then you need to also do svn co on the decencies and that what DSSS does.

Actually, as long as the dependency is also in an svn repository, you can just use the svn:externals property on a directory to get subdirectories with the data in the other repositories (either the latest version or a specific one) when you check it out (or update).

Not that I'm recommending that, I'm just saying you don't need to actually copy the data over to your own repository to get that effect.

Reply to Frits,

> BCS wrote:
> 
>> Reply to Bruno,
>> 
>>> If it's to mess around with the source, I am of the opinion that a
>>> given
>>> project distribution should have all of it's dependencies in the
>>> distribution as well (headers + binary libraries).
>> DSSS uses svn to download stuff. Unless you want to require that all
>> svn repositories have all dependencies in them (bad idea) then you
>> need to also do svn co on the decencies and that what DSSS does.
>> 
> Actually, as long as the dependency is also in an svn repository, you
> can just use the svn:externals property on a directory to get
> subdirectories with the data in the other repositories (either the
> latest version or a specific one) when you check it out (or update).
> 
> Not that I'm recommending that, I'm just saying you don't need to
> actually copy the data over to your own repository to get that effect.
> 

good to known