Вот уже на протяжении нескольких лет время от времени предпринимаются попытки прикрутить к Кикаду вывод текстовой документации. Например, на Кикад-фтп в свое время была выложена альфа-утилитка (если мне не изменяет память), которая преобразовывала кикадовский ВОМ в некое подобие перечня элементов, который выводился в МсВорд. Помнится, я попробовал тогда ею воспользоваться и обнаружил, что утилита очень сырая, т. к. перечень получался с какими-то непонятными полосами и прочими недоработками. Но не беда, ведь это только начао — подумал я, ведь со временем все наладится. Но, надежды не оправдались, т. к. дальнейшего развития не произошло, да и необходимость иметь на компе платный МсВорд для бесплатного Кикада как-то тоже не радовало. Словом, все заглохло.
Параллельно этой утилите другим форумцем велась разработка своего варианта такой важной полезняшки. Он со временем даже демонстрировал скриншот Кикада с новой иконкой по нажатию на которую можно было активировать функцию вывода документации по ГОСТ. Более того, однажды он написал на форуме, что до полного окончания работ осталась всего неделя, что привело меня в бурную радость.., однако, когда прошло больше года и я обескураженный решил спросить его на форуме когда же можно будет потестить разрабатываемую им мегафичу. К моему удивлению, он ответил, что давно забросил эту разработку т. к. не смог с какой-то тонкостью Кикада разобраться.
Я так и не понял тогда, зачем же он объявил всем, что практически все готово, т. к. неделя на вылизывание не в счет, В общем, опять все заглохло.
Конечно, работа ведется на энтузиазме в свое личное время, которого чаще всего не хватает и на более важные дела, поэтому нельзя ничего определенного ожидать. Но все же...
Прошло еще достаточно много времени и вот, на нашем форуме появляется желанное сообщение Барановского Константина:

Посмотрев на приаттаченный пример работы скрипта надежда на лучшее снова стала оживать, но опыт прежних неудач, когда тоже были продемонстрированы первые результаты, а потом пшик, заставлял приглушить радостные эмоции до момента тестирования готовой фичи, если, конечно, она будет реализована.
А дальше — больше, т. к. оказалось, что не только Константин занят разработкой вывода документации, но еще и AVL:

К тому же, возможно, они объединят свои усилия:

Но идет время и пока тишина... Неужели опять все напрасно? Хочется верить, что нет. Просто как всегда не хватает времени и еще все будет. Просто еще не время.
Как бы то ни было, я решил открыть эту тему для того, чтобы на ее страницах можно было обсуждать эту долгожданную мегафичу — вывод текстовой документации в Кикаде.

Немного обновил свой скрипт, изменений немного:

- добавил файлы для примера создания спецификации, описанного в руководстве;

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

Ну собственно и все. Скачать обновленный релиз можно отсюда https://launchpad.net/kicadbom2spec

Текущее состояние по GOST-doc-gen:
1) удается откомпилировать штатные исходники KiCad под винду только с помощью MinGW (перепробовал MS Visual C++ Toolkit 2003, MS Visual C++ 2008/2010 Express, ничем из перечисленного не удается откопмпилировать без ошибок)
2) с другой стороны OpenOffice/LibreOffice SDK поставляется с библиотеками под винду, которые можно линковать только с помощью MS Visual C++.
Таким образом, данный путь тупиковый. Единственное, что можно сделать - написать промежуточный проект-интерфейс (dll), соединяющий KiCad+GOST-doc-gen с OpenOffice SDK. Такой проект собирать с помощью MS Visual C++. Вариант не особо удобный.

Также размышлял насчет odfpy.

В результате решил добавить в GOST-doc-gen унифицированный интерфейс (класс COMMON_DOC_IFACE) для подключения различных модулей, реализующих какой-либо из способов подключения к офису, либо прямую генерацию файлов документов (например odfpy).

Весь специфический код по работе с OpenOffice/LibreOffice SDK вынес в отдельный модуль (класс OO_IFACE).

Дальше написал новый модуль с поддержкой odfpy (класс ODFPY_IFACE).
По odfpy вылезли следующие проблемы:
1) если открыть файл .odt и сразу же его без изменений сохранить, то в результирующем .odt файле "плывет" высота строк таблицы (то есть это баг odfpy).
2) оказалось, что odfpy поддерживает только абсолютную адресацию, которая полностью несовместима с именованной адресацией, используемой в GOST-doc-gen (вычислить одно из другого не возможно). В результате odfpy выбивается из построенной концепции унифицированного интерфейса (COMMON_DOC_IFACE).
По причине указанных проблем, пока принял решение отказаться от использования odfpy. По этой же причине исходники интеграции с odfpy пока не заливал.

В итоге набрел на еще один способ подключения к OpenOffice - использование Python-UNO.
И написал еще один модуль с поддержкой Python-UNO (класс OO_PYTHON_UNO_IFACE).

Отлаживался под Linux Debian 6.0.7. По крайней мере под Linux заработало. При использовании такого подхода (Python-UNO) ушли сложности с линкованием библиотек OO SDK.
Под винду еще не проверял, но по крайней мере линковать нелинкуемое уже не придется.

На данный момент предусмотрены следующие варианты сборки KiCad+GOST-doc-gen:
1) cmake ../. -DKICAD_STABLE_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON - собирать KiCad с генератором документов как таковым. При этом генератор будет работать на базе Python-UNO (без OO SDK)
2) cmake ../. -DKICAD_STABLE_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON -DUSE_OPENOFFICE_SDK=ON - вместо Python-UNO будет использоваться OO SDK

Пока думаю, что новый вариант сборки на базе Python-UNO (вариант номер 1) предпочтительнее.

AVL, в Ubuntu не хочет собираться (используя Python-UNO). Лог в приложении.

Попробовал собрать под Windows. Cкомпилировалось без ошибок, но не собралось (путаница с версией python 2.7/2.6). Скриншоты начала и конца прилагаю.

Константин, исправил в ревизии 4105.

Ubuntu 13.04 32-bit:


Пакет libreoffice-dev при такой конфигурации (сборка на базе Python-UNO без использования OO/LO SDK) устанавливать больше нет необходимости, но зато теперь нужны пакеты python-dev и python-uno (python-uno потребовался в случае ubuntu, я у себя на debian не ставил такой пакет).



Юрий, данную проблему исправил в ревизии 4105.
Под винду я еще недоотлаживал (в процессе). Там еще скорее всего сейчас вопросы выплывут.

Application: Eeschema
Version: (2013-05-05 BZR 4105 GOST)-testing
Build: wxWidgets 2.9.4 (wchar_t,compiler with C++ ABI 1002,GCC 4.7.2,wx containers,compatible with 2.8)
Platform: Windows XP (build 2600, Service Pack 3), 32 bit, Little endian, wxMSW

Сейчас все собралось до конца. Ошибка возникает по команде GOST Tools. Похоже не может запустить OpenOffice.
У меня XP и каталог программ - Program Files.

Да, сейчас под винду в KiCad пока захаркодил строку к офису: C:\\Program Files (x86)\\OpenOffice.org 3\\program\\soffice.exe
Пока это можно обойти введя в командной строке: soffice "-accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager"
Если напишет ошибку "soffice не является внутренней или внешней командой, исполняемой программой или пакетным файлом", то ввести полный путь, например:
C:\Program Files (x86)\OpenOffice.org 3\program\soffice.exe "-accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager"
при этом путь к soffice.exe указать фактический какой есть на установленной системе.
В данном случае KiCad все равно будет выдавать ошибку "unable to launch the process: ...soffice.exe", но выполнение пойдет дальше. Сделал так, чтобы в случае, если не удается из KiCad по какой-то причине запустить офис в режиме listening, то хотя бы дать возможность пользователю выполнить эту команду из ОС.

Не могу понять где в винде путь к офису прописывается. Если выполняю команду soffice из cmd.exe, то не находит что такое soffice.
Если же запускаю из far.exe, то находит soffice и запускает нормально.
Если выполняю команду soffice из KiCad, то тоже не видит, что такое soffice. При этом добавление в %PATH% не помогает в случае с KiCad.

...но дальше еще появится ошибка, что не может найти uno. Тоже пытаюсь понять, что сделать.

Снова ошибка:

Исправил в ревизии 4106.

Наконец-то заработало под винду. Единственное пока пришлось написать bat файл, в котором настраиваются пути к питону. В линуксе (debian, ubuntu) такой кривости нет.

1) нужно установить Python 2.6.6 (именно эту версию, http://www.python.org/ftp/python/2.6.6/python-2.6.6.msi). Если есть еще какие-то установленные версии питона, то их нужно либо деинсталлировать, либо переименовать временно директорию, чтобы cmake при сборке по ошибке не стал использовать какую-нибудь другую версию питона отличную от 2.6.6.

2) нужно установить OpenOffice 3.4.1 (именно эту версию).

3) нужно обновиться с lp:~al-lunev/kicad/GOST-doc-gen (на данный момент ревизия 4107).

4) выполнить сборку с опциями: -DKICAD_TESTING_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON
После сборки Python 2.6.6 в момент исполнения уже не потребуется кикаду. KiCad будет подгружать интерпретатор питона из офиса (все версии офиса распространяются вместе с питоном, который находится в директории офиса). Но и мешать никакой отдельно установленный питон не должен на этапе исполнения кикада.

5) установить собранный KiCad

6) отредактировать пути в файле KiCad-GOST-doc-gen.bat (путь к офису и путь к кикаду, см. вложение к сообщению) согласно путям к установленным программам на вашей машине

7) запустить KiCad-GOST-doc-gen.bat

При запуске KiCad-GOST-doc-gen.bat настраиваются пути к питону офиса; запускается офис в режиме listening (пока убрал запуск из самого кикада и перенес этот запуск в KiCad-GOST-doc-gen.bat, чтобы не вываливалась ошибка в кикаде на захаркоденый путь к офису); запускается кикад

----------------

Итог. В случае с виндой ситуация при применении Python-UNO стала лучше (хоть собирается теперь проект), но не идеальная.
При таком подходе есть зависимость между сборкой KiCad и версией OpenOffice / LibreOffice.
К примеру, если собрать KiCad по описанному алгоритму на базе Python 2.6.6, то KiCad будет работать только с OpenOffice 3.4.1 (ну и может еще некоторые версии офиса), в составе которого идет Python 2.6.6.
Если будем запускать к примеру LibreOffice 4.0.2, в составе которого идет Python 3.3.0 (и uno библиотеки собранные для именно этой версии Python 3.3.0), то сборка KiCad сделанная для Python 2.6.6 не будет работать с LibreOffice 4.0.2.

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

Так вот, какое у вас мнение? Можно с этим мириться или все-таки необходимо уйти от версионной зависимости?

На этот счет у меня есть новая идея X: запускать модуль uno_iface.py не из встраиваемого в KiCad Python-интерпретатора как сделано сейчас, а вместо этого запускать модуль uno_iface.py в питоне, идущем в поставке вместе с офисом. При этом превратить модуль uno_iface.py в сервер для KiCadа. То есть сделать следующую цепочку:
KiCad+GOST-doc-gen -> [uno_server.py -> office]
Взаимодействие между KiCad и uno_server.py сделать через TCP соединение.

При такой схеме тогда не должно быть никакой версионной зависимости.

Думаю все таки стоит избавиться от зависимости.

На ftp://ftp.kicad.ru/pub/kicad/kicad_eskd_d...ky_kicadbom2sp/
положил py-срипт К.Барановского для производства спецификации kicad на шаблоне LibreOffice.
Дополнительно сделан NSIS-скрипт для упрощения установки программы под Windows (пуск kicadbom2spec.exe).

Реализовал идею с промежуточным сервером.
Теперь нет версионной зависимости на уровне сопряжения программ и теоретически должно работать с любой версией OpenOffice / LibreOffice.

Текущая ревизия 4111.

Проверено и работает в Debian 6.0.7 (OpenOffice 3.2.1) и Windows 7 (проверены OpenOffice 3.1.1 и OpenOffice 3.4.1).

Под Windows теперь не требуется вообще устанавливать Python, поскольку задействован Python, идущий в поставке вместе с офисом.
OpenOffice / LibreOffice SDK соответственно тоже не нужен.
Нужно установить только сам офис (OpenOffice / LibreOffice).

Под Linux (по крайней мере Debian) как оказалось Python не идет в поставке с офисом. Разработчики дистрибутива это делают намеренно и используется системный Python. Системный Python, идущий в дистрибутиве Debian полностью совместим с uno библиотеками, идущими с офисом, который так же идет вместе с дистрибутивом Debian.

Сборку на ubuntu пока не проверял (сломалась виртуалка), но по идее действия должны быть следующие:


Пакет python-dev больше не требуется.
Опцию -DUSE_GOST_DOC_GEN=ON убрал, достаточно указывать только -DKICAD_GOST=ON.

Сборка под винду теперь выполняется точно так же как и раньше, просто включая опцию KICAD_GOST:
-DKICAD_TESTING_VERSION=ON -DKICAD_GOST=ON

bat файл больше тоже не требуется (реализован поиск офиса и его питона из KiCadа).

В ревизии 4112 добавил поддержку Python 3.
Теперь проверен и работает LibreOffice 4.0.2 под виндой (он поставляется с Python 3).

AVL, спасибо за проделанную работу!
Ubuntu 13.04 32bit ревизия 4111 собралась после небольших правок (см. diff.txt).
При попытке создать спецификацию последовательно появляются два сообщения: