>>>>> "GD" == Garrett D'Amore <[EMAIL PROTECTED]> writes:
Rich> usr/src/uts/sun4u/douglas/Makefile.files Rich> RL-4: L38 - See, now this *does* reference tadpmu, One or the Rich> other... GD> Hrmmm... right now the reference is a harmless stub, because nothing GD> calls it yet. But once I add tadpmu.c, it will get called. I can GD> remove it now if it is offensive. The problem with cruft like this is it makes it harder for people to understand just what's going on. As a general rule, unused code (including makefile bits) should be kept out of the gate. Rich> usr/src/uts/sun4u/douglas/Makefile.targ.shared Rich> RL-6: Some platforms do this and Makefile.targ, some just the Rich> latter. Is there a reason for that, I can't see one. [...] GD> I copied the current Makefile framework from grover. I noticed the GD> discrepancy, but I have no idea which is preferred. The Makefile.*.shared files were introduced to deal with makefile text that is shared between the open and closed trees. In the interest of simplicity, platforms that are entirely open-source should not use the .shared pattern. If there's a reasonable chance you'll be adding closed code later, I'd leave it as-is. (Teamware doesn't cope with renaming a file Foo to Foo.shared and then creating a new Foo. I haven't checked how well Mercurial copes.) Rich> usr/src/uts/sun4u/douglas/os/douglas.c Rich> RL-7: #if 0 is evil, don't do it. (see Developing in ON) GD> Again, this is intended to be very short term. Historically, there have been problems with project teams promising to fix something in a followup putback and then not doing so (e.g., the team gets redirected to work on something else). So there is a strong preference not to introduce #if 0'd code in the first place. mike _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
