Loading ...
Sorry, an error occurred while loading the content.

138435Re: [XP] Group vote for C unit testing framework

Expand Messages
  • stephendicks
    Jan 29, 2008
      --- In extremeprogramming@yahoogroups.com, David Carlton <carlton@...>
      wrote:
      >
      > On Tue, 29 Jan 2008 09:06:08 +1300 (NZDT), John Carter
      <john.carter@...> said:
      > > On Sun, 27 Jan 2008, David Carlton wrote:
      > >> On Mon, 28 Jan 2008 11:42:40 +1300 (NZDT), John Carter
      <john.carter@...> said:
      >
      > >>> Hint: Control of the build environment is handy. Instead of using
      > >>> "make" which doesn't really give you all that much you care about
      > >>> anyway...knock up your own using a rich scripting language like Ruby
      > >>> or Python.
      > >>
      > >> ? Make knows all about all sorts of handy dependency rules which are
      > >> very well suited for C and its derivatives; I wouldn't dream of
      > >> hand-rolling something else, if that's what you're suggesting. I
      > >> don't know what compiler the original poster is using, but GCC will
      > >> even spit out appropriate make dependencies, making it extremely easy
      > >> to write a safe, parallelizable Makefile for C code, in many common
      > >> situations.
      >
      > > Actually every large commercial make file I've seen has been about
      > > 20% make and a mish-mash of shell, awk, grep and other darker things
      > > (eg. .bat) for the rest. Trying to work out the various levels of
      > > quote stripping between make,shell and awk can be entertaining at
      > > the least!
      >
      > To give a bit more context, I'm rather fond of make, and part of the
      > reason why I'm fond is that I've spent time taking crap Makefiles and
      > turning them into Makefiles that are shorter, have fewer bugs, and are
      > more parallelizable. (With help from gcc -MD -MP and ideas in
      > <http://make.paulandlesley.org/autodep.html>.) At the core, it seems
      > to be a reasonable language for handling dependencies in a way that
      > can easily handle typical tasks for C and its derivatives on Unix
      > systems, which happens to be a situation where I spend some amount of
      > time.
      >
      > And, to give a bit more context, the only other build language that
      > I've used is ant (for a Java project); as far as I can tell, it gets
      > dependencies wrong, which I'd previously assumed was the single core
      > competency of anything that would call itself a build language. I
      > still tentatively assume that I must be missing something big there,
      > but I'm still a bit jaundiced towards other solutions. :-)
      >
      > Having said that, I should look at rake and scons; I agree that, all
      > else being equal, I'd like my build system to be integrated with a
      > pleasant scripting language, and make isn't that.
      >
      > John Roth mentioned rake and scons. Looking at the online
      > documentation, though, rake doesn't seem to be anywhere near ready for
      > prime time for C programming: I don't see any discussion of C issues,
      > and running "rake --help" doesn't mention anything about
      > parallelization, which would be an absolute show-stopper for me.
      >
      > scons looks more interesting, though: it looks rather more
      > fully-featured, the man page mentions parallelization, so it would
      > probably work. I don't know for sure if it will get automatic
      > dependency generation completely right, but it might, and even if it
      > doesn't, it might be close enough that its other virtues outweigh that
      > drawback. I would certainly play around with it, and (if the results
      > were good) it would be quite natural to use it if there was enough
      > Python knowledge on the project. (Or maybe even if there wasn't -
      > it's not like make gurus are falling off of every tree, after all.)

      I finally 'got around' to using Scons last year. Try it - you will
      never go back to 'make' again. The only drawback(s) that I've found so
      far are:

      Scons scripts are fully-fledged programs, so they can become overly
      complex (certainly my first attempts needed some refactoring, and my
      2nd and 3rd ones were improvements on the 1st).

      It is 'only' a build tool - you cannot trivially (at least I couldnt
      work it out) how to emulate 'make test' type behaviour where the tests
      are built and then run - I still used 'make' as a trivial controller.

      The documentation suggests a 'copy and build' approach, which works
      fine but can be confusing if you get a syntax error, as the 'compiled'
      source is a 'copy' (a writable copy at that) which should not of
      course be edited. [This style is not compulsory - a colleague used it
      by following the documentation]


      >
      > David Carlton
      > carlton@...
      >
    • Show all 19 messages in this topic