Readlink未找到C文件(MSYS)

Question

不久前，我就这个问题提出了一个问题，并通过使用Cygwin代替它的XWin实用程序来“解决”了它，但是我又回到了这个问题，因为Xwin实用程序不使用我的GPU，因此在模拟中造成了一个严重的瓶颈。另一方面，MinGW/MSYS确实使用我的GPU绘制，这是一个巨大的帮助，但有一些粗糙的领域，需要平滑，特别是与重新链接。

基本上，src/makefile for says (https://github.com/hannorein/rebound)是这样说的：

PREDEF+= -D$(shell basename `readlink gravity.c` '.c' | tr '[a-z]' '[A-Z]')
PREDEF+= -D$(shell basename `readlink boundaries.c` '.c' | tr '[a-z]' '[A-Z]')
PREDEF+= -D$(shell basename `readlink collisions.c` '.c' | tr '[a-z]' '[A-Z]')

如果我的理解是正确的，那么应该找到我指定的重力、边界和碰撞的哪个版本，并将其添加到PREDEFS中，以便编译器使用重力、边界和碰撞的正确版本。然而，它似乎不适用于MSYS。它最后会吐出来做伪证的是：

-DOPENGL -D.C -D.C -D.C

显然，它没有从上面的代码中得到任何东西。当然，这会导致宏名必须是标识符错误。我可以通过在readlink和文件名(例如-f )之间添加任何特殊选项来解决这个问题，但是之后它只会弹出。

-DOPENGL -DGRAVITY -DBOUNDARIES -DCOLLISIONS

这是不对的，因为它应该有额外的比特，如下所示：

-DOPENGL -DGRAVITY_DIRECT -DBOUNDARIES_OPEN -DCOLLISIONS_NONE

现在，如果我不想要任何特殊的重力，边界或碰撞，解决办法是可以的，但只是因为(我猜)默认的那些，如果没有特殊指定的每个宏名。但是，如果我确实想要一些特殊的东西，比如更有效的重力树代码，或者实际的冲突，由解决方案产生的缩短的名称将不会帮助它找到任何东西，因此它会导致编译错误，因为它需要从特殊文件中的某些函数显然是缺少的。

所以我现在被困住了。我非常希望能够使用默认代码以外的其他代码，但是MSYS在使用readlink时表现得很有趣，而且找不到正确的内容。正如我所说，它在X windows风格的编译器中工作得很好。我觉得一定有我缺少的库，或者我忽略的一些隐藏语法断开，需要在XWin和非Xwin编译之间进行解释，但是我什么也找不到。

下面是它应该阅读的链接的一个例子(至少我认为这是正在阅读的链接，我仍然在学习makefiles)：

ln -fs gravity_tree.c ../../src/gravity.c
ln -fs boundaries_open.c ../../src/boundaries.c
ln -fs collisions_none.c ../../src/collisions.c

如果有人能告诉我为什么这会在Xwin命令行上工作，而不是MSYS，我会非常感激的。

Answer 1

你到底为什么期望readlink在MSYS工作？您在哪里得到了调用readlink.exe的消息(如果这是正在执行的)？在标准的MSYS安装中没有readlink命令。也许您是在MinGW.org的msys-coreutils-ext包中发现的？如果是这样的话，您应该注意该包描述中的注释(如MinGW.org的mingw-get安装程序所示)：

msys-coreutils-bin子包包含那些历史上属于标准MSYS安装的应用程序。关联的msys- coreutils -ext子包包含其他已(名义上)移植到MSYS的coreutils应用程序--通常这些应用程序使用频率较低，且不能保证工作正常:例如，“su.exe”、“chroot.exe”和“mkfifo.exe”已知被破坏。

而且，我们似乎可以将readlink.exe添加到“已知被破坏”应用程序的列表中。

还值得注意的是，在支持工具列表中，readlink是而不是，符合GNU编码标准的应用程序可以从其configure脚本或makefile调用这些工具。因此，对于(维护MSYS的) MinGW.org开发人员来说，几乎没有什么动机来解决使readlink.exe工作的问题(尽管来自具有这种激励的独立开发人员的补丁将受到欢迎)。

作为最后的限定条件，以及对问题说明的评论，ln -s创建了文件的副本；它做的是而不是创建符号链接。怎么可能呢？MSYS本身可以追溯到windows不支持符号链接的时代.事实上，即使在今天，它对它们的支持也是零碎的。在MSYS发布时，要么复制文件，要么创建NTFS 硬链接，这是MSYS在脚本调用ln -s的情况下所能提供的最佳折衷方案。因此，任何提交补丁以使readlink.exe工作的开发人员都有责任解决更新ln.exe的问题，以便它能够创建符号链接(以操作系统版本依赖的方式)，然后readlink.exe将读取这些链接。

如果这不是您希望的答案，我很抱歉，但是除非有人致力于更新MSYS，以便它能够在最近的windows版本中使用(不可靠的)符号链接功能，否则您需要找到一种不同的方法；当前的MSYS不支持符号链接，即使底层操作系统现在支持。