www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DSSS 0.69 released.

reply Gregor Richards <Richards codu.org> writes:
DSSS, the D Shared Software System, is a tool to ease the building, 
installation, configuration and acquisition of D software.

Yet another mainly-bug-fix release. Here's the changelogs for 0.68-0.69:

0.69 from 0.68:
         - Added --test option to test built libraries.
         - Rebuild: Fixed an intermittent segfault on Windows.
         - Added --doc-binaries option to generate documentation for binary
           builds.
         - Fixed DSSS_Light build.

0.68 from 0.67:
         - Rebuild: -of<name> now converts / to \ on Windows (see ticket 

         - `dsss uninstall` now removes (empty) directories as well as files

         - Rebuild: Merged DMD 1.018.

         - /etc will now be preferred to /usr/etc when installing to the 
prefix
           /usr.



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.

As per usual, more information and downloads are available at 
http://www.dsource.org/projects/dsss/

  - Gregor Richards
Aug 03 2007
parent reply Mike Parker <aldacron71 yahoo.com> writes:
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!
Aug 04 2007
next sibling parent reply "Anders Bergh" <anders1 gmail.com> writes:
On 8/4/07, Mike Parker <aldacron71 yahoo.com> wrote:

 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!


DSSS comes with rebuild. OK, so you have DSSS installed too, but that
doesn't mean you have to actually use it :-)

-- 
Anders
Aug 04 2007
parent kenny <funisher gmail.com> writes:
Assuming you don't lose any functionality, I think it's a great idea to merge
it with dsss. Personally, will use it a lot more as time goes on. As an
example, I use php all the time, and having pear/pecl didn't hurt php at all,
but when I decided to try out xdebug or memcache bindings, it took like 5
minutes of my time. good stuff.

Anders Bergh wrote:

 On 8/4/07, Mike Parker <aldacron71 yahoo.com> wrote:

 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!


 
 DSSS comes with rebuild. OK, so you have DSSS installed too, but that
 doesn't mean you have to actually use it :-)
Aug 05 2007
prev sibling parent reply Gregor Richards <Richards codu.org> writes:
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!


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."

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.

</rant>

  - Gregor Richards
Aug 06 2007
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Gregor,


 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."
 
 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.
 
 </rant>
 
 - Gregor Richards
 


I hear you; I'd love to use DSSS as described. However a few issues arise

1. My primary dev systems are not connected to the internet (Not your issue)
2. The documentation is slim
3. Setting things up to use it isn't easy
4. I want to do a lot more than just build apps and libs


of this comes from the fact that I'm not totally clear on what how it's
supposed 
to work. A page with a how-to would be REALY nice. I'd want one starting 
with "download this" and going though things like "put filse ot build in 
line 27 of dsss.conf", "look at c:\foobar for you libs" and "set setting 
baz to the directory where you want stuff to show up". Ideally each step 
would include a section on what is happening and such. That would also cover 



heard DSSS can
--run dimple to build import graphs
--sort pragma(msg,"") output into memo, notice, error, diagnostic and other 
categories (this is done with about 6 passes through grep/grep -v/sort)
--generate a list of functions selectively imported from std.* (find, grep, 
sed, sort)
--build list of asserts without messages
--build list of debug sections without debug identifiers
--build a command file that will turn on all debugging
--build full docs twice (.html + index and .tex + aggregator file)
--build test version of app
--log most of this to a time stamped file

All of this is done with a build script that runs some stuff in the background, 
ignores errors from some things, generates a return condition for others. 
It is all a bash script that makes extensive use of the "()" and "&" structures 
and a bunch f other stuff.

It is also totally un-portable. If dsss could duplicate all of that and be 
portable I would write you a testimonial that will make you look like a saint 
(ok I exaggerate a little).
Aug 06 2007
next sibling parent reply Gregor Richards <Richards codu.org> writes:
BCS wrote:

 I hear you; I'd love to use DSSS as described. However a few issues arise
 
 1. My primary dev systems are not connected to the internet (Not your 
 issue)


I fail to see what this has to do with anything.


 2. The documentation is slim


I'm not good at documentation. There's really nothing I can do about 
that lack in my own person. Most documentation requests I've received, 
however, are for documentation that already exists.


 3. Setting things up to use it isn't easy


Extract. Add to PATH. Make two-line dsss.conf file (for most stuff). 
You're right, complicated.


 4. I want to do a lot more than just build apps and libs
 

 lot of this comes from the fact that I'm not totally clear on what how 
 it's supposed to work. A page with a how-to would be REALY nice.


http://www.dsource.org/projects/dsss/wiki/DSSSByExample ... I guess what 
you want is sort of a walkthrough?

http://www.codu.org/dsss_tutorials/ ?



 I'd 
 want one starting with "download this" and going though things like "put 
 filse ot build in line 27 of dsss.conf", "look at c:\foobar for you 
 libs" and "set setting baz to the directory where you want stuff to show 
 up".


Egad, you must think DSSS is incredibly complex >_O. Of all the 
dsss.conf files I've written, MAYBE one is 27 lines long - most are 
about two. You rarely have to list all of the files at all, and you 
never have to dig around somewhere to find libs.



 Ideally each step would include a section on what is happening and 

 

 haven't heard DSSS can


First let me point out that DSSS has hooks (preinstall/postinstall, 
prebuild/postbuild, etc) to run any command at any point during the build.



 --run dimple to build import graphs


... why is this part of your build?



 --sort pragma(msg,"") output into memo, notice, error, diagnostic and 
 other categories (this is done with about 6 passes through grep/grep 
 -v/sort)


... why is this part of your build?



 --generate a list of functions selectively imported from std.* (find, 
 grep, sed, sort)


... why is this part of your build?



 --build list of asserts without messages


... why is this part of your build?



 --build list of debug sections without debug identifiers


... why is this part of your build?



 --build a command file that will turn on all debugging


What do you mean by "command file" in this context?



 --build full docs twice (.html + index and .tex + aggregator file)


DSSS can build DDoc documentation automatically. Other forms of docs can 
be built with a postbuild hook.



 --build test version of app


Not sure precisely what you mean by this - with a specific version flag 
to have testing stuff enabled, or with debug/unittests/etc enabled?



 --log most of this to a time stamped file
 
 All of this is done with a build script that runs some stuff in the 
 background, ignores errors from some things, generates a return 
 condition for others. It is all a bash script that makes extensive use 
 of the "()" and "&" structures and a bunch f other stuff.


It sounds like the vast majority of your build script has nothing 
whatsoever to do with building, so having it in your build script is a 
bit ludicrous. It ought to be relegated to some sort of analysis script. 
Then, your (now-DSSS'd) build script would be platform-compatible and 
your analysis script, though not portable, wouldn't need to be.



 
 It is also totally un-portable. If dsss could duplicate all of that and 
 be portable I would write you a testimonial that will make you look like 
 a saint (ok I exaggerate a little).
 
 


  - Gregor Richards
Aug 06 2007
next sibling parent BCS <ao pathlink.com> writes:
Reply to Gregor,


 BCS wrote:
 

 I hear you; I'd love to use DSSS as described. However a few issues
 arise
 
 1. My primary dev systems are not connected to the internet (Not your
 issue)
 


 I fail to see what this has to do with anything.
 


As for using dsss as a build tool for my stuff; nothing
As for using it with 3rd party stuff; "dsss net" is useless on that systems 
and the only thing you could do about it is add something that would let 
me cache stuff on a thumb drive or something. That is a rare enough situation 
that I don't expect you to fix it.


 2. The documentation is slim
 


 I'm not good at documentation. There's really nothing I can do about
 that lack in my own person. Most documentation requests I've received,
 however, are for documentation that already exists.
 

 3. Setting things up to use it isn't easy
 


 Extract. Add to PATH. Make two-line dsss.conf file (for most stuff).
 You're right, complicated.
 


Well I hadn't tried it lately but last time I tried dsss, this didn't work:

download
extract
add to path
dsss net ...  ;gives error of some sort


 4. I want to do a lot more than just build apps and libs
 

 lot of this comes from the fact that I'm not totally clear on what
 how it's supposed to work. A page with a how-to would be REALY nice.
 


 http://www.dsource.org/projects/dsss/wiki/DSSSByExample ... I guess
 what you want is sort of a walkthrough?
 
 http://www.codu.org/dsss_tutorials/ ?
 


 downloading now...


 I'd want one starting with "download this" and going though things
 like "put filse ot build in line 27 of dsss.conf", "look at c:\foobar
 for you libs" and "set setting baz to the directory where you want
 stuff to show up".
 


 Egad, you must think DSSS is incredibly complex >_O. Of all the
 dsss.conf files I've written, MAYBE one is 27 lines long - most are
 about two. You rarely have to list all of the files at all, and you
 never have to dig around somewhere to find libs.
 



Ahh... I was looking at that part more from the user standpoint. Maybe I'm 
strange but I really don't like using systems that I don't know what they 
are doing.

OTOH if dsss is going to rely take off, a user should be able to be using 
it 5min after first hearing that it exists. *Everything* they need to set 
up should be listed on the download page. If they forget to set it up, the 
error should tell them how to set it up and what it is.

I'm no half wit and every time I try dsss I get fed up with it before I figure 
it out (mostly because I can get everything but the net dependencies in shell 
scripts and that is easy enough for me that I get fed up really quick).


 Ideally each step would include a section on what is happening and

 

 haven't heard DSSS can
 


 First let me point out that DSSS has hooks (preinstall/postinstall,
 prebuild/postbuild, etc) to run any command at any point during the
 build.
 

 --run dimple to build import graphs
 


 ... why is this part of your build?


it's part of building the docs


 

 --sort pragma(msg,"") output into memo, notice, error, diagnostic and
 other categories (this is done with about 6 passes through grep/grep
 -v/sort)
 


 ... why is this part of your build?


I get about 200 lines of output per build, lots of this fall into the TODO 
list, some of it is there to tell me what template are getting built, some 
of it is notes.

I want this output so tuning it off is not an option. But to use it I need 
to filter it to make stuff easier to find.


 

 --generate a list of functions selectively imported from std.* (find,
 grep, sed, sort)
 


 ... why is this part of your build?


I want to known when I use new function (I'm trying to avoid gratuitous 3rd 
party dependencies)


 

 --build list of asserts without messages
 


 ... why is this part of your build?


I want to never use then


 

 --build list of debug sections without debug identifiers
 


 ... why is this part of your build?


I want to never use then (turn on all debug and I get ~1MB output per run)


 

 --build a command file that will turn on all debugging
 


 What do you mean by "command file" in this context?
 


dmd  cmdfile

<file>
-debug=DebugFunctionFoo
-debug=DebugFunctionBar
...
</file>


 --build full docs twice (.html + index and .tex + aggregator file)


 DSSS can build DDoc documentation automatically. Other forms of docs
 can be built with a postbuild hook.
 


Would I have to call back into dsss? It would be nice to be able to say "also 
run a build with these args". This would also get the test version issue 
from below


 --build test version of app
 


 Not sure precisely what you mean by this - with a specific version
 flag to have testing stuff enabled, or with debug/unittests/etc
 enabled?


some of each (and I want 2 executables every time, e.i. you can't build only 
one version)


 

 --log most of this to a time stamped file
 
 All of this is done with a build script that runs some stuff in the
 background, ignores errors from some things, generates a return
 condition for others. It is all a bash script that makes extensive
 use of the "()" and "&" structures and a bunch f other stuff.
 




The reason for most of this is that I want to run the analysis etc. *every 
time*. I want to know when things break before the build's finished running 
(even when it's just forgetting a coding standard). I want the doc's to be 
up to date as of the last build *every time*.

This all boils down to "one step build" (I'd have the unittests and regression 
tests in there but they take to long to run). When I start having distros, 
I'll have the rpm/zip/tar.gz generation as part of that script (or DSSS if 
it can)


 It sounds like the vast majority of your build script has nothing
 whatsoever to do with building, so having it in your build script is a
 bit ludicrous. It ought to be relegated to some sort of analysis
 script. Then, your (now-DSSS'd) build script would be
 platform-compatible and your analysis script, though not portable,
 wouldn't need to be.


If I don't need the analysis then the build step is:

build -v1 -full main.d

and dsss give me next to nothing. I want the "building the executable" step 
to be that simple. If it starts getting more complicated, I'll work hard 
to get it back to that. So dsss (for me from a developers standpoint) would 
end up being a fix for an error on my part.

Where dsss has the most to offer me is in the "other stuff" area.
Aug 06 2007
prev sibling parent BCS <ao pathlink.com> writes:
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.
Aug 06 2007
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
BCS Wrote:



 heard DSSS can
 --run dimple to build import graphs
 --sort pragma(msg,"") output into memo, notice, error, diagnostic and other 
 categories (this is done with about 6 passes through grep/grep -v/sort)
 --generate a list of functions selectively imported from std.* (find, grep, 
 sed, sort)
 --build list of asserts without messages
 --build list of debug sections without debug identifiers
 --build a command file that will turn on all debugging
 --build full docs twice (.html + index and .tex + aggregator file)
 --build test version of app
 --log most of this to a time stamped file
 
 All of this is done with a build script that runs some stuff in the
background, 
 ignores errors from some things, generates a return condition for others. 
 It is all a bash script that makes extensive use of the "()" and "&"
structures 
 and a bunch f other stuff.
 
 It is also totally un-portable. If dsss could duplicate all of that and be 
 portable I would write you a testimonial that will make you look like a saint 
 (ok I exaggerate a little).
 
 


I once wrote a big Perl script (5 files!) which did everything from generating
code based on template files (I'm sure not as big a deal with D's insane
metaprogramming capabilities, but a huge deal when generating repetitive code
or code that needs to be synchronized across a lot of files for web programming
- the script would generate stylesheets, JavaScript and SVGs so that with a
change of a single file, the entire color scheme of the site could be changed)
to running the unit tests, pushing the nightly build out and generating reports
(I know CruiseControl and stuff can do that, but this way is more
customizable). It was a lot of work (8-10 hours of mucking about with Perl's
syntactical oddities), but the end result was well worth it, since I had a
portable and highly customizable build system.

There's simply no way to get this sort of power with a tool focused simply on
building. Even ant, with all its many extensions and its rather simple API
makes larger projects that require more than just compilation a nightmare. At
work, we have a set of eight Ant scripts averaging 10k, not to mention the 15+
taskdefs we have lying around... and still the push to the test environments is
done by a set of Perl, Ruby, Transact-SQL and bash scripts strung together
oddly.

DSSS looks like a great tool, and the net feature of it, which bears
similarities to CPAN, etc., looks like a great way to get dependencies. But as
far as building goes, I feel that build-focused tools should be better
integrated with scripting languages for larger projects. If DSSS had a Perl
interface, it's be perfect for me. 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.

I'm not actually working on a D project right now, so maybe DSSS is a "learn as
you try" thing, but the docs seem REALLY spotty, so that's the other thing
that's keeping me from embracing it.

But thanks, Gregor, for all your hard work!
Aug 06 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Robert Fraser wrote:

 There's simply no way to get this sort of power with a tool focused simply on
building. Even ant, with all its many extensions and its rather simple API
makes larger projects that require more than just compilation a nightmare. At
work, we have a set of eight Ant scripts averaging 10k, not to mention the 15+
taskdefs we have lying around... and still the push to the test environments is
done by a set of Perl, Ruby, Transact-SQL and bash scripts strung together
oddly.


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.


 DSSS looks like a great tool, and the net feature of it, which bears
similarities to CPAN, etc., looks like a great way to get dependencies. But as
far as building goes, I feel that build-focused tools should be better
integrated with scripting languages for larger projects. If DSSS had a Perl
interface, it's be perfect for me. 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.


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


Sean
Aug 06 2007
next sibling parent BCS <ao pathlink.com> writes:
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.
Aug 06 2007
prev sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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
Aug 06 2007
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Aug 07 2007
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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
Aug 07 2007
parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
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/
Aug 07 2007
prev sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
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.
Aug 06 2007
parent reply Gregor Richards <Richards codu.org> writes:
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
Aug 06 2007
parent reply Frank Benoit <keinfarbton googlemail.com> writes:
 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?
Aug 06 2007
parent Gregor Richards <Richards codu.org> writes:
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
Aug 06 2007
prev sibling next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
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.
Aug 06 2007
parent reply BCS <ao pathlink.com> writes:
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)
Aug 06 2007
parent Olli Aalto <oaalto gmail.com> writes:
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.
Aug 06 2007
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Aug 10 2007
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
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 

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.
Aug 10 2007
parent Witold Baryluk <baryluk smp.if.uj.edu.pl> writes:
Christopher Wright wrote:


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


I already created Debian packages for dmd, dmd2 and dsss...

http://movax.mpi.int.pl/d.php
Aug 11 2007
prev sibling next sibling parent reply Gregor Richards <Richards codu.org> writes:
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
Aug 10 2007
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Gregor Richards wrote:

 Responses inline. Beware extreme sarcasm.
 


Don't mind sarcasm as long as your arguments are clear.


 

 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.


Who said anything about compiling dependencies? That wasn't my 
intention, I did mention below that dependencies where in the form of 
"(headers + binary libraries)".


 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.
 


A project with *twenty* dependencies? Well, yes, in that case it's very 
likely DSSS would be quite useful, as I mentioned in my previous post.


 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.
 
 


Yes this is not a generic solution, and it isn't preferable for all 
cases. My contention is just on how often it is preferable or not. I 
would say it is more than just "in some limited cases".



 

 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.
 


Don't be so sure about my stance. I'm trying to understand more 
scenarios where DSSS would be clearly preferable.


 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.
 


Ten branches? You mean one branch for each dependency? Or you mean ten 
branches of your own project? What is <X> and what is <Y>? I don't 
understand that situation.


 

 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.
 
 


Why is it disgusting and unmaintable? Where would I re-duplicate? What's 
the trouble with following changelogs?


 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.
 


What do you mean a zero-modification branch?


 

 , 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.
 
 


If they wan't to use the latest, presumably-least-buggy versions, then 
just download the new library binaries and replace the old ones. That's 
in the case where there are no API changes of course.


 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
 
 


A download script with 103765 lines, right... Did you program an AI to 
download a file?
Right now I'm not imagining a download script more complex than either 
doing an svn/cvs checkout, or using wget to download an archive, and 
unpacking it. I'm not saying there wouldn't have to be more complex 
scripts, I'm saying I'm not imagining anything more complex.
Note that I'm talking about a script *specific* to a given project, made 
by the project's coders, not a generic script that would determine 
dependencies for any given project and download them (ie., dsss net in 
script form).


/* ----------  And now, on the binary installation issue  ---------- */



 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.


Rare case that they're available??... What kind of context are you 
talking about?? Maybe I'm hallucinating, but I find that most software 
(including libraries) has precompiled binaries for the common platforms 
(Windows, Linux, MacOS).


 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/.



"In the rare case that that's easy and generic." ? Again, what world do 
you live in?
Ever heard of an OS called Windows? Altough it sucks in a lot of things, 
it's software installation/uninstallation facility is not one of them. 
It's quite nice in fact. <sarcasm> There are also rumoreds sightings of 
mythical beasts such as "Gentoo" and "Ubuntu" which have proper OS 
installation facilities. They say they even allow uninstallation of 
software *gasp*. But like most legends, it's likely to fantasious to be 
true.... </sarcasm>.

Ok, seriously now. Make install?!? C'mon! Make install is not a facility 
for installation. Make install is not a proper facility for anything. 
Make install is an hack for OSes without proper install facilities, used 
by ugly and "hacky" software distributions who think that spreading 
seven pieces of the software across different locations in one's 
computer is a good thing.
Yes, this might go against traditional UNIX wisdom, but, as you can see, 
there are many things in this traditional "wisdom" I don't like, 
particularly with regards to file system structure.


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



 Aug 11 2007



prev sibling next sibling parent  "Rioshin an'Harthen" <rharth75 hotmail.com>  writes:


"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] 



 Aug 10 2007



prev sibling  parent reply BCS <ao pathlink.com>  writes:


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.



 Aug 10 2007



  parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl>  writes:


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.



 Aug 10 2007



  parent  BCS <ao pathlink.com>  writes:


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



 Aug 10 2007