Hi all I'm trying to finish up a 0.9 release of a new open source package that's taken a fair amount of my spare time lately, but I can't seem to get it past the final build stage.
- I'm using linux and recent versions of ldc, tango and Descent. I'm using D language 1.x. - I was using simple build scripts, then simple make files, then DSSS, but now I've run into a problem. - Part of my code creates a fairly flexible class factory that allows you do select a component to build at runtime. This is critical for the dynamic nature of the app. The code uses a mixin to configure the factory at compile time, depending on the "blueprints" that I want the factory to use. - DSSS can't "see through" the mixin to the dependencies it creates at compile-time. - I could manually build/link the unbuilt code, but I might as well go back to scripts at that point. - DSSS doesn't look like it's being maintained (which brings up another subject, I'll avoid here). - DSSS isn't documented well enough to even figure out if I could force the dependencies. That gives me a few options: 1. Stop using mixins. If DSSS can't figure it out, maybe it's bad programming practice. Not a particularly attractive option for my application. If Descent can see the dependencies, why can't DSSS? 2. Use some other method to pre-configure the factories other than manually coding them every time. (Possible, though mixins seemed to be the best way.) 3. Use a different build engine. At the moment that looks like 'rebuild', 'bud', 'xfbuild', make, cmaked and a few others. So this is where I'm at. The code is just now becoming complex enough that a complete tool set will be required, so I want to take some time for this decision. Here are my thought's so far.. a) xfbuild and dsss are similar. Perhaps xfbuild could see the dependency. If I could get a sense of committment of the developer and it's capabilities I might use it (especially if it worked with linux and ldc). Is there a way to force dependencies in DSSS or xfbuild? If so, I haven't seen them. b) Auto build tools like DSSS are great when they work, but useless if they can't see a critical dependency. Which makes me lean towards 'makefile' generators like cmake. If the D module for cmake can't see a particular dependency, at least I could force the issue in the generated makefile. Only issue with cmaked is that it looks like it hasn't been maintained in a long time either. How many changes to D have occurred since then? c) Plain makefiles by hand. Sometimes the most obvious is the best and I could probably get by using a makefile for a little longer, but it's not particularly conducive to rapid development right now. In short, I don't mind hacking together a toolset, but there comes a time when you are spending more time hunting down and hacking tools than programming your application. It's all fun, but I'd like to keep up a modicum of productivity. Any thoughts? BTW: For all of the development I've done so far, I'd like to thank the devs and tool teams that have held up so far... a) Walter, of course for the language. It's amazing what he's been able to do without funding from a major corp for this work. b) The LDC/LLVM team. Wonderful compiler. It would be nice if it was available for the Windows guys (maybe it is now). c) Team Tango. You have such a wide variety of tools and algorithms that occasionally I write an obscure little class only to find out you've already written it for me. d) everyone else who contributes. D is a great language. Everything we contribute adds to the critical mass. e) is there any way in which we can get the more critical core tools funded at least a little bit? Maybe some sort of "street performer" protocol, donations, university tenure for core D developers, Google summer of code contributions?
