DSSS 0.69 released.
Bruno Medeiros
brunodomedeiros+spam at com.gmail
Fri Aug 10 04:17:48 PDT 2007
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
More information about the Digitalmars-d-announce
mailing list