c - 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 中不起作用。它最终吐出的预定义是这样的:

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

显然它没有从上面的代码中得到任何返回值。当然，这会导致 macronames must be identifiers 错误。我可以通过在 readlink 和文件名之间添加任何特殊选项来解决这个问题，例如 -f，但它只会吐出

-DOPENGL -DGRAVITY -DBOUNDARIES -DCOLLISIONS

这是不对的，因为它应该有额外的位，像这样:

-DOPENGL -DGRAVITY_DIRECT -DBOUNDARIES_OPEN -DCOLLISIONS_NONE

现在，如果我不想要任何特殊的重力、边界或碰撞，解决方法是可以的，但这只是因为(我猜)如果每个宏名后没有特别指定，它默认为那些。但是如果我确实想要一些特别的东西，比如更有效的重力树代码，或者实际的碰撞，变通方法产生的缩短名称将无助于它找到任何东西，因此它会导致编译错误，因为它需要特殊文件的某些功能显然都不见了。

所以我现在很困惑。我非常希望能够使用默认代码以外的其他代码，但是 MSYS 对阅读链接表现得很滑稽，没有找到正确的东西。正如我所说，它在 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 安装程序所见):

The msys-coreutils-bin subpackage contains those applications that were historically part of the standard MSYS installation. The associated msys-coreutils-ext subpackage contains the rest of the coreutils applications that have been (nominally) ported to MSYS -- usually these are less often used, and are not guaranteed to work: e.g. 'su.exe', 'chroot.exe' and 'mkfifo.exe' are known to be broken.

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

可能还值得注意的是，readlink 不在支持工具列表中，GNU Coding Standards允许符合要求的应用程序从其 configure 脚本或其 makefile 调用。因此，MinGW.org 开发人员(维护 MSYS)几乎没有动力去解决使 readlink.exe 工作的问题，(尽管来自独立开发人员的补丁具有这样的动力，将受到欢迎)。

作为最后的资格，作为对问题注释的评论，ln -s 创建文件的副本；它不创建符号链接(symbolic link)。怎么可能呢？ MSYS 本身可以追溯到 windows 不支持符号链接(symbolic link)的时代……事实上，即使在今天，它对符号链接(symbolic link)的支持也很不稳定。在发布 MSYS 时，复制文件或创建 NTFS 硬 链接是 MSYS 在脚本调用 ln -s 的情况下可以提供的最佳折衷方案>。因此，任何开发人员都有责任提交补丁以使 readlink.exe 正常工作，同时解决更新 ln.exe 的问题，以便它可以创建符号链接(symbolic link)，(以操作系统版本相关的方式)，然后 readlink.exe 将读取。

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