DSSS and I
After Gregor stopped posting Rebuild binaries separately from DSSS, I downloaded the dsss-light version for Windows, which is DSSS without all of the net stuff. All I really wanted was access to the Rebuild executable without building it myself. I don't care how they do it in the Linux world, I want my binaries without having to compile them first, thank you.
So I don't really need, or want, DSSS to manage my libraries for me. I've got my own system that works just fine. That, actually, is one of the reasons I never bothered to use DSSS before nor wanted to use it when I downloaded it. I also didn't like that it generated .di files for everything. Nor did I like the idea that I had to learn how to create dsss.conf files in order to make it do what I wanted with my own projects. I was quite happy with using the simple response files I use for Bud and Rebuild.
Recently, I came to realize that it would be a good idea to add a dsss.conf file to the Derelict trunk. Since more and more people are using Tango with Derelict, and since the provided build script cannot be run by DMD when using Tango (at least on Windows, it has to be compiled into an executable first), DSSS seemed like it could potentially be a solution to the problem. So it was time to buckle down and dig into dsss.conf files.
As it turns out, creating a dsss.conf file is not nearly as complicated as the docs make it seem (Gregor did say doc writing isn't one of his strengths). It wasn't long before I had DSSS doing my bidding and building all of the Derelict libraries. There are still a few nits to work out, like I'm fairly certain that the DerelictSDL stuff is being compiled into every single DerelictSDL* library. I'd prefer that not to happen, but I haven't yet seen any obvious way to exclude entire packages (nor have I really dug around for one or asked Gregor). There's also a bug with library names that Gregor has already fixed for the next release. So when Gregor does release the next version, Derelict will be getting a dsss.conf file.
My intent was to provide dsss.conf alongside buildme.d, so that people who prefer can still run the build script. Some time ago I had refactored it to allow support for multiple build tools. That idea has now gone the way of the dodo, so I streamlined it and cleaned it up a bit just to support bud only. But now, I'm thinking, do I really need the build script? Providing two different methods of building the same project could potentially lead to confusion. I get enough confusion from just the single build script as it is. The majority of Derelict users don't bother reading the docs, judging by the majority of support requests I get in the forum. I may very well drop the build script and just require dsss if you want to build the libraries.
Today, I set some time aside to get started on the new, reinvented Smoothie. The first thing I would normally do is set up a couple of response files for Rebuild (or Bud as the case may be) for debug/release configurations. This time, I decided to go with a dsss.conf file instead. I still don't like that it generates .di files (is there a way to turn that off?) or creates extra files that I don't need, but it's not a big deal. Besides, a 'dsss distclean' solves that problem.
Still, if that were all, I'd see no real reason to give up Rebuild for DSSS. The big things for me are the ability to set up multiple builds in a single config file and the variety of hooks and commands available. I tend to configure my projects in such a way that I often have multiple test apps set up in their own packages. Using Rebuild or Bud, I'd need to configure a separate response file for each app. Also, I can already see how some of the hooks are going to be very useful for setting up a complex build process that involves manipulating more than just D source files.
I've said before in a NG post that DSSS solves problems I don't have. That's true, to an extent, but I see now that there's so much more to it than just library management and easy project compilation. To say I've warmed up to it is an understatement. I'll be replacing the response files for my game, and any other projects I have lying around, with DSSS configuration files. Color me converted.
Technorati Tags: D Programming Language, DSSS
September 13th, 2007 - 04:35
Let me respond to a few of your comments here.
“All I really wanted was access to the Rebuild executable without building it myself. I don’t care how they do it in the Linux world, I want my binaries without having to compile them first, thank you.”
And so, you downloaded the DSSS light binary. This is exactly what I was trying to encourage – I certainly wasn’t trying to encourage people to build it from source if they want it alone, I actually am not distributing the source separately either.
“I also didn’t like that it generated .di files for everything.”
These .di files are vital to how DSSS works. They associate imports with library files. This is why you don’t have to specify what libraries you want to link against when you use DSSS.
“As it turns out, creating a dsss.conf file is not nearly as complicated as the docs make it seem (Gregor did say doc writing isn’t one of his strengths).”
The docs make it seem complicated?
“There are still a few nits to work out, like I’m fairly certain that the DerelictSDL stuff is being compiled into every single DerelictSDL* library.”
They are not. DSSS uses the -explicit flag while building libraries, which means that only the files it lists will be built into them, not the dependencies.
(The entire next paragraph)
I should point out that a LOT of people are using Derelict through DSSS already, since I made it work with my evil magic.
“I still don’t like that it generates .di files (is there a way to turn that off?)”
To turn this off would be to subvert the entire purpose of DSSS. DSSS uses imports for all forms of dependencies – the .di files it makes associates those imports with libraries. Of course, I mentioned that above
Well, you can turn it off by just not building library files
“Color me converted.”
Thanks for the vote of confidence
September 13th, 2007 - 06:25
I certainly wasn’t trying to encourage people to build it from source if they want it alone
I didn’t mean to imply that
These .di files are vital to how DSSS works.
Even when it isn’t being used to manage libraries? If all I want to do is compile a lib externally to the management system (i.e., without ‘installing’ it), I really don’t need the .di files, do I? I’ve found, though, that I can use install to move the lib to a custom dir (rather than target) and then do a distclean.
The docs make it seem complicated?
Somewhat. The first time I skimmed through it just seemed that there was a lot going on. When I took the time to read more deeply, I had to go through a couple of times to grok it all. It could just be me, though
DSSS uses the -explicit flag while building libraries, which means that only the files it lists will be built into them, not the dependencies.
Cool. So only the modules in the package get compiled. That makes me very happy.
September 14th, 2007 - 19:47
Also, to exclude files and paths, I think you use something like
exclude=path/ path2/file.d
Not 100% if the above works, but look for ‘exclude’ in the dsss docs.