最近倒腾Linux C/C++项目。以目前的情况来说，要生成编译（build）一个Linux工程脚本，首选的工具必定是CMake。这也是我之前Linux项目的首选。不过自从VS IDE支持Linux C/C++开发后，也尝试这通过一些小demo来体验MS的解决方案。总得来说还可以，但是有个大问题因为一直没时间搞，就没有深入。
这里通过一个假定的场景来说这个问题。
在VS Linux项目里，如果一个解决方案下面有多个工程，比方说有两个工程A（.out）和B（.so），当工程A依赖工程B时我们需要设置工程的依赖关系，保证编译工程A时能先把依赖库编译出来。设置方式如下图：
设置完依赖关系后还要保证编译A时能够链接到已经生成的libB.so。这需要在工程属性页里Configuration Properties / Linker / Input : Libraries Dependencies里加上B。当然这还不够，因为链接指定的是so的名字，并没有指定so的路径。所以，要找到so必须知道so文件在哪里。除了使用绝对路径外，更好的方案显然是指定库文件的目录。正常情况下，类库文件都会统一编译到一个指定的目录下。
在VS的环境里，本地$(SolutionDir)默认映射到远程的$(RemoteRootDir)。而$(RemoteRootDir)默认是"~/projects"。所以如果统一将二进制文件编译到$(SolutionDir)bin$(Platform)$(Configuration)的话，对应地，在远程Linux上会被部署在"$(RemoteRootDir)/bin/$(Platform)/$(Configuration)"目录下。于是通过属性页向Configuration Properties / Linker / General : Additional Library Directories添加"$(RemoteRootDir)/bin/$(Platform)/$(Configuration)"就从理论上解决了链接时-lB到哪里找libB.so的问题了。但是，经过尝试之后你会发现，这样做并没有解决链接时找不到libB.so的问题。
之前并没有长期做Linux开发，所以对GCC编译选项的使用也就主要花时间看了看各种警告选项。对于大小L的链接选项，也是一样，只是知道是干嘛，但是对于输入字串的格式是不是有严格要求还真不知道。于是，我就遇到了本文要说的这个问题。只要Additional Library Directories里的路径是通过"~"来定位的，就必然会遇到VS环境下编译时找不到库文件的问题（当然我并不清楚在Linux上直接使用GCC编译链接是不是会遇到同样的问题）。
要解决这个问题，要么向前文说的，使用绝对路径。这显然不是个好方法，特别是自定义的类库比较多的时候。另外一种方法是将"~"使用绝对路径替换。也就是说将$(RemoteRootDir)的值从"~/projects"改为"/home/user_name/projects"。这就得保证在多个机器上使用VS远程编译时机器上的用户名都是同一个，不然要不停地改，也是作孽。
其实最好的方法是将$(RemoteRootDir)改为"$HOME/projects"。
完~