编译bug怎么去处理
这时很正常的问题.打代码没有bug才不正常.但是编译时的错误还是比较容易避免的,常见的可以通过以下几种方法解决
语法错误:比如说变量名打错,少一个分号,括号之类的错误,经过你不断的打代码,这样的错误慢慢就会减少了.
编译出错时,一半的方法是将问题从上到下一个一个解决.因为第一个错误可能引发后面的很多错误.因此你每次只需要留意第一个错误.很多情况下,第一个错误解决了,后面的错误自然迎刃而解.
编译出错时,编译器通常会提示出错的行号.寻找错误一半从出错的行号往上找,不需要往下找,看看编译错误的原因是什么,遇到不懂的单词可以查查,以后就明白了.因为错误就那么几个,错来错去还是那几个.
建议写程序的时候,不要等全部代码打完之后再一次性编译.可以分模块,分函数写.写完一个之后,尝试着编译,看看有没有问题,即使有问题,寻找起来也相对会方便一点.不必大海捞针.
至于运行时的bug,这需要随着你的代码量的提高而减少(相对).解决bug的常用方法是debug(调试),具体调试的方法因为不同的开发环境而不同.你可以根据你的开发环境查阅相应的debug文档.
‘贰’ 程序编译错误不知道是什么原因
不能通编译过的程序实际上还不是合法的程序，因为它不满足C语言对于程序的基本要求。
检查语法错误的第一要义：集中力量检查系统发现的第一个错误，弄清并改正它。
在编译过程中系统发现的错误主要有两类：基本语法错误和上下文关系错误。这些错误都在表面上，可以直接看得见。也是比较容易弄清，比较容易解决的。关键是需要熟悉C语言的语法规定和有关上下文关系的规定，按照这些规定检查程序正文，看看存在什么问题。
编译中系统发现错误都能指出错误的位置。不同系统在这方面的能力有差异，在错误定位的准确性方面有所不同。有的系统只能指明发现错误的行，有的系统还能够指明行内位置。
一般说，系统指明的位置未必是真实错误出现的位置。通常情况是错误出现在前，而系统发现错误在后，因为它检查到实际错误之后的某个地方，才能确认出了问题，因此报出错误信息。要确认第一个错误的原因，应该从系统指明的位置开始，在那里检查，并从那里开始向前检查。
系统的错误信息中都包含一段文字，说明它所认定的错误原因。应该仔细阅读这段文字，通常它提供了有关错误的重要线索。但也应该理解，错误信息未必准确，有时错误确实存在，但系统对错误的解释也可能不对。也就是说，在查找错误时，既要重视系统提供的错误信息，又不应为系统的错误信息所束缚。
发现了问题，要想清楚错误的真正原因，然后再修改。不要蛮干。在这时的最大诱惑就是想赶快改，看看错误会不会消失。但是蛮干的结果常常是原来的错误没有弄好，又搞出了新的错误。
另一个值得注意的地方：程序中的一个语法错误常常导致编译系统产生许多错误信息。如果你改正了程序中一个或几个错误，下面的弄不清楚了，那么就应该重新编译。改正一处常常能消去许多错误信息行。
解决语法错误
常见语法错误：
1）缺少语句、声明、定义结束的分号。
2）某种括号不配对。C语言中括号性质的东西很多，列举如下：
( ), [ ], { }, ' ', " ", /* */
在不同位置的括号不配对可能引起许多不同的错误信息。
3）关键字拼写错误。
较难认定的典型错误：
1）宏定义造成的错误。这种东西不能在源程序文件中直接看到，是在宏替换之后出现的。常见的能引起语法错误的宏定义错误：宏定义中有不配对的括号，宏定义最后加了不该有的分号，……
解决上下文关系错误
1）变量没有定义。产生这个问题的原因除了变量确实没有大意外，还可能是变量的拼写错误，变量的作用域问题（在不能使用某个变量的地方想去用那个变量）。
2）变量重复定义。例如在同一个作用域里用同样名字定义了两个变量，函数的局部变量与参数重名等。
3）函数的重复定义。可能是用同一个名字定义了两个不同的函数。或者是写出的函数原型在类型上与该函数的定义不相符。有时没有原型而直接写函数调用也可能导致这种错误信息，因为编译程序在遇到函数调用而没有看到函数原型或函数定义时，将给函数假定一个默认原型。如果后来见到的函数定义与假定不符，就会报告函数重复定义错误。
4）变量类型与有关运算对运算对象或者函数对参数的要求不符。例如有些运算（如 %）要求整数参数，而你用的是某种浮点数。
5）有些类型之间不能互相转换。例如你定义了一个结构变量，而后要用它给整数赋值。系统容许的转换包括：数值类型之间的转换，整数和指针之间的转换，指针之间的转换。其余转换（无论是隐含的，还是写出强制）都不允许。参见《C语言程序设计》（K&R）197-199页。
如何看待编译警告
当编译程序发现程序中某个地方有疑问，可能有问题时就会给出一个警告信息。警告信息可能意味着程序中隐含的大错误，也可能确实没有问题。对于警告的正确处理方式应该是：尽可能地消除之。对于编译程序给出的每个警告都应该仔细分析，看看是否真的有问题。只有那些确实无问题的警告才能放下不管。
注意：经验表明，警告常常意味着严重的隐含错误。
常见警告：
1）（局部自动）变量没有初始化就使用。如果对局部指针变量出现这种情况，后果不堪设想。对于一般局部自动变量，没有初始化就使用它的值也不会是有意义的。
2）在条件语句或循环语句的条件中写了赋值。大部分情况是误将 == （等于判断）写成 = 了。这是很常见的程序错误，有些编译程序对这种情况提出警告。
‘叁’ 软件测试发现bug怎么处理
一是项目经理通过和客户的交流，完成需求文档，由开发人员和测试人 员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地 方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合 开发人员，测试人员以及客户的意见，完成项目计划。然后sqa进入项目，开始进行统计和跟踪。
二是开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或 者双方理解不同的地方。测试人员完 成测试计划文档，测试计划包括的内容上面有描述。
三是测试人员根据修改好的需求分析文档开始写测试用例，同时开发人 员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写 测试用例的补充材料。
四是测试用例完成后，测试和开发需要进行评审。
五是测试人员搭建环境
六是开发人员提交第一个版本，可能存在未完成功能，需要说明。测试 人员进行测试，发现 bug 后提 交给 bugzilla。
七是开发提交第二个版本，包括 bug fix 以及增加了部分功能，测试人员进行测试。
八重复上面的工作，一般是 3-4 个版本后 bug 数量减少，达到出货 的要求。
九是如果有客户反馈的问题，需要测试人员协助重现以及回归测试。
在传统的 bugzilla 中，bug 描述应该包括以下的信息：① 和 bug 产生对应的软件版本；② 开发的接口人员；③ bug 的优先级；④ bug 的严重程度；⑤ bug 可能属于的模块，如果不能确认，可以用开发人员来判断；⑥ bug 标题，需要清晰的描述现象；⑦ bug 描述，需要尽量给出重新 bug 的步骤；⑧ bug 附件中能给出相关的日志和截图。
高质量的 bug 记录就是指很容易理解的 bug 记录， 所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。
‘肆’ 新人求教，编译一个最简单的Android程序，提示下面的错误咋解决
未说明具体问题，以下未说明具体问题，以下供你参考
1、32位系统下的编译
如果需要在32位系统中编译android系统，在编译前需要对部分makefile进行修改
首先修改build/core/main.mk，修改的内容如下所示：
-ifneq (64,$(findstring 64,$(build_arch)))
+ifneq
(i686,$(findstring i686,$(build_arch)))
$(warning
************************************************************) $(warning You are attempting to build on a 32-bit system.)
$(warning Only 64-bit build environments are supported beyond froyo/2.2.)
其次修改如下四个文件：
external/clearsilver/cgi/Android.mk
external/clearsilver/java-jni/Android.mk
external/clearsilver/util/Android.mk
external/clearsilver/cs/Android.mk # This forces a 64-bit build for Java6
-LOCAL_CFLAGS += -m64
-LOCAL_LDFLAGS += -m64
+LOCAL_CFLAGS += -m32
+LOCAL_LDFLAGS += -m32即将LOCAL_CFLAGS和LOCAL_LDFLAGS由-m64改为-m32，从而指定使用32位系统进行编译如果使用 64bit 的操作系统编译，这些就都不用修改，但记得需要安装：For 64-bit servers the following extra packages may be needed:
"sudo apt-get install libc6-dev-i386" (libc6-dev-amd64 if AMD CPU)
"sudo apt-get install g++-multilib lib32ncurses5-dev lib32z1-dev"
还有 jdk64bit 的版本编译2 、build/core/base_rules.mk:128:*** frameworks/opt/emoji/jni:
.... libgl2jni already defined by framwworks/base/opengl/tests/gl2_jni/jni 停止
从编译规则上看：
# Make sure that this IS_HOST/CLASS/MODULE combination is unique.
mole_id := MODULE.$(if \
$(LOCAL_IS_HOST_MODULE),HOST,TARGET).$(LOCAL_MODULE_CLASS).$(LOCAL_MODULE)
ifdef $(mole_id)
$(error $(LOCAL_PATH): $(mole_id) already defined by $($(mole_id)))
endif
在framwworks/base/opengl/tests/gl2_jni/下面定义的android.mk定义了：
LOCAL_MODULE := libgl2jni
include $(BUILD_SHARED_LIBRARY)
导致生成的动态库重复，这是不对的，修改tests这个目录不参与编译即可，最直接的办法删除掉framwworks/base/opengl/tests/gl2_jni这个文件夹
3、AIDL 编译报couldn't find import for class原因
“AIDL服务只支持有限的数据类型，因此，如果用AIDL服 务传递一些复杂的数据就需要做更一步处理。AIDL服务支持的数据类型如下：
Java的简单类 型（int、char、boolean等）。不需要导入（import）。String和 CharSequence。不需要导入（import）。
List和 Map。但要注意，List和Map对象的元素类型必须是AIDL服务支持的数据类型。不需要导入（import）。AIDL自动生成 的接口。需要导入（import）。
实现 android.os.Parcelable接口的类。需要导入（import）。
其中后两种数据类 型需要使用import进行导入，传递不需要 import的数据类型的值的方式相同。传递一个需要import的数据类型的值（例如，实现android.os.Parcelable 接口的类）的步 骤略显复杂。除了要建立一个实现android.os.Parcelable接口的类外，还需要为这个类单独建立一个aidl文件，并使用parcelable关键字进行定义。”
没有加LOCAL_AIDL_INCLUDES += xxx ，所以找不到我的parcelable aidl文件。
修改android源码根目录下的build/core/pathmap.mk把你的目录加进去,此时再make update-api
4、老是提示 @Override错误 方法未覆盖其父类的方法
使 用JDK1.6编译没有问题，使用JDK1.5编译，会报@Override方法未覆盖其父类的方法。实际上这个方法是类实现的接口中方法，
但是，这个语 法的jdk1.6的下面是可以通过的，也就是说jdk1.6认为类覆盖父类方法与实现接口方法都叫override，而jdk1.5不
是这样认为的，不知 道这是当初jdk1.5的bug，还是当初就是认为覆盖父类方法与实现接口方法是不一样的，不得而知。但是从
OO角度来看，覆盖父类方法与实现接口方法都 可以认为override，因为他们目的都是一样的，都是为了重用，都是多态的一种
表现方式。
更改jdk版本为1.6即可
5、编译alsa-lib库错误
android系统开发移植alsa-lib库的过程中编译的时候出现了如下的错误
/tmp/cckyaR40.s: Assembler messages:
/tmp/cckyaR40.s:2763: Error: selected processor does not support `mrs ip,cpsr'
/tmp/cckyaR40.s:2764: Error: unshifted register required -- `orr r2,ip,#128'
/tmp/cckyaR40.s:2765: Error: selected processor does not support `msr cpsr_c,r2
字面的意思报的是汇编错误，选择的处理器不支持mrs和msr指令。
原来的ARM指令有32位和16位两种指令模式，16位为thumb指令集，thumb指令集编译出的代码占用空间小，
而且效率也高，所以android的arm编译器默认用的是thumb模式编译，问题在于alsa的代码中有部分的内容
用到了32位的指令，所以才会报如下的错误，修改的方法也很简单，在Android.mk中加入如下内容即可：
LOCAL_ARM_MODE := arm
android的编译系统中LOCAL_ARM_MODE变量的取值为arm或者thumb，代表32位和16位两种arm指令集，默认为thumb
prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: failed to set dynamic section sizes: Bad value
collect2: ld returned 1 exit status
make: *** [out/target/proct/merlin/obj/SHARED_LIBRARIES/libasound_intermediates/LINKED/libasound.so] 错误 1
解决此问题将alsa-lib/include/config.h文件中的如下宏定义去掉即可：
#define VERSIONED_SYMBOLS
开发过程中碰到过很多错误，后续再一一总结记录下来，有些忘记了。。
在android.mk中编译：
include $(CLEAR_VARS)
$(call add-prebuilt-files, STATIC_LIBRARIES, libyfcdca.a)
出现提示需要定义：LOCAL_MODULE_TAGS := optional 一般修改方法是：
build\core\definitions.mk 中的宏定义变量：
define include-prebuilt
include $$(CLEAR_VARS)
LOCAL_SRC_FILES := $(1)
LOCAL_BUILT_MODULE_STEM := $(1)
LOCAL_MODULE_SUFFIX := $$(suffix $(1))
LOCAL_MODULE := $$(basename $(1))
LOCAL_MODULE_CLASS := $(2)
include $$(BUILD_PREBUILT)
endef
在这里增加一个LOCAL_MODULE_TAGS := optional
但是这需要修改android源码，如果不是自已的android系统，这么做就麻烦了，所以必须想其它办法解决：
#include $(CLEAR_VARS)
#$(call add-prebuilt-files, STATIC_LIBRARIES, libyfcdca.a)
include $(CLEAR_VARS)
LOCAL_SRC_FILES := libyfcdca.a
LOCAL_BUILT_MODULE_STEM := libyfcdca.a
LOCAL_MODULE_SUFFIX := lib
LOCAL_MODULE := yfcdca
LOCAL_MODULE_CLASS := STATIC_LIBRARIES
LOCAL_MODULE_TAGS := optional
include $(BUILD_PREBUILT)
如此即可了。供你参考
1、32位系统下的编译
如果需要在32位系统中编译android系统，在编译前需要对部分makefile进行修改
首先修改build/core/main.mk，修改的内容如下所示：
-ifneq (64,$(findstring 64,$(build_arch)))
+ifneq
(i686,$(findstring i686,$(build_arch)))
$(warning
************************************************************) $(warning You are attempting to build on a 32-bit system.)
$(warning Only 64-bit build environments are supported beyond froyo/2.2.)
其次修改如下四个文件：
external/clearsilver/cgi/Android.mk
external/clearsilver/java-jni/Android.mk
external/clearsilver/util/Android.mk
external/clearsilver/cs/Android.mk # This forces a 64-bit build for Java6
-LOCAL_CFLAGS += -m64
-LOCAL_LDFLAGS += -m64
+LOCAL_CFLAGS += -m32
+LOCAL_LDFLAGS += -m32即将LOCAL_CFLAGS和LOCAL_LDFLAGS由-m64改为-m32，从而指定使用32位系统进行编译如果使用 64bit 的操作系统编译，这些就都不用修改，但记得需要安装：For 64-bit servers the following extra packages may be needed:
"sudo apt-get install libc6-dev-i386" (libc6-dev-amd64 if AMD CPU)
"sudo apt-get install g++-multilib lib32ncurses5-dev lib32z1-dev"
还有 jdk64bit 的版本编译2 、build/core/base_rules.mk:128:*** frameworks/opt/emoji/jni:
.... libgl2jni already defined by framwworks/base/opengl/tests/gl2_jni/jni 停止
从编译规则上看：
# Make sure that this IS_HOST/CLASS/MODULE combination is unique.
mole_id := MODULE.$(if \
$(LOCAL_IS_HOST_MODULE),HOST,TARGET).$(LOCAL_MODULE_CLASS).$(LOCAL_MODULE)
ifdef $(mole_id)
$(error $(LOCAL_PATH): $(mole_id) already defined by $($(mole_id)))
endif
在framwworks/base/opengl/tests/gl2_jni/下面定义的android.mk定义了：
LOCAL_MODULE := libgl2jni
include $(BUILD_SHARED_LIBRARY)
导致生成的动态库重复，这是不对的，修改tests这个目录不参与编译即可，最直接的办法删除掉framwworks/base/opengl/tests/gl2_jni这个文件夹
3、AIDL 编译报couldn't find import for class原因
“AIDL服务只支持有限的数据类型，因此，如果用AIDL服 务传递一些复杂的数据就需要做更一步处理。AIDL服务支持的数据类型如下：
Java的简单类 型（int、char、boolean等）。不需要导入（import）。String和 CharSequence。不需要导入（import）。
List和 Map。但要注意，List和Map对象的元素类型必须是AIDL服务支持的数据类型。不需要导入（import）。AIDL自动生成 的接口。需要导入（import）。
实现 android.os.Parcelable接口的类。需要导入（import）。
其中后两种数据类 型需要使用import进行导入，传递不需要 import的数据类型的值的方式相同。传递一个需要import的数据类型的值（例如，实现android.os.Parcelable 接口的类）的步 骤略显复杂。除了要建立一个实现android.os.Parcelable接口的类外，还需要为这个类单独建立一个aidl文件，并使用parcelable关键字进行定义。”
没有加LOCAL_AIDL_INCLUDES += xxx ，所以找不到我的parcelable aidl文件。
修改android源码根目录下的build/core/pathmap.mk把你的目录加进去,此时再make update-api
4、老是提示 @Override错误 方法未覆盖其父类的方法
使 用JDK1.6编译没有问题，使用JDK1.5编译，会报@Override方法未覆盖其父类的方法。实际上这个方法是类实现的接口中方法，
但是，这个语 法的jdk1.6的下面是可以通过的，也就是说jdk1.6认为类覆盖父类方法与实现接口方法都叫override，而jdk1.5不
是这样认为的，不知 道这是当初jdk1.5的bug，还是当初就是认为覆盖父类方法与实现接口方法是不一样的，不得而知。但是从
OO角度来看，覆盖父类方法与实现接口方法都 可以认为override，因为他们目的都是一样的，都是为了重用，都是多态的一种
表现方式。
更改jdk版本为1.6即可
5、编译alsa-lib库错误
android系统开发移植alsa-lib库的过程中编译的时候出现了如下的错误
/tmp/cckyaR40.s: Assembler messages:
/tmp/cckyaR40.s:2763: Error: selected processor does not support `mrs ip,cpsr'
/tmp/cckyaR40.s:2764: Error: unshifted register required -- `orr r2,ip,#128'
/tmp/cckyaR40.s:2765: Error: selected processor does not support `msr cpsr_c,r2
字面的意思报的是汇编错误，选择的处理器不支持mrs和msr指令。
原来的ARM指令有32位和16位两种指令模式，16位为thumb指令集，thumb指令集编译出的代码占用空间小，
而且效率也高，所以android的arm编译器默认用的是thumb模式编译，问题在于alsa的代码中有部分的内容
用到了32位的指令，所以才会报如下的错误，修改的方法也很简单，在Android.mk中加入如下内容即可：
LOCAL_ARM_MODE := arm
android的编译系统中LOCAL_ARM_MODE变量的取值为arm或者thumb，代表32位和16位两种arm指令集，默认为thumb
prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: failed to set dynamic section sizes: Bad value
collect2: ld returned 1 exit status
make: *** [out/target/proct/merlin/obj/SHARED_LIBRARIES/libasound_intermediates/LINKED/libasound.so] 错误 1
解决此问题将alsa-lib/include/config.h文件中的如下宏定义去掉即可：
#define VERSIONED_SYMBOLS
开发过程中碰到过很多错误，后续再一一总结记录下来，有些忘记了。。
在android.mk中编译：
include $(CLEAR_VARS)
$(call add-prebuilt-files, STATIC_LIBRARIES, libyfcdca.a)
出现提示需要定义：LOCAL_MODULE_TAGS := optional 一般修改方法是：
build\core\definitions.mk 中的宏定义变量：
define include-prebuilt
include $$(CLEAR_VARS)
LOCAL_SRC_FILES := $(1)
LOCAL_BUILT_MODULE_STEM := $(1)
LOCAL_MODULE_SUFFIX := $$(suffix $(1))
LOCAL_MODULE := $$(basename $(1))
LOCAL_MODULE_CLASS := $(2)
include $$(BUILD_PREBUILT)
endef
在这里增加一个LOCAL_MODULE_TAGS := optional
但是这需要修改android源码，如果不是自已的android系统，这么做就麻烦了，所以必须想其它办法解决：
#include $(CLEAR_VARS)
#$(call add-prebuilt-files, STATIC_LIBRARIES, libyfcdca.a)
include $(CLEAR_VARS)
LOCAL_SRC_FILES := libyfcdca.a
LOCAL_BUILT_MODULE_STEM := libyfcdca.a
LOCAL_MODULE_SUFFIX := lib
LOCAL_MODULE := yfcdca
LOCAL_MODULE_CLASS := STATIC_LIBRARIES
LOCAL_MODULE_TAGS := optional
include $(BUILD_PREBUILT)
如此即可了。
‘伍’ 编译器错误。怎么办
这是两个截然不同的概念。不是叫做：编译器错误，而是应该叫做：编译错误。如果说真的是编译器内部本身（例如：C语言编译器、或者是别的各种编程语言的编译器）出现了bug 的话，那么任何人也没有办法。只有开发编译器软件的软件开发人员才能够解决这样的问题；
如果是在你的源程序中产生的各种编译错误（例如：语法错误、语义错误等），那么你只能够仔细地检查、编译、调试你的源程序了。
‘陆’ C语言，编译后有很多bug，但不知道错在哪。请求大佬帮忙QAQ
intj=*n;
for(inti=0;i<*n;i++){
if(a[i]==y){
for(j=i;j<(*n)-1;j++){
a[j]=a[j+1];
}
a[j]=0;
}
}
‘柒’ 当程序不能编译时怎么办调试configure
但是，这样行不通时怎么办？在本文中，Peter Seebash 讲述了当自动的配置脚本失效时应该如何去做——以及作为开发者您应如何尽量避免这种错误。毕竟，如果您的程序无法编译，其结果将和您的程序编译后不能运行一样，您的用户会减少。
现在许多开放源代码的程序都会附带有 configure 脚本。这种脚本的用途之一是自动进行对目标新系统的猜测过程。在过去，程序会附带一个 Makefile 文件，这个文件中有 6 个不同的编译标记和选项，但只会用到一个，其余全部注释掉，并且会有一个注解，告诉您“为您的系统选择合适的标记”。如果配置选项更复杂，可能还会有一个名为 config.h 的长长的 C 头文件，其中包含一些要设置的标记，这依赖于主机系统变量。
第一个方法很简单，在代码中使用 #ifdef 以支持两种系统，例如 BSD 和 System V。由于 Unix 的类型的增加，更为实用的方法是对每一个特性使用 #ifdef。每个系统的代码如下：清单 1. 每个系统的代码#ifdef SUNOS4 || NEXT || NETBSD || FREEBSD || OPENBSD
#include <string.h
#else#include <strings.h
#endif每个特性的代码如下：清单 2. 每个特性的代码#ifdef HAS_STRING_H
#include <string.h
#else#include <strings.h
#endif后者更容易适应新系统，但需要开发者进行大量的工作。由于现在有太多可能的目标系统，因此，第二种方法对用户来说帮助很大，不仅仅是可以自动生成配置头文件。完成这项任务的一种方法是使用 GNU autoconf 代码来生成 configure 脚本。这个脚本会去执行必要的测试，并创建一个具有适当值的配置头文件。
这种脚本的另一个功能是以一致的方式设置预定义的变量。用手工编辑标记一直存在一个问题，即修改了 Makefile 文件（比如将其安装到 /usr/gnu 而不是 /usr/local 目录下）却忘记修改头文件中相应的值。当然，这样的结果是，编译后的程序不知道到哪里去寻找它们自己的数据文件。使用 configure 脚本的一个好处是可以自动完成一致的安装（如果维护者做得没错的话）。
开发人员请注意，一个好的 configure 脚本的另一个好处在于，它会允许用户指定一些个人偏好，例如使用 /usr/gnu 而不是 /usr/local。
这些如何成为可能？编译，再编译configure 的许多功能实现机制其实很简单。为了能切身体会，您可以设计一个小测试程序，这个程序当且仅当期望的条件得到满足时才可以编译。将它保存在一个临时文件中，然后尝试编译它。例如，假定您想知道 X Windowing System 是否安装在 /usr/X11R6 目录下。一种方法是做一个如下的测试程序：#include <X11/X.h
int main(void) { return 0; }现在，如果您用编译器来尝试进行编译，那么只有当 <X11/X.h 在编译器的 include 路径中时，编译才会成功。因此，对每一个您认为 X 可能安装到的目录，可以将对应的 (directory)/include 加入到编译器的 include 路径中，并尝试对程序进行编译。如果采用某个值时示例文件可以编译，那么您就得到了正确的 include 路径。
请注意在 autoconf 中已经预定义了各种测试程序。如果可能，就直接使用这些测试程序，而不用自己去写。这样有很多好处。首先，autoconf 的新版本会改进这些测试程序，修正它们的错误，否则您将不得不自己去做这些工作。其次，这样会节省您的时间。当然，更好的方法是完全避免测试。如果您确认某一个测试是没有必要的（例如，即使机器字节多于 8 位也仍需要使 sizeof(char) 为 1），您可以完全不去进行这个测试。
有一些测试是功能测试；它不足以确定是否存在一个名为 memcmp() 的函数，它的语义必须正确。通常，这些测试用于只是在一两个平台上被注意到的非常不明显的错误。这些测试实际上会去运行测试程序，并检查它的输出。测试程序遵循标准的 Unix 习惯：如果测试通过则返回值为 0，如果失败则返回一个非 0 值。
一旦您有了足够的测试程序，您可以用它们来自动确定必需的编译标记和定义，以将它们放到头文件的某个地方。通常，configure 脚本会允许用户给出部分或全部已知的条件，而不是让脚本自己去猜测。
来看一个特例，假定，系统的 brokenmemmove() 出现了问题。如果您不知道它现在有一个只会影响少部分程序的 bug，您可能会编译一个程序并将其发布为产品，而没有意识到这样您将会遇到偶然的灾难性错误。
在许多情况下，一个冗长而复杂的 configure 脚本的最终结果是这样的：目标系统提供了这个程序用到的每一个标准特性，而且它们正确工作。在这种情况下为什么不手工去设置这些标记呢？这对开发者来说是可行的，而对众多用户来说就不可以了。用户可能不会知道到他们的 Linux 版本存在特定的 bug。他们可能不知道已经安装了哪些软件包，或者安装到了何处。脚本帮那些最需要帮助的人来完成大部分的例行公事的工作。当脚本出错时，引发的额外工作的代价可能不会太大。
错在何处？既然您已经基本上了解了 configure 都做了些什么工作，您可以开始寻找错误了。有两种可能的 configure 错误。一种是 configure 是正确的，而您的系统缺少必要的先决条件。绝大多数情况下，configure 脚本会正确诊断出这种错误。更为麻烦的情况是 configure 本身的错误。这样的结果或者是不能生成配置，或者生成一个不正确的配置。
当 configure 的猜测无误，而您缺少先决条件时，您所要做就是要满足缺少的那些先决条件。当您找到并安装好后，再重新运行那个报告缺少先决条件的 configure 脚本，就可以成功了。（不要忘记删除 config.cache 文件，这个文件缓存了上一次测试的结果；您应该让 configure 从头开始。）如果您正在开发 configure 脚本，您需要确保您给出的错误消息有意义。如果您测试的是一个函数，而这个函数是一个常见的可添加的软件包的一部分，那么不要告诉用户缺少的函数的名称 —— 告诉用户他们需要的软件包。确保将先决条件信息写入 README 文件中。并且，请一定要告诉人们您测试使用的其他软件包的版本号。
阅读文档无论何时，当 configure 失败时您首先要做的是运行 configure -h，并检查参数列表。如果它找不到您确认已经安装的库，您可能可以指定到另一个位置来找到这个库。您还可以禁用和启用某些特性。例如，用于 Angband （一个 Roguelike 游戏）的 configure 脚本有一个可选的标记 —— enable-gtk，以告诉脚本在编译时启用 GTK 支持。如果没有这个标记，编译时根本不会去尝试。
如果您的系统配置得比较奇怪，您可能不得不为 configure 脚本设置一些非常详细的变量，而且如果是在交叉编译，您很可能得做一些非常特别的事情。CC 是 configure 用于指定 C 编译器的变量，通过指定 CC 的值可以解决许多问题。如果您指定了编译器，configure 将使用那个编译器而不用去猜测需要使用哪一个。要注意的是，这样您可以在命令行中指定选项和标记。例如，如果您希望编译时支持调试符号，尝试：CC="gcc -g -O1" ./configure（这里假定您使用的是 sh 系列的 shell；在 csh 中，用 setenv 来设置环境变量 CC。）阅读 config.log当 configure 脚本运行时，它会创建一个名为 config.log 的文件，其中记录的是测试日志和得到的结果。例如，一个典型的 config.log 片断如下：清单 3. config.log 的典型内容configure:2826: checking for getpwnam in -lsun
configure:2853: gcc -o conftest -g -O2 -fno-strength-rece conftest.c -lsun &5
ld: cannot find -lsun
configure:2856: $? = 1
configure: failed program was:
(a listing of the test program follows)如果我的系统中，-lsun 应该提供 getpwnam()，我应该可以使用命令行来对其进行确切检查，然后再使用测试程序。只需进行少量这样的调试，我就可以根据得到的信息来修改 configure 脚本。请注意有帮助的行号；这个测试从 configure 脚本的第 2,826 行开始。（如果您是一个 shell 程序员，您可能会喜欢在阅读 configure 脚本片断时打印出行号；在 shell 中 $LINENO 不能自动地被扩展为合理值，脚本使用 sed 创建一个包含有行号的自身拷贝！）当一个测试失败或者得到意外的结果时，最好先去读一读日志文件。请注意，有时测试失败仅仅是因为上一个测试的失败，这种失败实际上并不重要。例如，configure 可能会因为找不到一个您闻所未闻的库而退出，而这可能是因为测试标准 C 库中某个功能的程序失败而导致无法找到那个库。在这种情况下，只需要解决第一个问题，第二个问题也就不会再出现了。
一种情况是测试程序设计不正确而可能