问题涉及以下构建命令，它是我从遗失的程序员继承的项目的一部分，我不能要求解释它。该项目基于alsa utils的“延迟”样本，他已将其扩展为提供其他功能。该命令适用于该项目，但我想开始剥离项目中所有未使用的垃圾，我有点需要了解这里发生了什么。我可以编程C并在基本意义上使用gcc但我不太了解下面的命令。我想知道是否有人可以在下面确认我的假设并解释几个方面：
我有这个命令来构建项目：
如果是gcc -DHAVE_CONFIG_H -I。 -一世。 -I ../ include -I ../ include -Wall -pipe -g -g -O2 -MT latency.o -MD -MP -MF“.deps / latency.Tpo”-c -o latency.o latency。 C;然后mv -f“.deps / latency.Tpo”“。deps / latency.Po”;否则rm -f“.deps / latency.Tpo”; fi＆amp;＆amp; / bin / bash ../libtool --tag = CC --mode = link gcc -lvgagl -lvga -Wall -pipe -g -g -O2 -o latency latency.o ../src/libasound.la
我想我明白这里发生了什么。 Wall = warnings，pipe =无关紧要，-g =调试东西，-O2优化东西，-MT制作一个目标文件而不是可执行文件，整体而言命令的第一位意味着从latency.c创建一个依赖列表，并且还编译latency.o。依赖文件将被称为.deps / latency.Tpo。
如果第一个命令返回成功，则将.deps / latency.Tpo移动到.deps / latency.po，如果它返回失败，则删除.deps / latency.Tpo。
然后只要删除或移动成功，就运行最后一位（在＆amp;＆amp;之后）。将latency.o，.. / src / libasound.la，lvgagl和lvga连接成可执行的延迟。
目前该项目使用svgalib，我不需要它，所以我将首先删除它，然后我假设我可以从libtool命令中删除-lvgagl -lvga。
但是我完全不明白'-DHAVE_CONFIG_H -I。 -一世。 -I ../包括-I ../ include'部分。我知道-I是头文件搜索路径，但为什么重复两次？ DHAVE_CONFIG_H是什么意思？如果不再使用依赖文件，为什么还要制作依赖文件（在libtool步骤中我看不到其它的引用）。
答案 0 :(得分：0)
大多数垃圾由automake和autoconf自动生成;你可以忽略它。
重复的包含路径不会受到伤害，因此没有人愿意避开它们。
-DHAVE_CONFIG_H由autoconf生成，但alsa-lib中的任何代码均未使用latency.c。
这里唯一的非标准选项是-lvgagl -lvga库，您已经知道如何处理它们。
移动到另一个构建系统时，其他所有内容都可以忽略;默认值可以正常工作。