I often add a Bill Of Materials File (a BOM) to directories that contain source code.
A BOM is a list of files that are expected to be in the directory.
I have make rules that check the files actually in the directory against the files in the BOM.
Files that are not in the BOM are reported, so that I can add them if necessary.
Files that are expected to be in the BOM are reported.
Most importantly, I nearly always have a "make BOMclean" target that removes all files not in the BOM.
The BOM is slightly annoying, because a file must be added to both CVS and the BOM.
The BOM helps in several ways:
"make cleanest" is just plain smart. nobody ever makes a really good "make clean"
I also have "make cvsclean", that removes all files not checked into CVS, but it doesn't work as well as "make BOMclean"
BOMs have caught errors in CVS, RCS, and SCCS.
Once, a sysadmin decided to remove all of the files in the CVS Attic - files that were not current, but were needed to reconstruct old versions.
The BOM detected this error.
Without the BOM, it happened that VPATH would silently have found an alternate (wrong) file of the needed name.
BOMs can be used to cope with CVS's inadequacies renaming files.
-- Some folks extend the BillOfMaterialsFile to contain stuff like
RCS/CVS version numbers
-- this basically makes BOMs into a sort of external tag - useful when you want to libraries to which you have only read-only CVS access
checksums
-- mainly because CVS has no checksums - and, yes I *have* found errors in CVS files.
I've seen this organization in a lot of projects and always wondered why.
People accept that a source file should be an input to the build process or an intermediate generated file, but not both.
If they don't allow hybrid files, why allow hybrid directories that contain both source files and generated files?
I prefer to treat source directories as read-only from the build tool's perspective, and put any intermediate and generated files elsewhere.
My source directory is my "bill of materials".