<!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.32.2"> </HEAD> <BODY> On Sun, 2011-12-18 at 16:19 -0800, Jeremy Huddleston wrote: <BLOCKQUOTE TYPE=CITE> <TT>For the more dangerous compiler warnings that we made into errors,</TT> <TT>use -Werror=... if .git exists and -W... if not.  This way we still</TT> <TT>force developers to trip on them but end users will just see</TT> <TT>warnings.</TT> <TT>Signed-off-by: Jeremy Huddleston <<A HREF="mailto:jeremyhu@apple.com">jeremyhu@apple.com</A>></TT> <TT>---</TT> <TT> xorg-macros.m4.in |   17 +++++++++++++++++</TT> <TT> 1 files changed, 17 insertions(+), 0 deletions(-)</TT> </BLOCKQUOTE> I am concerned about creating a precedent here regarding the detection of git and the assumption of a "use model". We have been confronted with this on numerous occasions where we wanted to do something different depending if the build is from git or from a tarball. I, for one, have been reminded many times by reviewers not to make assumptions about the role of the person who is building and the reason why the build is performed, let alone matching roles with "git vs tarball" builds. The proposed behavior will appear to be erratic and unpredictable when alternating between git/tarball builds until one realizes what is going on. Some may report bugs or post patches to fix warnings just to be told by others that they cannot reproduce the warning. Invariably we will begin to see questions like "are you building from git or from tarball"? The concept of a "development build" vs a "production build" where compiler options are different is very common. This should not occur without the builder's knowledge or consent. We can provide some mechanism to help builder select the type of build desired, but we cannot enforce it. The most obvious autotools features are configure options (we have --enable-strict-compilation) and environment variables that would be picked up by makefiles. There are no centralized builds and therefore no way to enforce a more stringent build. The tinderbox can play a role and the documented development process too. Some of the readers may recall this (git vs tarball) issue being discussed at length in other areas: <BLOCKQUOTE> ChangeLog: git is required to generate it. Special tools: like lex and yacc which may not be available when building from tarball which contains the special tool generated code </BLOCKQUOTE> I know these cases are not quite the same, but they always raised the question "if git do this, else do that" but it never worked out and we had to find a different way without explicitly testing for git. Would it not be possible to modify the content and semantic of --enable-strict-compilation to mean "development build"? Make this option a requirement in the server build process and on tinderbox. It will take time for working habits to adapt, as for any change. </BODY> </HTML>