Readlink 未找到 C 文件 (MSYS)

Question

不久前我问了一个关于这个主题的问题，并通过使用 Cygwin 而不是它的 XWin 实用程序“解决”了它，但我又回到了这个问题，因为 Xwin 实用程序不使用我的 GPU 并创建了一个严重的结果是模拟的瓶颈。另一方面，MinGW/MSYS 确实使用我的 GPU 进行渲染，这是一个巨大的帮助，但是有一些粗糙的区域需要平滑，特别是使用 readlink。

基本上，反弹的 src/makefile (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 中不起作用。它最终为 predefs 吐出的是：

-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 编译之间进行考虑，但我找不到任何东西。

这是它应该阅读的链接示例（至少我认为这是正在阅读的内容，我仍在学习 makefile）：

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 Coding Standards 的应用程序从其 configure 脚本或其makefile。因此，MinGW.org 开发人员（维护 MSYS）几乎没有动力去解决使readlink.exe 工作的问题（尽管来自独立开发人员的补丁，具有这样的动力，会受到欢迎）。

作为最后的限定，并且作为对问题注释的一个评论，ln -s 创建文件的副本；它确实不创建符号链接。怎么可能？ MSYS 本身可以追溯到 windows 不支持符号链接的时代......确实，即使在今天，它对符号链接的支持也很不稳定。在 MSYS 发布时，复制文件或创建 NTFS 硬 链接是 MSYS 可以提供的最佳折衷方案，在脚本调用ln -s 的情况下。因此，任何开发人员都必须提交补丁以使readlink.exe 工作，同时解决更新ln.exe 的问题，以便它可以创建符号链接（以操作系统版本相关的方式），@987654337 @ 然后会读取。

如果这不是您希望的答案，我很抱歉，但除非有人花一些精力来更新 MSYS，以便它可以利用更新的 Windows 版本中的（不可靠的）符号链接功能，那么您需要寻找不同的方法；当前的 MSYS 不支持符号链接，即使底层操作系统现在支持。