Question

有条件地设置package / lib _SOURCES或per-package / lib标志（CFLAGS，LDFLAGS，LDADD等）时，最好有条件地附加到包的标志，例如：

bin_PPROGRAMS = mypkg
mypkg_SOURCES = mypkg.c
if OS1
mypkg_SOURCES += os1.c
else
if OS2
mypkg_SOURCES += os2.c
endif
endif

或有条件地分配变量并将它们全部连接到包的标志中（无论是填充还是空），例如：

if OS1
os1_src = os1.c
else
if OS2
os2_src = os2.c
endif
endif

bin_PROGRAMS = mypkg
mypkg_SOURCES = mypkg.c $(os1_src) $(os2_src)

我已经看到了两种方式，我可以看到每种方式都有优势。对于前者，在条件中将这些标志添加到包中的实际最终操作是明确的，并且您还没有拥有在给定构建中实际上不具有任何意义的变量。在后者中，包中实际包含的内容在一行中合并，并且您不会在其他地方发生看不见的附件，但您可能不知道该不透明变量中发生了什么。名。

我想另一种选择是做类似于选项2的操作，但是使用configure脚本（configure.ac和AC_SUBST）分配变量。但我一直保持配置脚本纯粹检测可用功能，并选择在Makefile中使用哪些功能。

他们中的一个是否有技术上的缺点或令人讨厌的副作用？

Answer 1

你观察到的差异在很大程度上取决于风格，这是主观的，因此在很大程度上偏离主题。但你的实际问题非常客观：

他们中的一个是否有技术上的缺点或令人讨厌的副作用？

不，我都不知道。这两种方法都可以正常工作，至少是孤立的。较大的上下文可能提供了偏好第二种方法的变化的理由，例如将变量与多个目标结合使用。但是，对于预处理器或链接选项，情况更可能是选择源文件。

就个人而言，我会对你提出的具体案例进行一些不同的构建：

if OS1
os_src = os1.c
else
if OS2
os_src = os2.c
endif
endif

bin_PROGRAMS = mypkg
mypkg_SOURCES = mypkg.c $(os_src)

可以肯定的是，这是一种风格问题，所以不管它对你有什么价值。这里，变量的用法与条件的结构相匹配：OS1和OS2是 alternative ，因此在它们之间它们只控制一个变量的值。因此，该变量的含义在其设置值和使用点时都更加清晰。

多个变量对于多个不同的，不相关的条件更有意义。

Answer 2

我会添加一些更典型的模式：

os1_src = os1.c
os2_src = os2.c
if OS1
  myos = os1
endif
if OS2
  myos = os12
endif

mypkg_SOURCES = mypkg.c $($(myos)_src)

另一：

如果是OS1 os1 =是的 os2 =没有万一如果OS2 os1 =没有 os2 =是的万一 $（os1）src = os1.c $（os2）src = os2.c

mypkg_SOURCES = mypkg.c $(yessrc)

可以使用相同的方法来提供特定于os或处理器或配置的构建标志。通常，有一些常用设置用于多个模块，而其他标志则是特定于模块的。

每种方法都可能被滥用并导致令人讨厌的后果。

主要风险是一个模块的某些标志或设置无法正常重置，而另一个模块的某些设置将会溢出＆＃39;无意的。但是，有些模块可能会错过一些常见的标志。

为了降低这些风险，即使您的构建包含许多模块，也要尝试使用相同的技术。