> > > 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. > > > > 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)"). > 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. That said, we still strongly prefer (for the reasons that Keith already cited) that files that will never be relevant to Solaris be purged. > 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. -- meem
