[baranovskiykonstantin 0]

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

 

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

Пожелание: включить в дистрибутив простой набор файлов sample.* для примера и демонстрации результата.

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

Решил попробовать данный скрипт. Установил odfpy 0.9.6.

...

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

...

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

[AVL 0]

Текущее состояние по 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) предпочтительнее.

[baranovskiykonstantin 0]

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

build_log.txt

[viknn 0]

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

 

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

[AVL 0]

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

 

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

 

Ubuntu 13.04 32-bit:

sudo apt-get install bzr cmake g++ freeglut3-dev libwxgtk2.8-dev python-dev python-uno
bzr branch lp:~al-lunev/kicad/GOST-doc-gen
cd GOST-doc-gen
mkdir Release
cd Release
cmake ../. -DKICAD_TESTING_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON
make
sudo make install

 

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

 

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

 

Юрий, данную проблему исправил в ревизии 4105.

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

[viknn 0]

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

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.

[AVL 0]

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. Тоже пытаюсь понять, что сделать.

[baranovskiykonstantin 0]

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

-- Configuring done
CMake Error at eeschema/GOST-doc-gen/CMakeLists.txt:92 (add_library):
  Cannot find source file:

    ../template_fieldnames_keywords.cpp

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx

[AVL 0]

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

-- Configuring done
CMake Error at eeschema/GOST-doc-gen/CMakeLists.txt:92 (add_library):
  Cannot find source file:

    ../template_fieldnames_keywords.cpp

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx

 

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

[AVL 0]

Наконец-то заработало под винду. Единственное пока пришлось написать 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 соединение.

 

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

KiCad_GOST_doc_gen.zip

[baranovskiykonstantin 0]

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

[viknn 0]

Прошел по маршруту kicadbom2spec в Windows XP, руководство подробное (спасибо Косте).

Можно будет попробовать сделать автоустановку всего через NSIS.

На ftp://ftp.kicad.ru/pub/kicad/kicad_eskd_d...ky_kicadbom2sp/

положил py-срипт К.Барановского для производства спецификации kicad на шаблоне LibreOffice.

Дополнительно сделан NSIS-скрипт для упрощения установки программы под Windows (пуск kicadbom2spec.exe).

[AVL 0]

Реализовал идею с промежуточным сервером.

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

sudo apt-get install bzr cmake g++ freeglut3-dev libwxgtk2.8-dev python-uno
bzr branch lp:~al-lunev/kicad/GOST-doc-gen
cd GOST-doc-gen
mkdir Release
cd Release
cmake ../. -DKICAD_TESTING_VERSION=ON -DKICAD_GOST=ON
make
sudo make install

 

Пакет python-dev больше не требуется.

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

 

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

-DKICAD_TESTING_VERSION=ON -DKICAD_GOST=ON

 

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

[AVL 0]

В ревизии 4112 добавил поддержку Python 3.

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

[baranovskiykonstantin 0]

AVL, спасибо за проделанную работу!

Ubuntu 13.04 32bit ревизия 4111 собралась после небольших правок (см. diff.txt).

При попытке создать спецификацию последовательно появляются два сообщения:

diff.txt