James Carlson wrote:
> Ali Bahrami writes:
>> - Files that are not actual linker mapfiles
>> - A couple of template mapfiles that are processed
>> via their makefiles to generate mapfiles (mdb, libelfsign)
>> - A small number of mapfiles that don't set any versioning
>> information, but rather, are just tweaking segment attributes.
>
> How about just renaming those few exceptions so that they either don't
> match the pattern (s/mapfile/mapproto/) or additionally include some
> easy-to-detect pattern (.e.g., "mapfile_nocheck") that can be used to
> exclude them automatically?
>
> In either case, the changes should be quite easy to test using a
> binary compare (nightly -w).
>
I rejected that option because I didn't want people to have to
choose bad names. If someone wants to write a script
called "process_mapfile", I don't want to force them to rename
it to "process_map_file" just to get around mapfilechk. Similarly,
I didn't want to change file names that have been in place for years.
Of course this is not perfectly seamless --- the person integrating
process_mapfile will still be confronted with some confusing errors,
and will have to augment the exception file to make them go away.
Note that mapfilechk itself falls foul of this. I thought
about mapchk (a bit generic), or map-filechk, or other other
permutations, but I think mapfilechk is really the best name
for it, and fits the pattern set by the other tool names.
I guess it comes down to an aesthetic decision of which is better:
1) A standard mechanism that applies to all the
tools
or
2) Have each tool implement some heuristics that make
sense for it, thereby avoiding the need for more plumbing.
Since this is purely subjective, I won't make any strong claims
either way, but I prefer (1). I am of course willing to change
if you or others feel strongly --- my real goal is to get this
mapfile project finished... :-)
Consider this a call for everyone to weigh in.
The issue with cadmium however is orthogonal to this. Whether or
not I provide an exception mechanism for mapfilechk, cadmium's
.NOT processing isn't right, and needs a fix.
> In either case, the changes should be quite easy to test using a
> binary compare (nightly -w).
In the context of my mapfile project (6785284), we have already
discussed the idea of having the nightly builds verify that the
versioning details of a given object have not changed, or if they
have, of flagging them so that the gatekeepers will note the change
and ask about it. I've also been thinking that it would not be
difficult to augment wsdiff to make that comparison --- it's on
my list to look into, right after mapfilechk.
- Ali
