By user554629 on May 27, 2012
I like small software.
Remember the metric "LOC" ( Lines Of Code). That's not a battle cry; I have no desire to return to that era.
I used to drive managers crazy when asked how many lines of code it would take to implement a feature.
Q: How much larger will the code base be?
A: It will be smaller.
How can you measure an employee who gives answers like that? Do we penalize them for reducing the inventory? What about the answer "None". It's not needed; it's already in the base product. We need to document it.
Is that zero productivity, or infinite productivity?
Looking at the script I wrote to extract dbx from the Oracle Studio Distribution, I questioned why I did it that way. The motivations were:
- To retain the original structure of the distributed product.
- To permit the code to be patched; Studio patches would expect the original directory layout?
Nah ... you're not going to buy Oracle Support for 22MB of code, are you.
We don't need to be a slave to the original directory structure imposed by tar.
How can we make this more simple, and easier to understand.
I wrote a script ( dirstats ), to provide metrics on a distribution directory.
Here are the results for the full Studio 12.3 extraction from the downloaded tar file:
bash-2.05$ time dirstats studio12u3
Size Dirs Links Files Path
1.6G 1049 4255 10056 studio12u3
Now the A/B test for the dbx extraction:
bash-3.00$ dirstats studio*
Size Dirs Links Files Path
22M 34 28 53 studio12.3
16M 20 4 32 studio12.3a # 64-bit dbx failed.
17M 22 11 44 studio12.3b # Latest version
Same executables, directory is smaller with fewer directories, links and files..
The unpackDbx script becomes much simpler; after I untar the selected files, 12 lines of script were used to match the distributed directory directory structure that used symlinks. The structure build by tar:
cd studio12.3 ; ls
READMEs bin lib man prod share
(cd share ; tar -cf - man ) | tar -xvf - ; rm -fr share
(cd prod ; tar -cf - man ) | tar -xvf - ; rm -fr prod/man
for f in c++filt getmsg version whatdir; do mv prod/bin/$f bin ; done
for f in dem dwarfdump; do (cd bin; ln -fs ../prod/bin/$f . ) ; done
That didn't work out. The prod/bin and prod/lib structures needed to be retained because of symbolic links, so I remained faithful to the original directory, because there were dlopen constructs that didn't work. The only simplification was merging the man page directories.
There; I fixed it. We don't need the ./share or ./prod/man directories. The result is more simple.
Aside: executables remain in ./prod/bin, with symlinks to ./bin.
dlopen is used by these executables to open path relative libraries (.so) in ./prod/lib,
and also architecture dependent (sparcv9) executables for 64-bit.
Here are the lines of code removed from unpackDbx.sh
mkdir -p man/man1 man/man4 lib/sys/v9 lib/v9
(cd bin; ln -s ../prod/bin/* . )
(cd man/man1; ln -s ../../prod/man/man1/* . )
(cd man/man1; ln -s ../../share/man/man1/* . )
(cd man/man4; ln -s ../../share/man/man4/* . )
/usr/bin/catman -w -M man
(cd lib; ln -s ../prod/lib/* . ; ln -fs libdwarf.so.1 libdwarf.so)
(cd lib/v9; ln -s ../../prod/lib/v9/* . ; ln -fs libdwarf.so.1 libdwarf.so)
(cd lib/sys; ln -s ../../prod/lib/sys/* . )
(cd lib/sys/v9; ln -s ../../../prod/lib/sys/v9/* . )
(cd lib/locale/C/LC_MESSAGES; ln -s ../../../../prod/lib/locale/C/LC_MESSAGES/* . )
I was in a code review, when one participant complained the code was too hard to read.
The author's response: "It should be hard to read, it was hard to write." -RS