Peter Memishian wrote: > > Seriouly... did you really belive I'd try my luck with something like > > MVS ? > > One never knows ;-)
Brrrrr... <shiver> ... anyone who is going to propose such a BranzZ/MVS-project is IMO likely a canidate for a mental institution (we have "Hercules" (see http://www.hercules-390.org/) for that... :-) ) ... =:-) > > > 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... > > He's described what it does, but said "I'm not sure how/where the catalog > generation is being integrated" -- in other words, I still don't quite > understand when we would make use of it. Erm, AFAIK that comment was more about where we've put "msgcc"&co (in our case it's in usr/src/cmd/ast/msgcc/) and the libpp code (in our case usr/src/lib/libpp/) which slightly differs from the upstream source code layout... > > > 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...) ? > > Seems OK to me, but that's something that probably needs discussion with a > wider audience. Ok... > > 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): > > That seems OK to me. Ok... [snip] > > (please verify that I didn't miss any files) > > I thought we concluded that dirstd.h and atmain.C were also safe to > remove? Right. Seems I missed this (which was no wonder at that point after to many hours without sleep (near the point where you start to see the little pink flying elephants... :-) ) ... that's why I asked "... please verify..." to avoid that we're checking-in something dumb...) Here comes the fixed list: -- 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/dir/dirstd.h usr/src/lib/libast/common/misc/magic.tab usr/src/lib/libast/common/port/atmain.C usr/src/lib/libast/common/uwin/mini.sym 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 -- Better ? > > > > > ./lib/libpp/sparc/probe > > > > > ./lib/libpp/sparc/probe.sh > > > > 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). > > Indeed, why is that? I am not sure. I don't see anything special for these files and AFAIK none of the Makefiles in usr/src/lib/libpp/${TRANSMACH)/ uses something like /usr/bin/file which may touch the files for reading. Short: I have zero clues why they are not listed... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
