slay93 Вроде ребята тут бывают, или как минимум читают. Надеюсь что заметят, учтут и сделают. Было бы не плохо. А пока суть да дело имеем с SVN (кусок лога скрипта):
Цитата: U J:\Temp\fardev\unicode_far\syntax.cpp
U J:\Temp\fardev\unicode_far\macro.cpp
U J:\Temp\fardev\unicode_far\editor.cpp
U J:\Temp\fardev\unicode_far\vbuild.m4
U J:\Temp\fardev\unicode_far\macroopcode.hpp
U J:\Temp\fardev\unicode_far\changelog
Checked out revision 3195
На реалии Far 2.0.1010.3195. В GCC собрался, теперь осталось только EMenu собрать и поправить адреса в .REG-файлах плугина FTP. Ну, с последним sed в пол-оборота у меня разбирается.
Что бы ещё хотелось, так это наконец попросить разработчиков разобраться с .REG файлами плугина FTP - он под Far 2 хранит настройки в подключе
[HKEY_CURRENT_USER\Software\Far2\Plugins\FTP], а в исходниках этот факт не учитывается. В итоге после сборки плугин по идее должен их хранить в старом ключе
[HKEY_CURRENT_USER\Software\Far\Plugins\FTP], где он их естественно не ищет, и не найдёт никогда.
Пора бы разработчикам добавить вызов convert в мэйки, но и для меня не сложно сей древний баг прибить.
Хотя, делать это при каждой сборке достало - обновил исходники - SVN ругается, добавил команду в майки - не предсказыемо что с ними будет через час.
Правда, плугин FTP этим недостатком страдает не в одиночку, это беда большинства плугинов - код переписывают под Far 2, а .REG-файлы, иной раз заковыристые и объёмные как были написаны во времена царя Гороха и покорения Азова донскими казаками, так и остались для Far 1. Объяснение этому - общее - "Сохранение совместимости проекта с ANSI Far!. Эти файлы используются и в ANSI и в UNICODE проектах!". По моему, это не разумно, а говоря по честному прикрытие банального нежелания что-то менять.
Вот ещё что пока не понял: Far 2.0.1010/2.0.1011. Проверяем executor (ошибку Mantis#0000947) - для этого используем простой батник в двух вариантах:
Цитата: start cmd /k make --version
pause
и
Цитата: make --version
pause
набираем в командной строке команду
make --help и запускаем её итог у меня оказался не неожиданным - дерево! запущенных процессов CMD.EXE и 100% использование процессорного времени системой. Прибил через Process Explorer всё древо оптом. Интересно, а что стало причиной такого эффекта? Первый раз такое вижу, ничего не понимаю...
Такое впечатление что возникает вложенный автовызов батника столь необычным сочетанием параметров и make воспринимает собственный вывод как команду. Но его то- в процессах нет! Там только дерево
cmd.exe! Интересно, всё же, что вызывает такой эффект? На FreeBSD вложенное дерево вызовов sh при установке пакетов видел не раз, норма, но на WinXP SP3???