how to set CFLAGS variable for compiling Xorg

[Peter Breitenlohner]

On Wed, 5 Nov 2008, Pat Kane wrote:

> On Tue, Nov 4, 2008 at 12:30 PM, Julien Cristau <jcristau at debian.org> 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 <peb at mppmu.mpg.de>