Peter Memishian wrote: > > > > Fixed (I wish we could keep the comments to document how this stuff was > > > > created... ;-( ). > > > > > > They can go in the CR used to integrate the feature. Actually, they can > > > go pretty much anywhere *except* the source tree. > > > > There is still the unanswered/unsolved problem to track such things... > > any CR documentation is AFAIK not public and (more important) not > > maintained by a SCM (and even if there is such a SCM it would need to be > > kept in sync with the main OS/Net SCM, following all branches, splits, > > mergers etc.). > > The fact that it's not public is a bug which is being worked. For one-off > scripts used to generate files, I don't see a need to have that version > controlled. However, if you do, then just put a URL to the SCM-controlled > version in the CR. Like I said above, put the script wherever you want, > as long as it's not in the source tree.
Now I am getting VERY nervous while thinking about the "buildksh93.ksh" script. Most other sources/bits can be regenerated with some diff, hacks and lots of time... but if that script gets lost or out of sync we can rm -Rf the whole ksh93 sources in the tree and restart from scratch at the last snapshot point (if there is one). That's why I don't like the idea of a different location outside the tree. I remeber the issue about the IPv6 patch for dtksh and I really never want to be in this hell with that script since we cannot recover from that problem without lots of time (yes, yes, OpenSolaris will try to avoid the mistakes of the past... but unlike the IPv6 bits for dtksh (which can be described as some obscure moulding on a balcony in a far corner of one of the smaller towers) this one sits near the headstone and loosing such stuff may collapse the whole thing by accident. That's why I am sitting here now and can't really sleep... ;-( ). > > > > > usr/src/lib/libdll/common/Makefile > > > > > > > > > > Is this really the Makefile you intend to putback? It looks > > > > > like it came from the ksh93 source itself. > > > > > > > > Yes, see above (no fork() of AST codebase, please). > > > > > > Please, no alien Makefiles. They've invaded our source tree in the past > > > (e.g., the old SNMP codebase), and they were an unbelievable headache. > > > The Makefiles in our tree need to be written for our build system. > > > > The Makefile isn't used, it's just there (well, until now it didn't bite > > anyone). > > I'm glad to hear it's not used. However, the name alone makes it an > attractive nuisance -- and a possible victim of automated Makefile updates > (e.g., when we changed all instances of "-v" to "$(CCVERBOSE)"). That should be no problem since the next check/update will detect that the file was changed without having an entry in the *.diff files... :-) > > The problem I see is that if we remove this file we create a > > "precedent" for more file stripping in our copy of the AST codebase. > > Where should we start - and where should we stop ? > > It seems reasonable to me to strip out any files that will never be used > by ON. That would include the Makefiles and files that are exclusive to > other platforms (e.g., workarounds for brokenness on other platforms). We > have a tool (findunref -- through the -f option to nightly) that will > automatically identify all files that aren't accessed during the build. > > In general, all putbacks to ON must be findunref-clean, but exceptions are > granted for code that we plan to keep in-sync with an upstream source. What do you mean with that ? Would this apply to our AST/ksh93 codebase (I am praying for that (it seems at least "perl" and "BIND" fall into this category)) ? > That said, we still strongly prefer (for the reasons that Keith already > cited) that files that will never be relevant to Solaris be purged. There is a problem with parts of the files. For example the tree contains usr/src/lib/libshell/common/sh.1 which is the unmodified ksh93 manual page which exactly matches the status of the current codebase in OS/Net while the one (ksh93.1) which is going to be shipped with Solaris is a hightly customized version. Removing the "sh.1" file would be possible but we would loose the documentation to the current code since the Solaris "ksh93.1" manual page would follow the ARC cases and therefore may likely a few months behind the one in the tree and/or list features which are optional in the official version (like C99 math functions or SCTP support). Therefore I really don't like the idea of stripping the codebase at all - AFAIK there are no definitive rules which should be picked and which not - and stripping all "unused" files may only cause lots of trouble later (which would be my burden to get this somehow repaired, over and over again (and I am not really happy with that since it would turn the maintaince of ksh93 in OS/Net more and more into a full-time job (which is not good since I still have to work on other, unrelated stuff to get some food))). IMO it may be better to have "too many" files in the tree than lacking some files and then fanatically trying to search for the missing bits in the upstream tarballs... ... but maybe I am worrying too much... the "findunref" list (http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/tools/findunref/exception_list) lists "perl" and that may be a good precedent for ksh93... or not ? > > How do we keep track of removed files > > I'd think that list would live with the "(semi-)automated" update scripts > you alluded to. Where all that stuff lives is open for debate. Umpf... the scripts do no handle "missing" files and such a feature is not easy to implement (at least not with the current /usr/bin/ksh and somehow we lack a more capable shell right now... grumble... ;-( ) ... ;-( ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
