Seeking a true "tool-chain" [closed]

Question

I just posted this as part of a reply to a question about the "best" bug-tracking software...

---

Well, a tool on its own is just a tool. And while all speak of a toolchain, most just mean a loose collection of tools. Why not look for a problem tracker that "plays well with other children"? That is to say, interfaces well with your IDE, your build tool, your version control system ...

In fact, I think I'll go now and ask a question about the best linked toolchain ...

---

So, any comments? I would prefer replies for developing C/C++ on Linux and using FOSS (but don't let that prevent you posting Windows based answers if you think that it would help someone else). We don't need a complete chain, but maybe a few groups of linked tools are still better than totally separate "links" in the chain)

I use

• Eclipse - for coding and debugging, also its plug-ins for
  • Doxygen for auto code-documentation
  • Splint and CppCheck for static code analysis
  • CppUnit for automated testing
  • Bugzilla, et all for bug tracking
  • CVS, Subversion, etc, for version control
• Hudson - for automated builds, with plug-ins for
  • Doxygen for auto code-documentation
  • CppCheck for static code analysis
  • CppUnit for automated testing
  • Bugzilla, et all for bug tracking
  • CVS, Subversion, etc, for version control

I seem to be missing a tool for project management which interfaces with other "links" in the toolchain. How complete can we make it, end to end, and is there a "best" chain (or, at least, one with the most links)?

Edit: Let's not forget requirements tracking and project planning & tracking - end Edit

And has anyone every diagrammed the relationship between various tools (i.e., which interfaces to which, and in which direction; which can export in the import format of another, etc)?

Answer 1

G'day,

In my experience, I have found that trying to come up with a "definitive" tool chain can cause problems.

One of the worst is that it tends to force people into the "everything looks like a nail" approach to projects. That is, You've done the work to select the tools you think are suitable and you now have your tool suite.

In my experience, it is very difficult to get people to change their "canonical set" of tools for other projects once that tool set has been selected and annointed as such.

I've been doing this for over twenty years now in a variety of projects that ranged from on-board submarine sonar simulators to air-traffic control display systems to helicopter control systems. Even within the same company, different projects need different tool sets to address the various problems that are going to be encountered.

You might think that once you've selected a tool for a particular purpose then you can re-use that tool for all projects, e.g. your selection of BugZilla for bug tracking. But what if there is no suitable SMTP server available because you've got a distributed team and your mail server is internal, locked down, secure, for example.

I'd suggest that it would be better to establish a suite of possible tools from which you can select your project's tool suite from. For example, adding Trac or FogBuzz as a possible bug tracking mechanism.

A lot of things can affect your choice of tools. Off the top of my head I've got:

• geographical distribution of teams,
• internal lock down, i.e. no public access, of servers e.g. email, source repository, test platform, etc,
• having to interface to some existing system because of a desire to reuse aspects of that system, e.g. previous teams had had VisualSourceSafe inflicted upon them,
• customer insistence on the use of a particular platform,
• the management team for a new project having requirements that differ from the previous management team for regular management type reports,
• etc.

Having a suite of possibilities minimises the effect of "trying to squeeze a square peg into a round hole".

Anyway, you might find that you're able to trim down your suite of possibilities after a while because you can demonstrate a successful approach and so get enough traction within the company for the support of doing things the way you've previously done them.

HTH

Answer 2

I think the Unix philosophy militates against these kinds of tightly integrated toolchains. It's no accident that Eclipse, the first thing you mention, came from the Java world. Unix (and by extension, Linux) tends to believe less in things called "plugins" and more in sets of tools that share data stored in flat text files.

By "project management" I'm not sure if you mean something like Make or something to keep track of your team's progress. If you mean something like Make, the Unix world sorely needs a reusable Make that supports "smart recompilation" and will work with multiple compilers. The closest thing is Glenn Fowler's nmake, but that's not very close.

Regarding integrate toolsets more generally,

• The best set of tools I've seen are the Advanced Software Technology tools built at AT&T. There's a most excellent book Practical Reusable Unix Software, free to download, which describes the state of play circa 1995. Since then the toolset has only gotten better and richer, but to get an overview of what the hell is going on, you really need the book. These guys started with the Unix group at Bell Labs, and what they've created is not so much a toolchain but a way of life. Joe Bob says check it out.

• The other ubiquitous element in many Unix toolchains is (and this is likely to make you laugh or puke) Emacs. Although Emacs Lisp is not anyone's favorite way to write plugins or extensions, sheer accumulation over time has made Emacs into a very rich, powerful programming environment—and it talks to all sorts of other tools. I'm into simplicity, not complexity, so I try to keep to shallow water, but if you're serious about investigating toolchains for Unix, it's something to know about.

I'm looking forward to seeing more answers to your question.