> I have written a heads up message that describes all of this in more > detail: > > http://cr.opensolaris.org/~alib/mapfilechk.heads_up
"...ask for help, and from who" should read "...ask for help, and from whom." It's probably not a big deal, but the first sentence under "2)" gives the impression that mapfilechk, like hg mapfilechk, is subject to *mapfile* regex filtering. For "mapfiles that we know do not (and will not) specify symbol versioning," would it actually be inappropriate to embed the comment, instead of excluding them? > Webrev for the change is available on SWAN at: > > http://linkers/webrev/6785284/index.html > > or externally: > > http://cr.opensolaris.org/~alib/mapfilechk/ Your CRT advocate will appreciate it if you update the bug reports before filing your RTI. The defects (as opposed to RFE) will need introduced in/root cause info, and all will need suggested fixes. > There are 515 files involved in this, almost all of which are > mapfiles that received the comment, and possibly had their copyright > or cddl blocks updated. I certainly don't expect (or need) many of you > to wade through all of these (although I have looked at every one, and Rod > has already code reviewed this for me). I'd say that if you're interested > at all, just hitting a few randomly would suffice. > > Here is a list of the files that are not mapfiles, that might merit > your attention, based on your interest: I rearranged the list a little bit, in an attempt to make it clear what I had/had not reviewed. Let me know if I didn't succeed. > exception_lists/mapfilechk I didn't expect questions here. :) Nonetheless: why a glob for usr/src/tools/scripts, when all the rest are so much more filename-specific? > usr/src/tools/onbld/Checks/CmtBlk.py ...seems to be missing a word in line 30: 30 # Check source files contain a valid comment block > usr/src/tools/scripts/mapfilechk.1 Do you have this installed on a system that I can just check the manpage? > usr/src/tools/onbld/Checks/Mapfile.py > usr/src/tools/scripts/mapfilechk.py > usr/src/tools/onbld/Checks/Cddl.py To be perfectly honest, I assume that this was a complete cut/paste job. I didn't carefully review the code that you moved from one place to another. With that caveat, these looked like I expected. > usr/src/lib/README.mapfiles Comment on 207-213: - s/the OSnet/the OSNet consolidation/ - s/SUNWpriviate/SUNWprivate/ - I'm not actually sure that this paragraph provides useful clarification? And what IS the best practice here? Isn't it to use SUNWprivate for consolidation- or project-private interfaces? Ie something that's contracted should be in a public version, shouldn't it? Comment on 339-347: - s/Simply remove/To move an interface from Private to local scope, simply remove/ - The last sentence here seems like a separate paragraph, or even a separate, numbered section. > usr/src/tools/SUNWonbld/prototype_com > usr/src/tools/onbld/Checks/Makefile > usr/src/tools/onbld/Checks/__init__.py > usr/src/tools/onbld/hgext/cdm.py > usr/src/tools/scripts/Makefile > usr/src/tools/scripts/check_rtime.1 These all look OK. > usr/src/tools/scripts/check_rtime.pl I'm NOT a Perl guy, I would prefer somebody else reviewed these changes. > usr/src/tools/scripts/nightly.sh - Do we still care about people running our nightly script on pre-Solaris-9 systems? Maybe, but "ugh." (ref. lines 2959-2965) - While John Forte was merging NWS bits, I spent a *ton* of time helping him figure out a Makefile problem that was giving him a 32-bit object when it should have been 64-bit. Is the LDDWRONG string (ref. line 2966) actually correct? Because that would have gotten us there MUCH sooner, I suspect. (We fell through this test, but then still hit the next one, about CRLECONF.) > Thank you for your help. Perhaps it's cliche, but "No, Ali, thank YOU." --Mark
