应用程序的标准linux“make-install”，链接到正确的libs

我正在开发一个由大量二进制文件、脚本和lib组成的应用程序。在目前的开发过程中，我已经在我的存储库中构建并运行了：

myapp:
    bin/
    include/
    lib/
    scripts/
    src/
    Makefile

src/包含多个模块（libs或二进制）的代码。每个都有自己的makefile

运行make from myapp/为目标安装目录设置环境变量，然后递归运行make install，它为src/中的每个子模块使用环境变量

这将在myapp/的相关子目录中安装二进制文件、include和libs，因为环境变量就是这样设置的

现在我要在系统范围内安装，大概是在/usr/local中。我还对在开发myapp/时保持在本地构建和安装的能力感兴趣。可以方便地在myapp/bin/中运行二进制文件，而无需首先在系统范围内安装它们

我的第一个计划是保留默认的make目标，在myapp下创建可安装二进制文件libs，includes脚本，然后在myapp/Makefile中创建一个新的安装目标，该目标将这些可安装文件复制到/usr/local/sudo中

我的问题是，在开发过程中，二进制文件需要知道libs在哪里。我一直在用-Wl，-rpath=/path/to/myapp/lib链接到myapp/lib中的libs。但是，这不适用于系统安装的二进制文件，它们应该参考/usr/local/lib/

我可以看到几种解决方案，但都不是很好：

使用在/usr/local而不是myapp/中设置的环境变量target directories进行安装重建，而不仅仅是复制。缺点：我认为整个重建过程都需要sudo，而不仅仅是安装。 删除与-Wl，-rpath的链接，改为在开发时将LD_LIBRARY_PATH设置为包含myapp/lib，但不包括其他内容。很明显，这是我的。当我想在系统范围内运行时，我很容易忘记取消设置它，而本地libs将被错误地使用。 删除与-Wl，-rpath的链接，并要求在myapp/中本地构建二进制文件之前在系统范围内安装libs。这很麻烦，我想保留克隆我的回购协议并在本地一步构建的能力。 其他人可能有这个问题，我想知道是否有一个标准的解决方案

---

，但没有处理我链接libs的问题。

此处可能会用到$ORIGIN rpath值。看见话虽如此，我不认为LD_LIBRARY_PATH是个坏主意，但我建议将它包装在脚本中供开发人员使用，甚至可能是一个实现它的make目标。我相信自动工具可以在树内运行时包装脚本。为什么不创建另一个像dev这样的make目标，它将使用local-rpath执行构建，而默认的make builds用于部署？@EtanReisner:$ORIGIN听起来很有趣！即使安装在/usr/local/*中，它也应该可以工作。我正在重新考虑LD_LIBRARY_PATH，但我担心我经常挠头，试图弄明白为什么我在库中的更改似乎没有任何效果，结果却发现我使用的不是正确的。一个目标怎么能设定呢？它只会为这个make进程设置，如果我导出它，可能会为子进程设置，但不会为调用shell设置。@dekkard：这是可能的。但是我需要重新构建所有的lib和二进制文件进行安装，而不是只构建一次，然后安装我在本地测试的东西。make target的想法是一个rundev或类似的目标，它只是设置/运行脚本，该脚本使用LD_LIBRARY_PATH为开发人员的使用设置东西。是的，$ORIGIN的思想是二进制文件/库可以作为一个单元重新定位。