<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0"> </HEAD> <BODY> On Thu, 2010-02-25 at 10:57 -0800, Keith Packard wrote: <BLOCKQUOTE TYPE=CITE> <TT>Having this be consistent across all protocol libraries and server</TT> <TT>modules seems like a good idea, even if there aren't obvious bugs</TT> <TT>present now, </TT> </BLOCKQUOTE> Drivers and apps excluded? (or case by case) <BLOCKQUOTE TYPE=CITE> <TT>future changes in GCC may well cause old code to break in</TT> <TT>the future and we'll need a hook to make sure that we can apply options</TT> <TT>globally across the system.</TT> </BLOCKQUOTE> It's easy to add a variable, say $(PROJECT_CFLAGS) that is added in each makefile. Ideally it would be empty, meaning there is no problem to solve. If a new feature is implemented which causes several bugs, we can turn it off by adding the appropriate option until it stabilizes and then remove it. Macros: XORG_PROJECT_CFLAGS which defines $(PROJECT_CFLAGS) variable XORG_WARNING_CFLAGS which defines $(WARNING_CFLAGS) variable set to -W* XORG_OPTIMIZATION_CFLAGS which defines $(OPTIMIZATION_CFLAGS) variable set to -fno-strict-aliasing Proposed content for makefiles where -fno-strict-aliasing is needed: AM_CFLAGS = \      $(PROJECT_CFLAGS) \      $(WARNING_CFLAGS) \      $(OPTIMIZATION_CFLAGS) Proposed content for makefiles where -fno-strict-aliasing is *not* needed: AM_CFLAGS = \      $(PROJECT_CFLAGS) \      $(WARNING_CFLAGS) Let's rewrite history using these macros: ~2005: gnu changes optimization that breaks a fair amount of code. The -fno-strict-aliasing is added in XORG_PROJECT_CFLAGS which returns the system to the previous state. Further investigation shows that it may never be possible to change all the code, so a new XORG_OPTIMIZATION_CFLAGS macro is created and becomes a permanent solution for a large part of the system. The -fno-strict-aliasing option is then removed from XORG_PROJECT_CFLAGS and ready for the next problem. The word "WARNING" and OPTIMIZATION" are taken from the compiler options category. There are many other categories like Debugging or Linker. By naming the macro according to the category, we would never be in a situation where we stick an optimization option in a warning macro. If another optimization goes bad, it would go in XORG_OPTIMIZATION_CFLAGS as well. The legacy CWARNFLAGS would be left alone to handle previous versions of xserver/libs... </BODY> </HTML>