One of my usual mantra is "untested software doesn't work".
Applies to everything including my own code.
Case study: new update-plist has interesting heuristics to figure out where
to put variables in lists.
Specifically, for each entry, it keeps track of the original line from
the old plist BEFORE variable substitution, e.g.,
e.g.,
lib/python2.7/site-packages/lzo.so
and matching
lib/python${MODPY_VERSION}/site-packages/lzo.so
In one of the recent changes, I decided to try to get some info from
directories as well, so that a new
lib/python2.7/site-packages/lzo2.so
would still get the
lib/python${MODPY_VERSION}/site-packages
part, even if the file didn't previously exist.
A bit tricky, so I decided to add a debugging assert, namely for each entry,
the unsubstituted string should match, e.g.,
if we have s=lib/python2.7/site-packages/lzo2.so
unsubst=lib/python${MODPY_VERSION}/site-packages
then apply substitution again to unsubst and check
that subst=lib/python2.7/site-packages
is indeed a prefix of s.
Straight-forward check, right ?
Except that the assertion died, and kept dying.
- my initial code didn't strip \n from read lines, so it could never match
(easy to fix)
- some python lists have ${MODPY_PYCACHE}/ at the end of an entry, which
yields a double / (easy to strip though)
- last but not least, some items may be recognized as something more
specific, like bin/someprog -> @bin bin/someprog
I'm in the process of fixing that last one, which is an actual bug: the
unsubst string would NOT be a prefix of the subst'd string, and this DOES
break the "try to guess the empty variable location" in the update-plist
heuristics...
Each time you add checks, you will find bugs...
