Roland Mainz wrote: > Peter Memishian wrote: > >> > > usr/src/lib/libast/mapfile-vers >> > > >> > > Lines 29-618 - Please just include the results and don't embed >> > > the script inside the comment. >> > >> > 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.). >
A README in the source tree would be where I would put this kind of info. > >> > > 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). 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 ? How do we keep track > of removed files and updates to them (in theory the *.diff files could > be used to track&&restore removed files but exactly this mechanism > doesn't seem to be welcome in the OS/Net tree... ;-( ) ? We can't really > affort trying to rip out source files "randomly" since this would break > any (semi-)automated update process and doing such stuff manually would > be time-consuming and error-prone. > The problem with this approach is that having "stale" or "unused" files in the tree can be quite confusing -- especially to anyone who is trying to debug a problem with the build, etc. (This is the same reason I hate leaving large #if 0/#endif blocks in code -- grep doesn't understand the C preprocessor.) I would argue that if this process is fairly mechanical, then it can be scripted. Imagine a shell script called "import-upstream-sources" or somesuch, that unpacks a tarball, removes files that are known not to be used (such as the upstream Makefiles), applies any required patches, etc. This approach is used by other projects such as debian, NetBSD, etc. I think it is well tested, and known to work. Without creating undue confusion. It is true (and will always be) that importing a new revision will always require some human intervention (conflict resolution in merge, as well as testing and review of any new features/changes to make sure that they are appropriate for Solaris -- e.g. imagine introduction of a new shell syntax that breaks an existing set of scripts -- that would need human intervention.) My point is, we will never be able to fully automate integration of updates, and I don't think we should have that as our aim. I think we should do the best we can to automate and document the changes we make, and not be afraid to make the changes that are required to have the best solution for Solaris. (OTOH, gratuitous changes should not be made for their own sake, but only if the change really does help the project integrate better with Solaris.) I would apply these guidelines to any program or project, btw, not just ksh93. -- Garrett D'Amore, Principal Software Engineer Tadpole Computer / Computing Technologies Division, General Dynamics C4 Systems http://www.tadpolecomputer.com/ Phone: 951 325-2134 Fax: 951 325-2191
