Readlink не находит файлы C (MSYS)

Question

Некоторое время назад я задал вопрос на эту тему и "решил" его, используя вместо этого Cygwin с его утилитой XWin, но я снова вернулся к этой проблеме, поскольку утилита Xwin не использует мой графический процессор и создает серьезное узкое место в симуляции. в следствии. 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. То, что он в конечном итоге выплевывает для prefires это:

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

Очевидно, что ничего не вернулось из кода выше. Это приводит к тому, что macronames должны быть ошибкой идентификаторов, конечно. Я могу обойти это, добавив любой из специальных параметров между readlink и именем файла, например, -f, но тогда он только выплевывает

-DOPENGL -DGRAVITY -DBOUNDARIES -DCOLLISIONS

Что не правильно, потому что у него должны быть дополнительные биты, например:

-DOPENGL -DGRAVITY_DIRECT -DBOUNDARIES_OPEN -DCOLLISIONS_NONE

Теперь, если я не хочу какой-либо особой гравитации, границ или столкновений, обходной путь приемлем, но только потому, что (я полагаю) он по умолчанию равен тем, если после каждого макронейма не указано ничего особенного. Но если я действительно хочу что-то особенное, например, более эффективный код дерева гравитации или реальные коллизии, сокращенное имя, полученное в результате обходного пути, не поможет ему ничего найти, и поэтому оно вызывает ошибки при компиляции, поскольку определенные функции необходимы из специальных файлов. очевидно отсутствуют.

И поэтому я застрял на данный момент. Я бы очень хотел иметь возможность использовать другие коды, кроме значений по умолчанию, но MSYS ведет себя забавно с readlink и не находит нужного материала. Как я уже сказал, он прекрасно работал в компиляторе стиля X Windows. Я чувствую, что должна быть какая-то библиотека, которую я пропускаю, или какое-то скрытое отключение синтаксиса, которое я пропускаю, которое необходимо учитывать между компиляцией XWin и не Xwin, но я ничего не могу найти.

Вот пример ссылок, которые он должен читать (по крайней мере, я думаю, что это то, что читается, я все еще изучаю make-файлы):

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 вызывается, (если это то, что выполняется)? Здесь нет readlink команда в стандартной установке MSYS. Возможно, вы обнаружили это в MinGW.org msys-coreutils-ext пакет? Если это так, вы должны отметить комментарий в описании этого пакета (как видно из MinGW.org's mingw-get Установщик):

Подпакет msys-coreutils-bin содержит те приложения, которые исторически были частью стандартной установки MSYS. Соответствующий подпакет msys-coreutils-ext содержит остальные приложения coreutils, которые (номинально) были портированы на MSYS - обычно они используются реже и не гарантированно работают: например, 'su.exe', 'chroot. Известно, что exe 'и'mkfifo.exe'не работают.

и, кажется, мы можем добавить readlink.exe в этот список "известных быть сломанных" приложений.

Также стоит отметить, что readlink не входит в список вспомогательных инструментов, которые разрешено вызывать приложению, соответствующему Стандартам кодирования GNU, configure сценарий или его makefile, Таким образом, у разработчиков MinGW.org (которые поддерживают MSYS) мало стимулов для решения проблемы создания readlink.exe работать, (хотя патчи от независимого разработчика, с таким стимулом, будет приветствоваться).

В качестве окончательной квалификации и в качестве одного комментария к примечаниям к вопросу, ln -s создает копии файлов; он не создает символические ссылки. Как это могло? Сам MSYS датируется эпохой, когда окна не поддерживали символические ссылки... действительно, даже сегодня его поддержка для них ненадежна. В то время, когда MSYS был опубликован, копирование файлов или создание жестких ссылок NTFS было лучшим компромиссом, который мог предложить MSYS, в ситуации, когда вызывался скрипт ln -s, Следовательно, он станет обязан любому разработчику, представляющему патчи для readlink.exe работать, чтобы также решить проблему обновления ln.exeтак, чтобы он мог создавать символические ссылки (в зависимости от версии ОС), которые readlink.exe тогда бы прочитал.

Я извиняюсь, если это не тот ответ, на который вы надеялись, но если кто-то не приложит усилий для обновления MSYS, чтобы он мог использовать (ненадежную) функцию символьной ссылки в более поздних версиях Windows, тогда вам нужно найти другой подход; текущий MSYS не поддерживает символические ссылки, даже если базовая ОС теперь поддерживает.