Peter Memishian wrote: [snip] > > Slightly offtopic: Actually my long term plan is to _fix_ /usr/bin/file. > > The current version has a couple of design problems > > You enjoy pain, don't you? ;-)
No... not really. But Solaris's /usr/bin/file is... uhm... old and could really get an update (I've done similar work long ago (e.g. AmigaOS's datatypes.library and we can look at other work like freedesktop's mimetype work or CDE's Datatypes framework) which means this would only be plain, dumb work and nothing special or mind-melting... :-) ). > > > > ./lib/libast/common/port/atmain.C > > > > > > > > at stubs (not used on Solaris (unless someone writes something like > > > > BrandZ/MVS ... =:-) )) > > > > > > This seems highly unlikely to be relevant. > > > > Right (you did see the "devil" smiley (e.g. "=:-)"), right ?) ... :-) > > Ah :-) Seriouly... did you really belive I'd try my luck with something like MVS ? > > > > ./lib/libpp/common/ppsym.c > > > > > > > > Some kind of "iffe"-like probe to figure out the list of CPP > predefined > > > > symbols. > > > > > > I'm still lost on this one, but OK. > > > > Erm... which question do you have about this ? > > Just that "some kind of iffe-like probe" seems nebulous. How confident > are we that we understand its purpose and relationship to Solaris? See Glenn's answer (http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2007-March/002429.html) for that... > > I am worried since it is in the default search path for includes which > > means noticing cases like "cc -Ioverlay/ -Inormal/ mychicken.c # where > > both overlay/ and normal/ contain a version of 'x.h'" may cause > > (undetected) trouble if "overlay/x.h" gets removed, e.g. this scenario > > may compile but the results may... uhm... not something you really want. > > That's why I said I am little bit scared in this case. > > Maybe I'm not being creative enough, but if it's really an overlay, then > the interface definitions should be compatible, right? Theoretically "yes" (except if you do something like |#define regex _ast_regex| for one version of the header and not for the other version (no, the ASTSA code doesn't do that... it's just an example...)). > I would've thought > that astsa would be a semantically compatible subset of the functionality > available in the non-standalone environment, and thus that removing the > standalone headers would not cause problems -- especially not at runtime. Depends on how the code works. For example if two different libraries have functions with the same name and almost identical functionality you may run into "interesting effects" when there is a difference hidden behind the "almost". And debugging this kind of issues is... uhm... not fun (we've fixed that kind of trouble early during development, don't worry). > > What about using something like /usr/bin/file to detect the file type > > and get "findunref" to complain only if such files do not have the right > > type (Ok... the problem would be that this would read the files and > > therefore alter the access timestamp) ? > > Yes, I'd like to keep findunref's output reproducible. Ok... > > ... what about adding *.xml or *.docbook to this list of files (assuming > > that some day we get some documentation written in DocBook into the > > tree) ? > > For hygiene reasons, we don't permit exceptions that are not actually > being used. There is another tool (checkpaths) that will enforce this. > (Yes, we're really *that* picky about this sort of stuff.) Ok... ... but are there any objections that someone stuffs a DocBook/XML file (documentation) in the tree (later... not now...) ? [snip] > > > each resync: > > > > > > */Mamfile > > > */Makefile > > > > AFAIK "*/common/Makefile" would be better (OkOk, nitpicking... :-) ) ... > > I agree it would be better. Well, my idea was to create a file (e.g. "usr/src/lib/libshell/misc/filelist.txt") which should contain the list of added/moved/removed files that we can keep track of all the movements of our citizen. For now the file would only contain the following list of removed files (plus CDDL header+description... and maybe a "removed" in front of each filename): -- snip -- usr/src/cmd/ast/msgcc/Mamfile usr/src/lib/libast/common/Mamfile usr/src/lib/libast/common/Makefile usr/src/lib/libast/common/astsa/align.h usr/src/lib/libast/common/astsa/astwinsize.c usr/src/lib/libast/common/astsa/ccode.h usr/src/lib/libast/common/astsa/strmatch.c usr/src/lib/libast/common/astsa/times.h usr/src/lib/libast/common/astsa/sig.h usr/src/lib/libast/common/astsa/lclib.h usr/src/lib/libast/common/astsa/README usr/src/lib/libast/common/astsa/ast.h usr/src/lib/libast/common/uwin/mini.sym usr/src/lib/libast/common/misc/magic.tab usr/src/lib/libcmd/common/Mamfile usr/src/lib/libcmd/common/Makefile usr/src/lib/libdll/common/Mamfile usr/src/lib/libdll/common/Makefile usr/src/lib/libpp/common/Mamfile usr/src/lib/libpp/common/Makefile usr/src/lib/libpp/common/probe.win32 usr/src/lib/libshell/common/Mamfile usr/src/lib/libshell/common/Makefile usr/src/lib/libshell/common/mamexec usr/src/lib/libshell/common/mamstate.c -- snip -- (please verify that I didn't miss any files) [snip] > > > ./lib/libpp/sparc/gentab > > > ./lib/libpp/sparc/probe > > > ./lib/libpp/sparc/probe.sh > > > > AFAIK we should keep them - AFAIK April's original list of "unreferenced > > files" did not include "lib/libpp/i386/probe.sh", "lib/libpp/i386/probe" > > or "./lib/libpp/i386/gentab" either. > > So does that mean that the above are actually referenced on a SPARC build? Uhm... good question. Glenn explained in http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2007-March/002429.html for which stuff these files are used... but the OS/Net Makefiles do not use them (which raises the question why these files didn't show up in the original "unused i386 files"-list). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
