>>>>> "meem" == Peter Memishian <peter.memishian at sun.com> writes:
meem> It is true there is existing precedent for unused source files for
meem> things we sync with upstream, but I am not aware of a similar
meem> precedent for Makefiles.
I've noticed a couple components with upstream makefiles in the ON gate,
namely
usr/src/grub/grub-0.95 (Makefile.am, Makefile.in)
usr/src/cmd/tcpd (Makefile.dist, Makefile.org, Makefile.sfwsrc)
But doing a quick search for Make*.* didn't show any other obvious
cases.
meem> The difference I see here is one of expertise: Makefile changes
meem> are often made not by the project team, but by other engineers who
meem> are trying to address some general issue (e.g., support for a new
meem> compiler, or new linker options). Because these engineers must
meem> make changes across a giant array of Makefiles, interlopers from
meem> other build systems (and inconsistency in general) present
meem> needless hazards that impede progress.
Yes. These sorts of gate-wide changes are hard enough. Having to deal
with makefiles that don't use the standard macros (e.g., for cpp flags)
makes it harder. And having decoy :-) makefiles makes it worse yet.
meem> I remain strongly opposed to alien Makefiles in our tree.
There are a few options for remedying this. The weakest is to add a
README. It's better than nothing, but it only helps if you actually
start poking around in the source directory.
At the other end of the spectrum is removing the files entirely.
In the middle is renaming the files (e.g., Makefile.att) or hiding them
in a subdirectory.
Meem, I imagine your preference is to remove the files entirely. Are
there any of the other options above that you could live with?
mike
