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)?

Radio

First ;-) Hmmm, what else counts as a "tool"? Maybe if it interfaces well with a wiki? – Radio

If you are asking people to contribute to the chain, this needs to be community wiki – Pinstripe

You might like to add some sort of static analyser for security to nip some security issues in the bud, e.g. FlawFinder. – Meprobamate

Neil, can you please move it to the community wiki, then? thanks – Radio

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

Meprobamate

Good reply, and I do agree. In my case, it's a startup, so I can enforce a toolchain (mwuuuhahahaha!!!!) But I agree that different different tools might be better for different projects. I still like the idea of a "chain", where the tools actually interface with each other. Maybe I need to draw up a matrix of relationships (and allow free choice, per project, like a restaurant menu)? I also forgot requirements, anything else? Strange, I had expected many more replies to this.... – Radio

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.

Road

"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." I understand and agree, Norman, but Unix/Linux CLI gurus sure love that pipe, don't hey? I'm thinking of somethign the same where tools either export in one-another's file format, or invoke the other tool, or somehow couple. I like CLI, but can't avoid soem GUI tools.. – Radio

I like Emacs (or used to...). By project management, I mean project planning (taskJuggler, et al) but also project tracking, so plugging an issue tracker into PM s/w ... I'm looking for a web of interoperability (such as is more readily available with CLI and flat text data files) – Radio

Answer 3

Well its not FOSS but Rational supplies a complete tool chain (except for the compilers!),

You get IDEs, Class diagrams, use cases, requirements tracking, test tools, problem logging tools which integrate well all for a few thousand (or hundreds of) dollars.

None (aprt from the modeling tools) is best of breed, but, they are all pretty good and integrate well with each other.

Disclaimer:- My "toolset" of choice is vim,make, ddd, gmail and a moleskin notebook for modeling.

Sodality

Not so sure I want a single source, and I don't want non-FOSS, but thanks for pointing it out. – Radio

And thanks for reminding me of requirements tracking. – Radio

Are you joking about the moleskin notebook? – Waistcloth

Dont worry "moleskin" is a brand name! – Sodality