我正在尝试通过以下方式链接使用SCons创建的静态库：
//LIBSUFFIX and PREFIX are already set
env.Replace(LINKCOM = '$LINK $LINKOPTFILE $LINKMIXEDOPTIONS $LINKERR $LINKMAPFILE $SOURCES $LINKFILE $_LIBDIRFLAGS $_LIBFLAGS -o $TARGET')
env.Library('libraryname', ['file1.o','file2.o'])
env.Program(target = '', LIBS = 'libraryname', LIBPATH = 'path', source = Glob(*.c))
我的问题如下：在LINKCOM中添加的库没有其位置ex ：libraryname.a。库中已经包含的文件也将传递给链接器命令（例如SCons无法识别我正在使用它们创建库）
例如：我必须从以下来源创建程序：main.c s1.c s2.c s3.c和library_s.a从s1.o和创建库s2.o。
SCons传递的链接器命令：
linker.exe linkerflags s1.o s2.o s3.o library_s.a -o target.exe
如何将每个目录_LIBDIRFLAGS与其相应的库连接起来，如何使SCons知道我正在从某些源文件创建库？
编辑：这是链接器命令应如下所示的方式：
'linker.exe' linkerflags s3.o pathtolibrary/library_s.a -o target.exe
备注：由于library_s.a是从s1.o和s2.o创建的，所以我希望SCons仅传递s3.o和库
您只需将lib的完全必需的路径添加到Program()调用中即可：
lib_a = env.Library('libraryname', ['file1.c','file2.c'])
env.Program('target', ['main.c', 's3.c', 'pathtolibrary/' + str(lib_a[0])])
如果告诉Glob()您查找所有C文件（“ *.c”），它将返回完整列表。如果这不是您想要的，则必须Glob手动或使用从v2.3.5开始可用的“排除”选项来过滤调用结果（仅适用于VariantDirs，此功能仅从v2.4.1中的相应修订开始！） 。
不幸的是，您对SCons的运行方式的期望，对lib源文件和目标文件之间的依赖关系的自动检测的期望与现实不符。通常要做的是重组构建，以使该lib的所有C文件都位于与主要源文件不同的子文件夹中。然后，您可以Glob(*.c)再次使用，而不会出现干扰源列表。请注意，如何像s2.o第二次那样将目标文件添加到最后的链接步骤实际上可能有意义，例如，在循环依赖的情况下...因此，SCons（或任何其他构建系统）将无法全部解决这个问题反正本身。解决此类问题将始终需要用户的输入。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句