DSSS 0.69 released.

[Christopher Wright]

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.