О кодах, загрузке и компиляции. Часть 2.
Продолжим начатое здесь.
Загрузка lsp сама по себе, конечно, интересна, но... Но быстродействие скомпилированного fas'a может быть в несколько раз выше. Разберем компиляцию сборника lsp в единый fas-файл.
Можно сказать, что уже разработана функция, позволяющая определить "приоритет загрузки" каждого файла (естественно, при условии, что имена файлов и имена функций можно отфильтровать по какому-либо критерию). Сортировка полученного списка особых трудностей не представляет (точнее, не должно представлять) - обычный vl-sort. Выполнить эту функцию в момент загрузки документа тоже по идее недолго (примерно 300 файлов обрабатываются около 2 секунд). Но это может работать только на некомпилированных файлах lsp. С компилированными файлами подобный фокус, скорее всего, не прокатит (скажу честно - лично я не пробовал).
Известно, что скомпилировать несколько файлов lsp в один fas в принципе несложно - создается новый проект, задаются ему некоторые условия, загружаются исходные коды и вуаля, готов fas. Но загружать в один проект хотя бы 50 взаимосвязанных lisp-файлов руками - удовольствие заметно ниже среднего. И потом, что мы, зря, что ли, столько корячились? Нет, конечно!
В версиях до 2006 включительно (возможно, и в 2007 - не проверял, не знаю) последовательность внесения lsp-файлов в проект fas'a никакой роли не играла. Похоже, что выполнение и окончательная "сборка" происходили в памяти уже после загрузки. В 2008 ситуация изменилась: "доводка" кода не выполняется, и, если есть самозапускаемые функции, то на момент их загрузки AutoCAD уже должен иметь в памяти загруженные "подчиненные" функции. Если этого нет, то что при загрузке обычных lsp, что при загрузке скомпилированного (кстати, успешно скомпилированного!) fas'a можно запросто получить сообщение вида:
Функция fun1: ошибка выполнения. Не определена функция fun2
Текст пишу по памяти, но суть от этого не меняется: после первого же такого сообщения можно смело говорить о неработоспособности (ну, или неполной работоспособности - хрен редьки не слаще) сборника.
Если для lsp-файлов вроде бы решение найдено (да, я помню, что оно не до конца показано), то для компиляции его, казалось бы, нет пока вообще ни в каком виде. Хотя это не так.
Проект fas в версиях до 2006 описывался одним файлом *.prj (обычный текстовый файл, кодировка полностью Windows, безо всяких выкрутасов с UTF-8), а вот с 2008 добавился еще один файл - *.gld. По крайней мере - понадобился для компиляции. Возможно, существование *gld-файла допускалось и ранее, но его наличие не было настолько критичным: в 2008 и дальше fas-файл лично у меня без *.gld-файла получался нерабочим. Может, руки кривые, не знаю...
Если разобрать "по косточкам" оба этих файла, можно увидеть, что их достаточно просто формировать именно программно - лиспом. Получается, что:
- Исходные файлы должны загружаться в память в строго определенной последовательности
- Эта последовательность может быть определена единственным образом, и это мы уже умеем делать
- Для компиляции сборника в fas вносить исходные файлы в проект надо в той же последовательности
Получается, что, открыв VLIDE, мы можем написать код, который:
- Сформирует эту последовательность
- Создаст prj и gld-файлы
- Создаст новый проект
- И скомпилирует его
Почему это надо выполнять именно в VLIDE? Именно из-за последнего пункта - компиляция исходников в fas допустима только внутри VLIDE.
Даже не знаю, надо ли подробно рассматривать prj- и gld... Там все достаточно просто и понятно.
P.S. Полтретьего ночи, обалдеть! Не, с готовыми кодами сегодня я уже пас...
