Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Imagination Technologies's MIPS group, in the past of other companies such as Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Sunday, May 20, 2012

file.ext and file.ext-DIR/ versus file and file/file

I learned a long time ago that what starts out as a single file often becomes a directory. E.g. one of my first "open source" things was my debug header, debug.h. Standardly ~/src/libag/debug.h But many years later I drank the koolaid of testing, so I wanted debug-test.c. And a Makefile. Where did I put it? Separate files makes it easy to copy debug.h without the tests:
    ~/src/libag
          debug.h
          debug-test.c
          Makefile
          some-other-lib-header.h
And the Makefile would have to have stuff for all the things in the same directory. Messy. So I learned that it was good to create "directory objects" for such things. Places where all of the usual things, e.g., associated with a single header-only library fo: tests, Makefiles, README, man pages, etc.:
    ~/src/libag
          debug/
              debug.h
              debug-test.c
              Makefile // just for debug.g
          some-other-lib-header
              some-other-lib-header.h
              test-some-other-lib-header.c
              Makefile // just for some other lib header
So, all is happy. It is slightly annoying to have to type debug/debug.h, as in
#include "debug/debug.h"
but I am willing to do so to get the goodness of directory objects. But then I encounter... barbarians. Tools that do not use "directory objects". E.g. I recently had to debug my X windows setup. I'm learning that even simple stuff in something like a .twmrc needs tests. Where do I but them? .twmrc is in a directory, ~/, shared by many tools. Convention: create .twmrc.DIR, and put the stuff in there. Generalization: given a file "file" that is not by itself in a directory "file/file", create "file.DIR/" as the place to hold such meta-information. === It might be nice to make this transparent: Create a file "file", and let it live without the stuff that I put in the accompanying or enclosing directory. As long as it needs to. But when it comes time to create the accompanying stuff, the meta stuff, like READMEs and manual pages and tests and examples and makefiles... - allow file.DIR top be created. (Or cvall it file.meta, or ...). But make file and file.DIR semi-transparent. If you do "cp file dest ", then it is equivalent to "cp -R file file.DIR dest". Or, rather, perhaps, use the old concept of filesystem forks, such as resource forks. Make "file" be an alias for "file.DIR/file".