Peter Memishian wrote: > > > ... David (Comay): Are there any objections to leave the all the files > > > in place and add a README for now describing the source file layout ? > > > > I'm OK with this approach with dealing for the ATT files although it's > > really unfortunate that unused Makefiles will be left in the source > > directories, causing confusion for those who run across them. > > I'm still confused here. It is true there is existing precedent for > unused source files for things we sync with upstream, but I am not aware > of a similar precedent for Makefiles. > > The difference I see here is one of expertise: Makefile changes are often > made not by the project team, but by other engineers who are trying to > address some general issue (e.g., support for a new compiler, or new > linker options). Because these engineers must make changes across a giant > array of Makefiles, interlopers from other build systems (and > inconsistency in general) present needless hazards that impede progress.
Somehow this reminds me of the story/joke how computer scientist test whether "Africa" containts any "elephants" (unforunately I couldn't find any english versions of the original): The algorithm works like this: You place one elephant in Cairo (e.g. the "terminator" of the search area) and starting searching in South Africa. If you find an elephant before the one in Cairo then there are "elephant(s)" in" Africa", otherwise you just find the terminator of the search area (e.g. the elephant in Cairo) ... :-) I guess if someone writes an automated script he/she will have to deal with things like http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/tcpd/Makefile.org or Makefiles in test/debug subdirs anyway... maybe it's better to have a well-known "black sheep" in the tree than having no one. > I remain strongly opposed to alien Makefiles in our tree. Umpf... if the argumentation above isn't convincing enougth (yes, yes... it isn't _that_ funny... ;-/ ) - how should we proceed in this case ? Removing the file is bad because it would generate the "precedent" to get more files stripped and renaming isn't much better (well, it isn't that bad (compared to the ide to get files removed) ... we adjust the paths of the parent directories in the diff files anyway and doing this for the Makefiles may not hurt... but I fear which possible "precedent" could be constructed from that (like "... lets rename all files which are unused from ${i} to ${i}.unused ..." or something like that) ... ;-( ). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)