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

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

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

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

В своем сообщении о скрипте я писал:

после чего было получено только одно замечание от faa и далее тишина. Раз никто не жалуется и ничего не предлагает, то возможны два варианта:
1) все пользуются и все довольны;
2) никто не пользуется, никому не нужно.
Я думаю что в данном случае имеет место второй вариант и раз так, можно не спешить с нововведениями и улучшениями, так как не для кого стараться, а для меня хватает и реализованной функциональности.

Если кому интересно, то в ближайшее время хочу переписать скрипт добавив графический интерфейс (т.к. не все дружат с командной строкой), оставив возможность работы через консоль.

На опросник похоже. Так почему бы его не создать?
Я бы проголосовал "за".

Скрипт скачал, но еще не прикрутил. Поэтому замечаний нет Штука-то полезная.

Константин, для того, чтобы можно было высказать свое мнение о работе Вашего скрипта, нужно попрактиковаться в выводе документации при помощи него, ведь так? А теперь посмотрим в на эту ситуацию глазами обычного пользователя Кикада, не программиста, каким являюсь я. Такой пользователь резонно ожидает такой готовности предлагаемого программного продукта, когда он будет органично интегрирован в Кикад, как все его составляющие. Например, при выводе перечня элементов будет достаточно поставить галочку в чекбоксе «выводить перечень в ГОСТ» и на выходе мы получим вместо абстрактной таблицы в Екселе именно то, что нам надо. Или, например, в менеджере Кикада к шести уже имеющимся кнопкам запуска приложений добавится седьмая - «текстовая документация». В любом случае речь идет о законченном приложении, интегрированном в существующий графический интерфейс и все это устанавливается без бубна совместно с установкой самого Кикада.
Ваше сообщение с анонсом своего скрипта я воспринял как обращение к программистам, могущим и «прикрутить» и в консоли поработать. Я же командной строкой пользовался за всю свою жизнь раз десять, да и скриптами с «костыликами» никогда не игрался. Таких как я, увы, много, возможно — большинство. Вот и молчит это большинство, т. к. еще не получило в свои руки сей важный инструмент, чтобы можно было его потестировать.
Тут уж Вам нужно определиться: либо вы делаете свой продукт только для «продвинутых» и тогда то, что уже реализовано можно считать достаточным, либо Вы делаете законченный продукт интегрированный в Кикад и тогда это будет «для всех». Хочется верить, что Вы настроены на доведение своей разработки до полной завершенности
В данный же момент мне даже не понятно поддерживает ли нынешняя версия Кикада python или нет. Ведь об этой поддержке уже многое писали, однако писали и о том, что вроде бы сейчас это отключено (я пишу о стаб. сборке 4009). Если поддерживает, то зачем Вы в своем readme требуете его установку, а также установку odfpy? Если пока не поддерживает, но может, так не лучше ли в ГОСТ версии таки реализовать эту поддержку, чтобы в довесок в Кикаду не устанавливать целый перечень доп. программ и потом разбираться в их взаимодействии вместо работы в САПРе? Почему нельзя сразу в общем пакете установить opengostfont, а нужно опять прыгать с бубном и как Вы пишете «может придется подобрать шрифт, желательно моноширинный»? А требуемая настройка шести пользовательских полей разве не может быть один раз на всю жизнь сделана при сборке Кикада? Ведь если кому-то не понравится, то он поля легко исправит?
Словом, я за то, чтобы все новые приложения по уровню безгеморройности и завершенности соответствовали самому Кикаду и вызывали радость, а не головную боль.
Но не зря существует поговорка: «сытый голодного не поймет». «Сытый» - продвинутый, самодостаточный, могущий «прикрутить», а «голодный» — тот, кто ожидает понимания и снисхождения, т. к. по сложившейся ситуации не владеет тем, чем владеет «сытый». Вот и проходят мимо «голодных» скрипты и «костылики на перловке», а могли бы украсить Кикад на радость всем, а не только продвинутым.
Чтобы не возникло вопросов типа, а сам-то чего не станешь «продвинутым», отвечаю. В этом году мен 59, а лет 6 — 7 назад я еще не умел самостоятельно устанавливать приложения и только-только сел за компьютер. Так уж сложилась жизнь, она у всех разная...
Простите за пространные речи, просто хочется, чтобы Вы могли понять реальное положение вещей, тогда будете несколько иначе мыслить. И не ждите шквала отзывов, а работайте на будущего пользователя, который обязательно появится, если Кикад станет дружественным и функциональным. Кстати, если замечали, все предлагаемые материалы обычно скачивают не более, чем полтора-два десятка человек, что говорит о том, что на форуме не так много «нашего брата».
И еще, пожелание: подумайте, может быть реализовать не только вывод перечня, но и ведомость покупных раз уж есть ВОМ, ведь тоже гостовский текстовый документ, причем гораздо более простой по организации.

Всем привет.

Как раз и разрабатываю интегрированный модуль для формирования документации по ГОСТ.
Скоро выложу ветку на launchpad.

AVL, немного поясню то, что я написал об интегрированности в Кикад.
Конечно же высший пилотаж это иметь в Кикаде вывод текстовой документации в ГОСТ без привлечения каких-то дополнительных программ. Но, если, например, в процессе вывода будет запускаться имеющийся на компе пакет Либре Офиса, то это никак не уменьшит доступность и удобство для пользователя. Такое решение все равно будет считаться полностью интегрированным, т. к. не требует от пользователя хитрых танцев с бубном, а сам Офис практически у всех и так имеется.

Желаю успеха! Надеюсь, что финальный релиз Кикада в обозримом будущем будет пересобран для интеграции в него вывода текстовой документации по ГОСТ требованиям.

Вариант шаблона спецификации для LibreOffice (с боковым и нижним штампами)

Переписал свой скрипт, теперь он имеет графический пользовательский интерфейс и с ним можно работать как с обычной программой.


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

Архив с программой и руководством можно загрузить отсюда: https://launchpad.net/kicadbom2spec

P.S.

Надеюсь в таком виде программа будет приемлема для использования обычными пользователями.


К сожалению, на создание генератора спецификации интегрированного в KiCAD сейчас банально нет времени.

Прошел по маршруту kicadbom2spec в Windows XP, руководство подробное (спасибо Косте).
Вместо рабочего стола для установки odfpy использовал строку Total Commander - получилось.
Пожелание: включить в дистрибутив простой набор файлов sample.* для примера и демонстрации результата.
Можно будет попробовать сделать автоустановку всего через NSIS.

Всем привет.

Хотел узнать, есть ли где-либо (в bzr репозиториях, на ftp и т.д.) свободно распространяемый пример электрической принципиальной схемы (включая библиотеки) оформленной по ГОСТ для KiCad?

Хочу добавить такой пример в директорию demos дерева проекта KiCad по аналогии примерам не ГОСТ исполнения, которые находятся в директории demos. (Пока планирую вручную добавить нужные аттрибуты для компонентов такой схемы-примера).

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

В дальнейшем планирую добавить некий GUI-менеджер, позволяющий удобно назначать аттрибуты компонентам, а также указывать каким исполнениям пренадлежит каждый из компонентов.

Исходники выложил в ветке https://code.launchpad.net/~al-lunev/kicad/GOST-doc-gen
Однако пока отлаживал под Linux Debian Squeeze (под Windows скорее всего пока не соберется).

Предварительно сделал генерацию документов через нажатие Eeschema->Tools->GOST Tools.

После сборки из исходников, генерируется файл env.sh в директории eeschema
Данный файл пока приходится запускать перед запуском eeschema следующим образом:
. ./env.sh
иначе eeschema не увидит библиотеки программы Open Office.

Буду еще думать как убрать этот костыль.

Для возможности сборки проекта из исходников, понадобится установить Open Office SDK.
Я пока работаю на версии 3.2, другие версии еще не тестировал.

Нарисовал пока свой пример схемы https://code.launchpad.net/~al-lunev/kicad/GOST-doc-gen:
demos/GOST/multivibrator.sch (путь в дереве кикада)

Компонентам назначены аттрибуты так, чтобы продемонстрировать формирование документов для схем с исполнениями.

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

AVL, хочу и Вам пожелать удачи! Может быть к тому моменту, когда я закруглюсь с ремонтом и Ваш вариант вывода документации под Виндами будет готов. Вот ведь, еще недавно не было ничего на этом поприще, а теперь намечается изобилие
--------------------------
Еще раз прошу прощения за свою временную пассивность на форуме по причине своего жилищного форсмажора.

Действительно, жаль. Был бы хоть какой-нибудь "лайк", я бы поставил.
На одной консультируемой мною фирме последней каплей среди аргументов перехода на KiCAD послужило наличие вывода гостовской документации.

Хотел попробовать, но в Ubuntu OpenOffice SDK просто так не установишь, а LibreOffice SDK не подходит. Если есть возможность, выложите собранные бинарники KiCAD, уж очень интересно что да как.

Константин, а у Вас какая версия Ubuntu (включая архитектуру)?

AVL, Ubuntu 13.04 32 bit.

P.S. лучше на "ты"

Официальный релиз Ubuntu 13.04 вроде бы завтра выходит. По крайней мере сейчас я не нашел где официально можно скачать Ubuntu 13.04.
Константин, у тебя есть ссылка, где можно скачать Ubuntu 13.04?

Да, официальный релиз должен появиться завтра, но я не смог удержаться и еще месяц назад перешел на тестовую версию, т.к. все говорили о высокой стабильности. Ежедневные сборки доступны здесь: http://cdimage.ubuntu.com/daily-live/current/.

Приведу два ГОСТа на текстовые КД:
ГОСТ 2.701-2008 - ЕСКД. Схемы. Виды и типы. Общие требования к выполнению. Здесь раздел 5.7 посвящен
перечню элементов (ПЭ), который "помещают на первом листе схемы или выполняют в виде самостоятельного документа".
ПЭ выполняют в виде таблицы заданной формы. Даны правила заполнения.

ГОСТ 2.106-96 (переиздание 2007 года) - ЕСКД. Текстовые документы (в том числе спецификация, СП).
В СП восемь разделов. В пункте 3.7 описывается заполнение самого трудоемкого раздела "Прочие изделия",
куда и заносятся компоненты ЭРИ для печатных плат. Приведены формы документов.

Добавил поддержку LibreOffice, а также новых версий OpenOffice/LibreOffice (начиная с версии 3.4 разработчики OpenOffice/LibreOffice изменили способ соединения с офисом).

Отлаживал под Ubuntu 13.04 32-bit (официальный релиз), установленной под VirtualBox.



Сейчас есть две проблемы:
1) приходится до команды make запускать ". eeschema/env.sh", чтобы в переменную окружения LD_LIBRARY_PATH прописался путь к библиотекам URE
2) приходится до запуска eeschema также запускать ". eeschema/env.sh" по тем же причинам (в текущей сессии достаточно запустить только один раз)

Константин, есть какие-нибудь идеи как решить пункт 1, чтобы не приходилось руками выполнять эту команду? Вчера для этого экспериментировал с cmake, пока не удалось победить.

Насчет пункта 2 у меня пока только идея - это добавить возможность в каком-нибудь окошке в кикаде конфигурировать путь к OpenOffice / LibreOffice.

Решил попробовать данный скрипт. Установил odfpy 0.9.6.
При запуске скрипта потребовало пакеты (у меня Linux Debian 6.0.7) - установил:
sudo apt-get install python-argparse
sudo apt-get install python-tk

Далее при запуске скрипта вываливается ошибка:


Заархивированный тестовый файл прикрепил.

Спасибо большое за описание ошибки! Приложил исправленный скрипт.

Прости, но последнее время был очень занят и не мог заняться решением проблем gost_doc_gen. Обязательно что-нибудь придумаем

P.S.
В BOM файле, в поле Field 5 должна указываться точность, а примечание в поле Field 6.

Спасибо. Теперь заработало.

Впечатление положительное, что нет проблем с всякими коннектами / путями к OpenOffice/LibreOffice.
Я уже стал задумываться, может как-то odfpy прикрутить к GOST-doc-gen, либо может есть c++ odfpy-альтернатива.

AVL, GOST_doc_gen не хочет собираться:



Вроде бы библиотеки на месте, но никак...

Получается, что если в C++/Qt-библиотеке (> 4.5) есть простые средства формирования ODF-файлов, то в C++/Wx их нет...

здесь кросс-платформенная свободная Qt-утилита kicad_service, © 2010, Павлюков.
написана для просмотра схем kicad (PDF формат kicad еще не поддерживал)
можно подключать ttf-шрифты типа opengostfont
попытка формировать BOM и перечень элементов (формат PS)

Линкер не видит файлы so.3. Ему нужны файлы so.
На этапе линковки линкеру передается путь ${OOO_SDK_DIR}/lib (для ubuntu 13.04 32-bit этот путь = /usr/lib/libreoffice/sdk/lib). Там и лежат файлы so (симлинки на so.3, которые, в свою очередь, лежат в /usr/lib/libreoffice/ure-link/lib)

Раз линкер не может найти указанные библиотеки, значит по какой-то причине cmake не смог вычислить корректно значение переменной OOO_SDK_DIR (это вычисление выполняет модуль GOST-doc-gen/CMakeModules/FindOpenOffice.cmake, то есть на него возлагаются надежды, что он на произвольной машине найдет корректно расположение офиса и его SDK).

Поэтому нужны логи выполнения команды cmake ../. -DKICAD_STABLE_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON | tail -n15
И логи команды ls -la /usr/lib/libreoffice/sdk/lib

P.S.
LD_LIBRARY_PATH тоже должен быть проинициализирован (в данном случае = /usr/lib/libreoffice/ure-link/lib, судя по приложенным логам, проинициализирован верно), иначе не будут найдены зависимости, необходимые библиотекам uno_cppuhelpergcc3, uno_cppu, uno_salhelpergcc3, uno_sal.



Жаль, что KiCad не на базе Qt

Прикручивать Qt только, чтобы формировать odf - избыточно, хотя тоже вариант.

Значит имеем 3 варианта:
1) оставить все как есть (OO SDK). В случае с Windows пытаюсь добиться компиляции KiCad с помощью VC Express 2010 (с помощью VC Toolkit 2003 уже не получается собрать wxWidgets, поскольку в составе VC Toolkit 2003 нет nmake.exe). Если удастся собрать сам KiCad, то появляется возможность слинковать OO SDK. Жаль, что библиотеки OO SDK не собирают для mingw, и очень странно, что они есть только для VC.
2) прикручивать odfpy
3) прикручивать qt

Константин, проверь, пожалуйста, новый коммит (4098) с исправлением. По идее должно заработать.

AVL, спасибо большое! Все собралось и заработало. Выглядит очень мощно, сейчас свободного времени немного, нет возможности оценить все особенности данного инструмента.
Вызывает сомнения расположение дополнительных полей, может я что-то упустил. Но это мелочи, а вот с решить проблему с библиотеками ОО sdk пока не знаю как, кроме запуска с помощью скрипта.

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

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

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

Ну собственно и все. Скачать обновленный релиз можно отсюда 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).
При попытке создать спецификацию последовательно появляются два сообщения:
Нажмите для просмотра прикрепленного файла

Константин, спасибо за помощь.

Установил новую виртуалку с ubuntu 13.04 32bit.

Проверил, mb_str тоже не работает (как раз из-за него вываливается ошибка).

Сейчас в результате вернул использование TO_UTF8() как было в предыдущих коммитах.
Но когда был применен TO_UTF8() в винде кодировка не правильно отображалась.
Сейчас добавил принудительное декодирование в UTF8 в uno_iface.py, и это помогло.

Перепроверил в debian, ubuntu, Windows 7 (OpenOffice 3.1.1, OpenOffice 3.4.1 и LibreOffice 4.0.2). Сейчас везде работает.

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

4113 - собралась и работает.

Всем привет.
В пятницу (10 мая) сделал запрос на слияние ветки lp:~al-lunev/kicad/GOST-doc-gen с lp:kicad.
Как и ожидалось, опять админы, пока в данном случае Жан-Пьер, противится.
Если кому интересно, читайте и участвуйте в этой "дискуссии": https://code.launchpad.net/~al-lunev/kicad/...n/+merge/163239

Основные камни преткновения:
1) Жан-Пьер считает, что встраивать данный инструмент в сам KiCad - это не правильно.
2) Жан-Пьер требует, чтобы исходники содержали литералы только на английском, а русский перевод делать через интернационализацию.

По 1-му пункту я ему объясняю, что иметь отдельное ПО - это не правильно и не удобно. И в данном случае технически не реально использовать промежуточный файл как он предлагает. Вдобавок я делаю менеджер компонентов, который постоянно читает/пишет атрибуты eeschemы. (Самое интересное, что в случае с pcad2kicad (изначально я его сделал отдельным исполняемым файлом, но в составе дерева исходников Кикада), они тогда уперлись и потребовали его переписать в виде плагина Pcbnew, то есть встроить в сам KiCad).

По 2-му пункту я ему объясняю, что GOST-doc-gen расчитан только на русскоязычных пользователей и сам ГОСТ на русском. Никак не предполагается, что генерируемые формы будут использоваться не русскоязычными пользователями. И зачем в таком случае усложнять жизнь мне и человеку, который это будет собирать?

Подробности и остальные аргументы читайте на https://code.launchpad.net/~al-lunev/kicad/...n/+merge/163239
Если требуется перевод на русский, пожалуйста, дайте знать.

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

Борьба с этими админами у меня уже продолжается с июня 2012, то есть уже год почти.
Уже все какие возможно капризы их выполнены, а к примеру pcad2kicadsch (lp:~pcad2kicad-committers/kicad/pcad2kicad) до сих пор существует в виде отдельного проекта и живет своей жизнью. Они до сих пор его не добавили в основную ветку! А pcad2kicadpcb добавили только в декабре 2012!

Я уже не говорю про попытки других разработчиков присылать им патчи и реакцию этих админов.

Мой план такой. Я сейчас еще понаблюдаю, что они решат по GOST-doc-gen. Если безрезультатно, то придется создать ветку lp:~GOST-committers/kicad/kicad или что-то вроде этого. Коммититься в нее. Синхронизироваться периодически с lp:kicad.
Условная компиляция KICAD_GOST - это и так по факту отдельный проект, собирается он только участниками этого форума для русскоязычных пользователей.
Исходный код части KICAD_GOST сопровождается тоже только разработчиками с этого форума. Так и так приходится самим синхронизироваться с изменениями, которые вне KICAD_GOST секции.

Значит тому и быть.

Юрий, спасибо за сборку.

Как и обещал, добавил GUI менеджер компонентов (ревизия 4115).
Поскольку данный менеджер (я не говорю про сам генератор GOST-doc-gen) по идее может применяться любыми пользователями Кикада (не только ГОСТ пользователи), исходники его полностью на английском с расчетом на использование интернационализации. Потребуется руссификация.

Возможности менеджера компонентов:
1) список всех компонентов схемы с отображением полной строки в примерном виде в каком это попадет в КД
2) добавление новых исполнений
3) возможность просмотра и работы со списком компонентов в разных плоскостях (полный список, постоянная часть, переменная часть для выбранного исполнения)
4) указание компоненту в каких исполнениях он присутствует
5) возможность задать значение "Не устанавливается". В результате будет сделана отметка в ПЭ3, и данный компонент не попадет в спецификацию.
6) редактирование атрибутов компонента
7) если есть поз.обозначения вида A1C1, то такие компоненты образуются в комплекты и в соответствующем виде отображаются в КД
8) возможность группового редактирования компонентов
9) все изменения сделанные в менеджере компонентов автоматически, не видимо для пользователя, отражаются в eeschema и наоборот, все изменения сделанные в eeschema появляются в менеджере компонентов
10) запуск генератора перечня элементов (ПЭ3) и спецификации из менеджера компонентов (должен быть установлен OpenOffice или LibreOffice)
Идея реализации данного менеджера компонентов похожа на проприетарный генератор перечней Брагина.
------------------------------

У меня вопрос к Юрию Викулову и Андрею Федорушкову по руссификации:
На сколько я понимаю придется создавать ветку документации (bzr branch lp:~kicad-developers/kicad/doc)? Раз пока GOST-doc-gen не находится в lp:kicad и не известно будет он ли вообще там.
То есть я вижу сейчас следующую проблему. Если добавлю перевод в lp:~kicad-developers/kicad/doc, то скорее всего мой перевод будет затерт следующим коммитом, который будет сделан на базе lp:kicad, так как в lp:kicad отсутствуют фразы, которые есть в lp:~al-lunev/kicad/GOST-doc-gen.
Я сегодня пробовал запустить poedit, и он если видит, что в новых коммитах какие-то фразы уже отсутствуют, то выкидывает их, и результат сохраняется без старых фраз.
Поэтому я вижу выход из ситуации - создать ветку документации, которая будет в паре с lp:~al-lunev/kicad/GOST-doc-gen.

Если все так, то, Юрий и Андрей, вам бы это не помешало делать сборку, если документация будет в другой ветке отличной от lp:~kicad-developers/kicad/doc?
Либо может есть другой вариант как поступить с документацией?

Думаю, что это не помешает взять ru-перевод из отдельной ветки для GOST-doc-gen, поместить его в GOST-сборку.
Надо подумать о методе пост-копирования ru-перевода новых сообщений из новых версий развития основной ветки kicad.
Может часть сообщений, нужных только ru-сообществу, делать изначально ru.