A make pattern

test: run-test1 run-test2

.PHONY: run-test1
run-test1: test1.x
        ./test.x
test1.x: test1.cpp ...
        gcc -o test1.x test1.cpp ...

Of course, in a decent build system, this is a macro Build_Targets_For("foo.cpp"), rather than having to write them all out by hand. Scons may not be the best, but it avoids much clutter.

.x

I once gave a bad revioew to a UNIX book that suggested that executables should have a .x suffix.

But I find myself using the .x suffix, in large part because I want to automatically .hgignore (or .cvsignore, or ,gitignore) executables created by tests.

I *do* only tend to use .x for test executables. I prefer not to have to type in foo.x to use the tool foo. Although sometimes I will create a script foo that invokes foo.x.

I sometimes wonder about a suffix path as well as the directory path.

Wanted: per-directory .hgignore

One of my big complaints about Mercurial is that it only supports /.hgignore.

It does not support .hgnores in sub-directories.

I have a lot of legacy code with .cvsignores scattered around.  In CVS, when you move the directoriy from one place to another, the .cvsignores just work at the new location.  (Although moving the CVS directories around is a challenge.)  Whereas in Mercurial, wehen you move a subdirectory, you also need to go and fix any patterns in the project .hgignore.  :-(

Because of this, one is tempted to use patterns that are possibly too broad.  I have several times found myself .hgignorre'ing files in one part of the tree because they matched a pattern intended for a different part of the tree.

Status versus log

Many people - e.g. the people who want me to edit version control history - really want a status, rather than a log.

A log tends to record diffs. Deltas. Changes, What I did or am doing.

A log message for a version control system tends to describe what has changed between this and the last.

Note that a version control log is less complete than a human log.  A human log may describe what you tried, but which failed, and which you did not commit.  Sometimes I think it is as important to record that, as it is to record what worked well enough to release.

Oftentimes what people really want is a status.  "Here's the state of the project - this works, this does not".

Note that in a human log, sometimes you may step back and write a status.

Tools like hg bisect really want a status.  E.h. hg bisect only wants to attempt to test on versions that are known good - good enough to have run some sort of test in the past.

Statuses change.  "Passes all tests" may become false, if more tests are added.

Logs

I like keeping a manual log (journal or diary) as I go.

Logs want to be a meta-file concept.

E.g. I only want to edit and view one log.  I want to be able to track all of my work in a single place.

But, I also want to associate subsets of my overall log with particular projects.

E.g. I want to view log entries related to a project under ~/work/project/LOG.  But I want to view these, and all others, under ~/LOG.

Editing this in ordinary files sucks.  If I place it in a subdir/LOG I can't see it in ~/LOG, etc.

Suboptimal interactions with version control. I want version control for logs, but... Even if I am just working in projectdir/, editing projectdir/LOG, if I go off on a branch, edit projectdir/LOG, and switch back, I lose the log.  The log wants to transcend branches.

I have occasionally tried to work around this by placing all of my log in the ciommit log.  But that's not all that great an idea.

I wahnt as much automated log support, support for tracking personal history, as possible.

E.g. record the fact that I sent an email.

Automatically copy version control commit messages into my overall log.  But, of course, make everything filterable/foldable.