我在Linux上开发了与其他人共享的项目并使用qt creator。
问题是我多次链接错误，特别是因为这种情况发生：
libA使用libB - > libA必须链接到libB
libC使用libA - > libC必须链接到libA和libB
appZ使用libC - > appZ必须链接到libC，libA和libB
对我来说理想的是，在我的appZ .pro文件中，我只需编写：“链接到libC”，然后自动获取其他依赖项。
这是因为经常会发生某人更改其中一个库的依赖关系以及许多难以解决链接问题的人来打招呼。
有没有办法以某种方式设置qt creator，只能指定最直接的依赖项，如果是，是否有任何缺点？还有其他选择吗？
我正在调查连接标志--no-undefined，但仍然没有理解这是否会对我有所帮助。
[编辑]只是为了澄清，问题是，如果100个应用程序使用libC，如果libC或其中一个依赖项必须链接到新库，则会成为一个大问题。所有应用程序都必须更改或者它们存在链接问题。我只是想找到一种方法来限制这个问题
良好的链接是一个广泛的主题领域，往往需要大量的时间和经验来理解一切。
要回答您的问题，没有人会在一夜之间更改库或文件的依赖关系。即使它们发生了变化，它们也会提供以前的版本以及新版本，并且它们提供了与该库的先前版本的向后兼容性（这意味着旧的API将起作用）。如果他们添加了一些新的依赖项来提供新的支持或功能，它们会详细提供您需要的新文件以及如何构建新库。
在许多情况下，如果您不想要任何新的支持，请使用该库本身的旧版本。但通常新的库有一些错误修复，更适合新版本。
我们使用库来减少我们的工作量，但令人惊讶的是，我们增加了一些工作量来构建第三方库，跟踪这些库中的更改和错误，解决链接错误等。遗憾地处理库并不是那么容易比较在Java或npm。
我所做的是在Linux中编写一个跟踪所有内容的脚本。但该脚本本身并不是自动化的，但它减少了我的大部分工作量。我想你也可以做类似的事情。
只是为了澄清，问题在于，如果100个应用程序使用libC，如果libC或其中一个依赖项必须链接到新库，则会成为一个大问题。所有应用程序都必须更改或者它们存在链接问题。我只是想找到一种方法来限制这个问题
在这种情况下很简单，只需在构建机器中构建新库，并在LD_LIBRARY_PATH中提供如此文件路径。据我所知，这并不容易，但如前所述，在Java或npm中处理库并不是那么容易。您可能还需要在用于维护构建的脚本中进行一些编辑。我没有看到任何捷径。