Commits on Jan 11, 2011
  1. Fix use of in example

    rkuester committed Jan 11, 2011
Commits on Jan 4, 2011
  1., minimal/do: don't use ansi colour codes if $TERM is blank or …

    Apparently emacs sets TERM=dumb in its tty simulator, so even though
    isatty() returns true, we shouldn't use colour codes.  (emacs is therefore
    lame. But we knew that.)
    apenwarr committed Jan 4, 2011
  2. Use named constants for terminal control codes.

    (apenwarr slightly changed the minimal/do tty detection.)
    Screwtapello committed with apenwarr Jan 4, 2011
Commits on Jan 2, 2011
  1. redo-sh: keep testing even after finding a 'good' shell.

    Otherwise we miss out on seeing the results from additional tests.
    apenwarr committed Jan 2, 2011
  2. wrap long lines.

    apenwarr committed Jan 2, 2011
  3. Handle .do files that start with "#!/" to specify an explicit interpr…

    Now you can have your .do files interpreted by whatever interpreter you
    apenwarr committed Jan 2, 2011
  4. bash completions: also mark 'do' as a completable command.

    (ie. minimal/do)
    apenwarr committed Jan 2, 2011
  5. bash completions: work correctly when $cur is an empty string.

    Otherwise 'cd t/defaults-flat' then 'redo <tab>' doesn't show all the
    possible targets.
    apenwarr committed Jan 2, 2011
  6. bash completions: call redo-targets for a more complete list.

    Also fix handling of filenames needing quoting (like "t/space dir"),
    directories, and targets named after directories.
    apenwarr committed Jan 2, 2011
Commits on Jan 1, 2011
  1. minimal/do: faster deletion of stamp files.

    "while/read/printf | xargs -0" is much faster than while/read/rm, because it
    doesn't fork so many times.
    apenwarr committed Jan 1, 2011
  2. minimal/do: use ".did" stamp files instead of empty target files.

    If runs and creates no output, we shouldn't create a file called
    'all', but we should remember that 'all' has been run successfully.  We do
    this by creating 'all.did' during the build.
    Since minimal/do always just wipes everything out every time it runs, we can
    safely remove the .did files after minimal/do terminates, so this doesn't
    clutter things too much in normal use.
    This fixes some edge cases, particularly that 'minimal/do clean' no longer
    leaves stupid files named "clean" lying around, and the redo-sh directory
    can now be rebuilt correctly since we rebuild it as long as redo-sh.did
    doesn't exist.  (We don't want to "rm -rf redo-sh" because it makes me
    apenwarr committed Jan 1, 2011
  3. minimal/do: use posix shell features instead of dirname/basename.

    This avoids a few forks, and is a good example of how to do some "modern" sh
    programming.  Plus we now use fewer lines of code.
    apenwarr committed Jan 1, 2011
Commits on Dec 21, 2010
  1. Automatically select a good shell instead of relying on /bin/sh.

    This includes a fairly detailed test of various known shell bugs from the
    autoconf docs.
    The idea here is that if redo works on your system, you should be able to
    rely on a *good* shell to run your .do files; you shouldn't have to work
    around zillions of bugs like autoconf does.
    apenwarr committed Dec 21, 2010
Commits on Dec 19, 2010
  1. Move some of the tests from t/ into t/defaults-flat.

    This lets us move t/ out of the way; it was confusing otherwise.
    apenwarr committed Dec 19, 2010
  2. Don't update the database during redo-ood.

    Makes it slightly faster.
    apenwarr committed Dec 19, 2010
  3. Add a new redo-ood command.

    Prints the list of existing but out-of-date targets.
    apenwarr committed Dec 19, 2010
  4. Move dependency checking from redo-ifchange into

    In preparation for sharing between multiple commands.
    apenwarr committed Dec 19, 2010
  5. New redo-sources and redo-targets commands.

    Suggested by djb in personal email, and on the mailing list.  redo-targets
    lists all the targets in the database; redo-sources lists all the existing
    sources (ie. files that are referred to but which aren't targets).
    redo-ifcreate filenames aren't included in the redo-sources list.
    apenwarr committed Dec 19, 2010
  6. Rename redo-oob to redo-unlocked, to more accurately represent its use.

    It's still undocumented.  Because you shouldn't run it by hand.  So don't!
    It's dangerous!
    apenwarr committed Dec 19, 2010
  7. Add Documentation/git-{import,export}.do scripts.

    These export and import, respectively, the generated man pages to/from the
    git branch called 'man'.  You can use it to retrieve the .1 files if you
    don't have a working pandoc.
    apenwarr committed Dec 19, 2010
Commits on Dec 17, 2010
Commits on Dec 16, 2010
Commits on Dec 15, 2010
  1. Release minimal/do to the public domain.

    This makes it more convenient if you really want to include it as the build
    script for your own projects.
    apenwarr committed Dec 15, 2010
  2. Fix a couple of typos in the README.

    Jonathan Wakely committed with apenwarr Dec 15, 2010
Commits on Dec 14, 2010
  1. stub /usr/bin programs: be smarter about finding the libdir.

    We were hardcoding the absolute $LIBDIR location, which sounds smart, but not if
    you're doing "make install" into a temp dir that will end up somewhere else
    Instead, look for ../lib/redo/ from wherever the binary is installed.
    apenwarr committed Dec 14, 2010
  2. Switch to using a separate lockfile per target.

    The previous method, using fcntl byterange locks, was very efficient and
    avoided unnecessarily filesystem metadata churn (ie. creating/deleting
    inodes).  Unfortunately, MacOS X (at least version 10.6.5) apparently has a
    race condition in its fcntl locking that makes it unusably unreliable
    My tests indicate that if you only ever lock a *single* byterange on a file,
    the race condition doesn't cause a problem.  So let's just use one lockfile
    per target.  Now "redo -j20 test" passes for me on both MacOS and Linux.
    This doesn't measurably affect the speed on Linux, at least, in my tests.
    The bad news: it's hard to safely *delete* those lockfiles when we're done
    with them, so they tend to accumulate in the .redo dir.
    apenwarr committed Dec 14, 2010
  3. Assert that one instance never holds multiple locks on the same file …

    …at once.
    This could happen if you did 'redo foo foo'.  Which nobody ever did, I
    think, but let's make sure we catch it if they do.
    One problem with having multiple locks on the same file is then you have to
    remember not to *unlock* it until they're all done.  But there are other
    problems, such as: why the heck did we think it was a good idea to lock the
    same file more than once?  So just prevent it from happening for now,
    unless/until we somehow come up with a reason it might be a good idea.
    apenwarr committed Dec 14, 2010
Commits on Dec 12, 2010