Best Builder to Use
eris
jvburnes at gmail.com
Fri Mar 12 09:20:25 PST 2010
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?
More information about the Digitalmars-d
mailing list