PT153, дело в том, что компилятор у меня это exe файл, запиленый на C++, а всякие параметры и настройки получает плагин к vscode - это мне нужно будет начинать передавать компилятору дополнительные параметры, чего я не очень хочу делать, отложил так уже несколько фич которые тоже требуют дополнительных флагов - вот когда будет билд-файл, то компилятор будет получать путь к нему и читать оттуда все дополнительные параметры, сколько бы их ни было.
Я думаю, что можно просто добавить опцию "Not include original code" (с пометкой, что это для advanced пользователей), из-за которой пункты сборки 1 и 4 будут просто проигнорированы.
PT153, я изначально хотел сохранить возможность расставлять юнитов и ректы в WE и писать гуи триггеры для настроек, поэтому вариант с полной заменой всего оригинального кода WE никогда не рассматривал. Если я когда-нибудь дойду до того чтобы запилить билдфайл по которому будет работать компилятор вместо автоматического режима - такая возможность появится, а раньше я врядли стану тратить на это время.
Автоматический режим сборки кода достаточно прост:
файл оригинального кода от WE компилируется, скомпилированная версия падает в папку .build, получает идентификатор MAP и добавляется в список на сборку
в указаной директории рекурсивно перебираются все LUA файлы, компилируются, складываются в .build, получают идентификаторы и требования из директив компилятора и добавляются в список на сборку
перед компиляцией каждого файла выполняется проверка на наличие его скомпилированной версии и сравнение дат, если компилировать файл заново не нужно, то просто читается его заголовок с директивами компилятора, а компиляция файла пропускается, файл сразу добавляется в список сборки
все файлы получают в требования MAP, чтобы оригинальный код от WE всегда шел первым в списке сборки
список сборки сортируется таким образом чтобы выполнялись все требования (если требования выполнить невозможно из-за рекурсии или несуществующих индикаторов файлов, то сборка кода фейлится, но пока это только в логе видно - код в любом случае собирается по списку сборки, просто не гарантируется выполнение всех требований )
все файлы из списка сборки мержатся в единое целое согласно списку и падают в фиксированное место одним файлом
при сборке карты в mpq сборщик подхватывает готовый код карты из известного места и копирует его в архив собираемой карты
Что касается магических файлов для main и config - я не очень хочу плодить магические файлы, работающие определенным образом только потому что они так названы без более явного действия со стороны пользователя.
Поэтому куда более вероятен вариант макроса --#REPLACE или INJECT, который заставит компилятор найти оригинал функции и стереть его, но пока парсер не готов к таким макросам т.к. индивидуально проходит все файлы по очереди, только один раз и в алфавитном порядке продиктованном системой.
prog, я думаю, что просто возможность создать отдельные файлы для config и main, если их нужно полностью заменить.
Как в принципе собирается код карты? Мне вот сгенерированный код от WE вообще не нужен. Было бы неплохо иметь возможность полностью заменять файл кода.
alexprey, это надо чтобы оптимизатор умел понимать что можно оптимизировать. Имхо, этот конкретный случай того не стоит. Банальная минификация сторонней либой и то больше профита даст при куда меньших затратах времени. Но как задача на когда совсем нечем будет заняться сойдет.
Единственный недостаток - если нужно полностью заменить main или config, а не дополнить их, то старый код этих функций останется в коде карты мертвым грузом.
Для этого по идее надо использовать отдельный шаг после компиляции - оптимизация кода
PT153, в этом нет большого смысла на уровне компилятора, ведь это можно реализовать силами самого Lua
Например у меня есть такой файл, main.lua
function InjectMain()
local alpha_main = main
return function()
local alpha_init = RunInitializationTriggers
RunInitializationTriggers = function() end
alpha_main()
InitLibraries()
alpha_init()
end
end
main = InjectMain()
Работает за счет того, что в отличии от WE, мой компилятор добавляет код из файлов после кода сгенерированого WE.
Единственный недостаток - если нужно полностью заменить main или config, а не дополнить их, то старый код этих функций останется в коде карты мертвым грузом.
Я про syntax check в самом VSCode. Я сказал "ПЕРЕД" для того, чтобы в алгоритме по удалению пробелов можно было засечь ошибку, да и всяко лучше запускать чекер после всех препроцессорных махинаций.
У меня немного другая идеология, которая заключается в том, что валидный код до препроцессора всегда должен выдавать валидный код после препроцессора и наоборот, не валидный код до препроцессора может выдать только не валидный код после препроцессора. Это немного сужает допустимый функционал препроцессора, но избавляет от огромного количества головной боли и хорошо интегрируется с существующими инструментами для работы с Lua.
Поэтому, например, не имеет смысла что-то чудить с пробелами перед синтакс чеком т.к. синтакс чек из WE просто не будет вызываться в 99% случаев.
Я про syntax check в самом VSCode. Я сказал "ПЕРЕД" для того, чтобы в алгоритме по удалению пробелов можно было засечь ошибку, да и всяко лучше запускать чекер после всех препроцессорных махинаций.
Что касается синтаксиса макросов - я не случайно пошел путем аннотаций к переменным вместо кода в комментах - в моем варианте с этим более-менее прилично работает обычный синтакс-чекер для Lua и мне не нужно писать кастомный.
Ещё бы я хотел, чтобы выражения в константах считались препроцессором.
На самом деле было бы хорошо делать вычисления для всех выражений без переменных, как это делает python.
Аналогично с макросом RAW - он принимает только значения в одинарных кавычках и имена констант чтобы проходить стандартный синтакс-чек. Более того, используется еще и объявление глобальной переменной RAW=FourCC, чтобы если что-то пошло не так с макросом, был шанс на срабатывание стандартного конвертера, ну и строгий синтакс-чек без этого не пройти.
BLOG-PROG
Комментарии проекта Эксперименты в Пустоте
Ломаем Warcraft3 1.31 полностью: Кастомный компилятор Lua
Ред. prog
Поэтому куда более вероятен вариант макроса --#REPLACE или INJECT, который заставит компилятор найти оригинал функции и стереть его, но пока парсер не готов к таким макросам т.к. индивидуально проходит все файлы по очереди, только один раз и в алфавитном порядке продиктованном системой.
Ред. PT153
Ред. prog
Например у меня есть такой файл, main.lua
Единственный недостаток - если нужно полностью заменить main или config, а не дополнить их, то старый код этих функций останется в коде карты мертвым грузом.
Ред. PT153
PT153: