Объединение нескольких исходников в один lsp
Возник тут как-то вопрос - можно ли безболезненно объединить несколько lsp-файлов в один? При условии, что этих "несколько" - пара-тройка сотен штук?
Казалось бы, все должно быть достаточно просто: используем vl-file-copy с указанием третьего аргумента. Ага, как бы не так!
К сожалению, я не могу найти источник, но где-то мелькала информация о том, что внутри одного lsp-файла не может быть больше 256 определений функций. Я сам сталкивался с тем, что такой "объединенный" lsp невозможно отформатировать и на его основе невозможно собрать fas / vlx.
Нельзя в лоб - пойдем в обход:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | (defun _kpblc-create-united-lisp (ref-list file / file handle count) ;| * Собирает все lsp в одну кучу * Параметры вызова: ref-list список объединяемых файлов file результирующий файл. Полный путь. Каталог файла уже должен существовать |; (setq count 0 handle (open file "w") ) ;_ end of setq (close handle) (foreach item (vl-sort ref-list (function (lambda (a b) (< (strcase (vl-filename-base a)) (strcase (vl-filename-base b))))) ) ;_ end of vl-sort (setq handle (open file "a")) (write-line "\n\n" handle) (if (>= count 200) (progn (write-line ")\n(progn" handle) (setq count 0)) ) ;_ end of if (close handle) (vl-file-copy item file t) (setq count (1+ count)) ) ;_ end of foreach file ) ;_ end of defun |
Введено принудительное ограничение в 200 вкладываемых функций, но его можно менять.
Собственно ссылка: _kpblc-create-united-lisp
Пока подобное работает - представить, что у меня будет необходимость одновременно в один файл загнать 40 000 функций, я не могу.
В подобном подходе кроется одна засада: внутри одного lsp можно хранить хоть сотню определений функций. И при прямом копировании такого файла внутрь объединенного мы получим ту самую ошибку, от которой пытались уйти. Выход, конечно есть, даже два:
1. Вручную пройтись по всем файлам и при необходимости экспортировать описания функций в отдельные lsp. Их уже и объединять
2. Выполнить то же самое, но программно.
Второй вариант лично мне больше нравится - ну не люблю я тупую работу! 
Алексей, а почему нельзя делать простую сборку Проекта в VLX-файл?
Конечно 40К функций это много, но вот их то и можно пообъединять по тематике в один/несколько LISP-файл/ов
В некоторых версиях ACAD'a (сейчас уже точно не помню, в каких именно) можно было получить очень забавный момент.
Допустим, есть f1, которая использует f2. И есть f3, которая использует f1. Если мы в fas / vlx проект просто положим f1.lsp, f2.lsp, f3.lsp, да еще и добавим самовызов f3, то приложение могло не скомпилироваться. Все будет работать, если мы положим функции в порядке их "зависимости": f2, f1, f3. Т.е. приходится либо высчитывать приоритет загрузки, либо загонять все в один lsp-файл (в таком случае ошибок при компиляции с сообщениями типа "вызывается неопределенная функция" не получаем). Вычисление приоритета загрузки та еще задачка, весьма ресурсоемкая.
В последних версиях подобное уже не встречается, кажется.
Уточнение: подобная ситуация лично у меня была на ACAD2016x64. Возможно, в других версиях все будет хорошо.
В крайнем случае можно опубликовать несколько безымянных функций и далее им передать список значений.
2
3
4
5
6
7
8
(list (read "mi+") (read "mi*") (read "mi/") (read "mi-"))
(list (lambda (a b) (+ a b)) (lambda (a b) (* a b)) (lambda (a b) (/ a b)) (lambda (a b) (- a b)))
)
(mi+ 1 2)
(mi* 1 2)
(mi/ 1 2)
(mi- 1 2)
Идея хорошая
Одно главное объявление, с неограниченной длиной списков 
Правда, у меня памяти не хватит такое держать в голове