问题与以下构建命令有关，该命令是我从一个迷失的程序员那里继承的项目的一部分，我无法要求他解释它。这个项目基于alsa-utils的“延迟”示例，他已经将其扩展为提供其他功能。这个命令在项目中起作用，但我想开始剥离项目中所有未使用的垃圾，我需要了解这里的内容。我可以编程C并使用基本意义上的gcc，但我不太理解下面的命令。我想知道是否有人能证实我下面的假设并解释几点：
我有这个命令来构建项目：
如果g c c-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&&/bin/bash../libtool--tag=CC--mode=link gcc-lvgagl-lvga-Wall-pipe-g-g-O2-o延迟。o../src/libasound.la
我想我明白这里发生了什么。Wall=warnings，pipe=inrelative，-g=debugging stuff，-O2 optimization stuff，-MT生成一个对象文件而不是可执行文件，总的来说，命令的第一位意味着从latency.c创建一个依赖项列表，并编译latency.o。该依赖项文件将被称为.deps/latency.Tpo。
如果第一个命令返回success，则将.deps/latency.Tpo移动到.deps/latency.po，如果返回failure delete.deps/latency.Tpo。
然后只要删除或移动成功，就运行最后一位（在&&&之后）。将latency.o、../src/libasound.la、lvgagl和lvga链接到可执行延迟中。
目前这个项目使用svgalib，我不需要它来做，所以我将首先删除它，然后我假设我可以从libtool命令中删除-lvgagl-lvga。
但是我完全不理解'-DHAVE_CONFIG_H-I.-I.-I../include-I../include'部分。我知道-我是一个头文件搜索路径，但为什么要重复两次那达夫的配置是什么意思？如果依赖项文件不再使用（在libtool步骤中，我看不到其他对它的引用），为什么还要费心制作它呢。
最佳答案
大多数垃圾都是由automake和autoconf自动生成的；您可以忽略它。
复制的包含路径不会造成伤害，因此没有人愿意避开它们。-DHAVE_CONFIG_H由autoconf生成，但未被alsa-lib中的任何代码使用（也未被latency.c使用）。
其中唯一的非标准选项是-lvgagl -lvga库，您已经知道如何处理这些库。
当移动到另一个构建系统时，其他所有内容都可以忽略；默认设置可以正常工作。
关于c - Alsa项目的编译选项，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/25611399/