On Wed, 5 Nov 2008, Pat Kane wrote: > On Tue, Nov 4, 2008 at 12:30 PM, Julien Cristau <[EMAIL PROTECTED]> wrote: >> On Tue, Nov 4, 2008 at 08:44:17 -0800, Carl Worth wrote: >> >>> But it's still awfully rude of the Makefiles to use CFLAGS for internal >>> purposes so that the user can't augment things on the make command line. >> >> Agreed. Should be fixed now for libXfont; feel free to complain if you >> run into the same problem in another module, so someone else can fix it.
Hi Julien, this very same problem occurs in many (most?) modules. If you'd apply them I could prepare patches for that (against current git). There are, however, two or three related problems that maybe should be addressed at the same time. (1) In order to further ansification, IMHO all modules should use the gcc warning flags. Paulo Cesar Pereira de Andrade has even suggested to enhance them with -Wdeclaration-after-statement, -Wold-style-definition, and -Wbad-function-cast, that could be done unconditionally or conditionally (via --enable-extra-warnings). I have prepared some patches for that, but they butcher CFLAGS and need to be revised. These additional warnings are extremely useful to find non-ansi declarations and related problems. (2) You have applied a patch that avoids the need for AM_PROG_CC_C_O in some modules, but there are still plenty of modules needing that (and some others really do need AM_PROG_CC_C_O). (3) The ChangeLog hook has to be revised in practically every module: (a) replace 'git-log' by 'git log' because git-log was deprecated in git-1.5.x and removed from PATH in git-1.6.x (b) "(GIT_DIR=....; rm -f .changelog.tmp)" will always succeed and consequently the second part "(touch ChangeLog...)" never be executed. IMHO the rule should read "(GIT_DIR=....) || (rm -f .changelog.tmp; touch ChangeLog...)" I could go through the modules, prepare patches for these three issues, and send them to you, provided you'd agree to apply them. If so, please also let me know your opinion about the additional warnings (never, conditional, or unconditional). Cheers, Peter Breitenlohner <[EMAIL PROTECTED]> _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg