[faa 4]

ЧЯДНТ?

собралось на ubuntu 12.04 х86_64.

добавил

sudo apt-get install swig python-dev

собирал скриптом:

#!/bin/bash
cd kicad
bzr pull
rm -rf build
mkdir build
cd build
cmake -DwxUSE_UNICODE=ON -DKICAD_GOST=ON -DKICAD_STABLE_VERSION=ON \
-DKICAD_SCRIPTING=ON -DKICAD_SCRIPTIG_MODULES=ON \
-DCMAKE_INSTALL_PREFIX=/usr ../
make -j 4
# sudo checkinstall --pkgname kicad --pkgversion 20130127-gost --nodoc
# sudo dpkg -i kicad_20130127-gost-1_i386.deb

Изменено 6 марта, 2013 пользователем faa

[faa 4]

faa, а может быть эту стаб. сборку сделать с последними патчами, если с ними теперь все в порядке?

Принимайте.

Можно тестировать стабильную версию с новым ГОСТ-патчем от К.Барановского ;)

 

[Aldan 0]

Принимайте. Можно тестировать стабильную версию с новым ГОСТ-патчем от К.Барановского ;)

faa, премного благодарен! :)

Сборка работает, патч тоже. Все пока симпатично. Только один маленький вопрос: Жан Пьер на мой взгляд еще не выкатил наипоследнейшую из наистабильнейших сборок этой недели а только сделал очередной фикс. Если мы заглянем в свойства нынешней сборки, то увидим, что у нее стоит "testing". Правильно ли я понимаю, что теперь, как в старые добрые времена, тестовая сборка с номером как у стабильной имеет одинаковый код байт в байт? Т.е. не стоит смущаться надписью "testing"?

Хотя, я почти уверен, что Жан Пьер в ближайшие дни еще выкатит самую наистабильную версию и тогда можно будет собрать непоколебимую сборку. :)

[faa 4]

Сборка работает, патч тоже. Все пока симпатично. Только один маленький вопрос: Жан Пьер на мой взгляд еще не выкатил наипоследнейшую из наистабильнейших сборок этой недели а только сделал очередной фикс. Если мы заглянем в свойства нынешней сборки, то увидим, что у нее стоит "testing". Правильно ли я понимаю, что теперь, как в старые добрые времена, тестовая сборка с номером как у стабильной имеет одинаковый код байт в байт? Т.е. не стоит смущаться надписью "testing"?

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

И основа - она та же, что и у стабильной. Если убрать указанный патч, то будет почти байт в байт

(добавлены/изменены "горячие" клавиши для ширины дорожки, исправлен вывод дуг на слое чертежа в DXF, исправлены 2 ошибки форматов сообщений).

 

[svvord 0]

Всем доброго времени суток =)

 

Решил сделать свежий порт KiCAD для FreeBSD, т.к. текущий имеет версию аж 2010-05-05-BZR2356. А я смотрю проект не стоит на месте и к нему присоеденились «наши» =) И даже свою сборку организовали, которой бы тоже порт не помешал...

 

Электронными поделками я занимаюсь весьма эпизодически. По этой причине эпизодически обращаюсь к CAD системам. До того как обратил внимание на KiCAD, я пользовался Eagle. И вот решил кое-что смастерить, глянул — Eagle из портов пропал =( Тут-то на KiCAD и наткнулся. В принципе для моей поделки достаточно и старой версии, но хочется помочь проекту.

 

На этом присказака заканчивается. Начинается сказка.

 

Сборка у меня обломалась с первого же .cpp файла:

 

[  0%] Building CXX object bitmaps_png/CMakeFiles/bitmaps.dir/cpp_16/pinorient_right.cpp.o
cd /usr/ports/cad/kicad/work/stable_2013-02-26_BZR3974/bitmaps_png && /usr/local/bin/g++46   -DKICAD_STABLE_VERSION -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -D-pthread -D_THREAD_SAFE -O2 -pipe -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -I/usr/ports/cad/kicad/work/stable_2013-02-26_BZR3974/include -I/usr/local/include -Wl,-rpath=/usr/local/lib/gcc46 -fPIC -I/usr/local/include/wx-2.8 -O2 -Wall -DNDEBUG -I/usr/ports/cad/kicad/work/stable_2013-02-26_BZR3974/include -I/usr/ports/cad/kicad/work/stable_2013-02-26_BZR3974/bitmaps_png/. -isystem /usr/local/lib/wx/include/gtk2-unicode-release-2.8 -isystem /usr/local/include/wx-2.8 -I/usr/ports/cad/kicad/work/stable_2013-02-26_BZR3974 -o CMakeFiles/bitmaps.dir/cpp_16/pinorient_right.cpp.o -c /usr/ports/cad/kicad/work/stable_2013-02-26_BZR3974/bitmaps_png/cpp_16/pinorient_right.cpp
<command-line>:0:1: error: macro names must be identifiers
*** [bitmaps_png/CMakeFiles/bitmaps.dir/cpp_16/pinorient_right.cpp.o] Error code 1

 

Нарвался на ошибку препроцессора. Вот только совсем не пойму откуда она такая вылезла. Тот же результат получается даже в случае полной замены содержимого файла pinorient_right.cpp на что-нибудь совершенно иное. Пробовал разные версии gcc — результат одинаков.

 

Собственно вопрос: не нарывался ли кто-нибудь на такое поведение при сборке? А если да, до как решалось?

 

Ну и в заключение хотелось бы сказать что GOST сборке не помешал бы собственный сайт. Чтобы сложить в одно место сборку, библиотеки, информацию для русских пользователей, а так же для разработчиков. Глядишь интерес к проекту повысится, а то непосвящённому сложно собирать крупицы информации с разных форумов. У меня имеется собственный сервер в датацентре Ростелекома, где я предоставляю услуги хостинга. Могу предоставить место для такого сайта бесплатно.

 

Захотелось мне пощупать скрипты на питоне. Собираю bzr3980 в Ubuntu 12.10 (32bit), останавливается на этапе "Linking CXX shared module _pcbnew.so". Полный лог прикрепил.

Параметры сборки: cmake -DwxUSE_UNICODE=ON -DKICAD_GOST=ON -DKICAD_TESTING_VERSION=ON -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DUSE_NEW_PCBNEW_LOAD=ON -DUSE_NEW_PCBNEW_SAVE=ON -DUSE_IMAGES_IN_MENUS=ON -DMAINTAIN_PNGS=ON -DCMAKE_INSTALL_PREFIX=/usr ../

Похоже не указана линковка библиотеки libpython.

Если не затруднит, покажите пожалуйста лог сборки с параметром cmake:

cmake -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON

 

Изменено 6 марта, 2013 пользователем svvord

[Сергей Борщ 121]

вылезла. Тот же результат получается даже в случае полной замены содержимого файла pinorient_right.cpp на что-нибудь совершенно иное. Пробовал разные версии gcc — результат одинаков.

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

 

 

А я подобрался вплотную к баге с загрузкой настроек, на которую жаловался еще летом. Как-то некогда было, пользовался старыми, до-нанометровскими сборками.

 

Проблема проявляется при вызове pcbnew <имя_файла.brd>, т.е. при вызове с загрузкой файла из текущей директории. В ReadProjectConfig() передается имя файла проекта <имя_файла.pro>, которое потом внутри ReCreatePrjConfig() передается конструктору wxFileConfig. Так вот согласно описанию, wxFileConfig при этом ищет файл ~/.имя_файла.pro и, естественно, не находит, после чего ReadProjectConfig() смело загружает kicad.pro из директории templates. Если при вызове pcbnew указать полный (абсолютный) путь к brd-файлу, то wxFileConfig использует этот абсолютный путь и файл находит. При этом eeschema при точно таком же вызове на пути к ReadProjectConfig() добавляет полный путь к имени файла проекта. Вот тебе и "повторное использование кода". Попробую сегодня найти то дивное место, где добавляется путь в eeshema и сделать патч с таким же действием для pcbnew. Или кто-то может это сделать быстрее?

[baranovskiykonstantin 0]

Спасибо всем за проявленный интерес к моей проблеме.

 

Похоже не указана линковка библиотеки libpython.

Если не затруднит, покажите пожалуйста лог сборки с параметром cmake:

cmake -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON

 

Вывод команд cmake и make в приложении.

 

cmake_make_logs.zip

[AHTOXA 15]

Принимайте.

 

В eeschema при вызове ERC каждый раз создаётся новое окошко. Наверное при наличии уже открытого окна ERC нужно активизировать его?

 

И попутно маленький вопрос: можно ли как-нибудь в схематике отключить отображение кружочка в месте соединения ножки компонента с проводником?

 

--------

Ещё вопросы по eeschema:

1. Почему у меня нет пунктов чертить в PS/SVG/DXF? (Есть только "Чертить" и "Чертить в буфер обмена".)

2. Зачем нужны пункты "Сохранить настройки"/"Загрузить настройки"? Вроде бы как и без них всё сохраняется/восстанавливается:)

 

[svvord 0]

Барановский Константин

В выводе cmake имеется странная строчка:

-- Found PythonLibs: /usr/lib/python3.2/config/libpython3.2.so (found version "2.7.3")

Нашёл он либу версии 3.2, а опредил её версию как 2.7.

В версии 2.7 необходимые функции имеются, я проверил у себя. А в версии 3.2 — отсутствуют. У меня 3.3 и я проверял на ней, но в пределах мажорной ветки существует бинарная совместимость, т.ч. в 3.2 они тоже отсутствуют.

 

Полагаю в системе имеется Python двух версий. 3.2 и 2.7. Но в cборочных скриптах не указана небходимая версия. Её надо просто указать.

 

Приложить патч не получилось, поэтому выкладываю его сюда...

--- CMakeLists.txt.orig 2013-03-07 19:55:39.000000000 +1100
+++ CMakeLists.txt  2013-03-07 19:56:42.000000000 +1100
@@ -298,7 +298,7 @@
# Find Python and other scripting resources
if(KICAD_SCRIPTING OR KICAD_SCRIPTING_MODULES)
     set(PythonInterp_FIND_VERSION)
-    find_package(PythonInterp)
+    find_package(PythonInterp 2.7 REQUIRED)
     check_find_package_result(PYTHONINTERP_FOUND "Python Interpreter")

     # Get the correct Python site package install path from the Python interpreter found by
@@ -317,7 +317,7 @@
     set(PYTHON_DEST "${PYTHON_SITE_PACKAGE_PATH}" CACHE PATH "Python module install path.")
     mark_as_advanced(PYTHON_DEST)
     message( STATUS "Python module install path: ${PYTHON_DEST}")
-    find_package(PythonLibs)
+    find_package(PythonLibs 2.7 REQUIRED)
     include_directories(${PYTHON_INCLUDE_PATH}
                         ./scripting)
endif(KICAD_SCRIPTING OR KICAD_SCRIPTING_MODULES)

 

Ругается он на какую-то из опций командной строки. Вероятно на одну из -D.

Точно. Сам не заметил что "-D-pthread" несколько выбивается из синтаксиса. Благодарю! =)

 

Изменено 7 марта, 2013 пользователем svvord

[baranovskiykonstantin 0]

Полагаю в системе имеется Python двух версий. 3.2 и 2.7. Но в cборочных скриптах не указана небходимая версия.

Так и есть.

 

Приложить патч не получилось, поэтому выкладываю его сюда...

С патчем все собралось без ошибок.

Спасибо! Большое при большое))

 

 

Нашел две ошибки касающиеся недавно добавленной тильды:

1) при вводе нескольких подряд символов '~' неверно определялась длинна текста;

2) при экспорте в DXF не верно отображалась та самая тильда.

 

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

tilde_size.patch.zip

gost_07032013.patch.zip

[Aldan 0]

основа - она та же, что и у стабильной. Если убрать указанный патч, то будет почти байт в байт

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

Я спрашивал об этом по той причине, что после перехода на bzr некоторое время номера тестовых сборок сильно отличались от номеров стабильных, а теперь вроде бы все вернулось к номерному единству.

Единственное отличие пока состоит в том, что раньше Жан Пьер несколько раз объявлял релиз-кандидат и все спешили подчистить свои косяки до выхода финальной версии. А сейчас, никаких «кандидатов», а просто несколько раз за короткое время выкладывается «стабильная версия», которая после нескольких итераций переходит в действительно стабильную.

Но это все так просто, заметки на полях...

 

А теперь небольшие наблюдения за поведением форматок в данной сборке - bzr3985-win32 newgost. Помнится, обычно вопросы возникали с форматкой А4. Для тестирования я создал новый проект из пары компонентов и нескольких проводников, чтобы можно было пробежаться по основной технологической цепочке. И вот какие наблюдения.

Изначально при создании проекта форматка А4 стоит вертикально, как и положено. Более того, при печати теперь не приходится все время переводить в книжную ориентацию, т. к. это наконец-то делается автоматически (когда это исправилось не знаю, т. к. долго работал на прежней стабильной сборке и в тестовые не лез).

При новом открытии схемы после ее сохранения ориентация форматки в норме, а вот эти же действия при сохранении топологии и повторном открытии в pcbnew имеют несколько различные последствия.

Если разводку платы сохранить в brd и потом вновь открыть, то форматка откроется так, как надо, а вот если сохранять разводку в kicad_pcb, то при повторном открытии вертикальная форматка А4 развалится на части: большая часть примет расположение горизонтальной форматки, а левая сторона вместе с полями останется стоять вертикально. Таким образом, при сохранении разводки в kicad_pcb форматка А4 искажается: левая сторона с полями остается неизменной, правая сокращается по высоте, а верхяя и нихняя сторона форматки напротив удлиняются, что и создает эффект «развалившейся форматки упавшей на бок».

 

Теперь несколько мыслей вслух.

1. Почему бы в pcbnew > Настройка правил > Общие правила проектирования не заполнить по умолчанию все 12 значений «особые переходные отверстия» и «особые дорожки»? Например, дорожки — 8, 10, 12, 16, 24, 36, 48, 60.., мил и соответствующие им переходные отверстия? Кому от этого будет плохо? Ведь эти размеры должны соответствовать определенным требованиям, да и набивать эти цифры гораздо дольше, чем удалить при надобности. Особенно это будет ценно для новичков, осваивающих не только сам кикад, но и сами навыки разводки. На мой взгляд это сделать не сложно, а польза большая.

 

2. Если пользователь pcbnew захочет распечатать избранные слои топологии и выберет опцию «по странице на слой», то получит несколько безымянных листов, если была выбрана печать без рамки, или столько же листов с поименованных за счет штампа в рамке, но каждый из листов будет иметь большой штамп первого листа. Так вот, на мой взгляд, не лучше ли будет сделать как в схематике: первый лист с большим штампом, а последующие с малым? Если это покажется спорным, можно будет сделать чекбокс для выбора старого варианта.

 

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

 

 

[baranovskiykonstantin 0]

А теперь небольшие наблюдения за поведением форматок в данной сборке - bzr3985-win32 newgost. Помнится, обычно вопросы возникали с форматкой А4. Для тестирования я создал новый проект из пары компонентов и нескольких проводников, чтобы можно было пробежаться по основной технологической цепочке. И вот какие наблюдения.

Изначально при создании проекта форматка А4 стоит вертикально, как и положено. Более того, при печати теперь не приходится все время переводить в книжную ориентацию, т. к. это наконец-то делается автоматически (когда это исправилось не знаю, т. к. долго работал на прежней стабильной сборке и в тестовые не лез).

При новом открытии схемы после ее сохранения ориентация форматки в норме, а вот эти же действия при сохранении топологии и повторном открытии в pcbnew имеют несколько различные последствия.

Если разводку платы сохранить в brd и потом вновь открыть, то форматка откроется так, как надо, а вот если сохранять разводку в kicad_pcb, то при повторном открытии вертикальная форматка А4 развалится на части: большая часть примет расположение горизонтальной форматки, а левая сторона вместе с полями останется стоять вертикально. Таким образом, при сохранении разводки в kicad_pcb форматка А4 искажается: левая сторона с полями остается неизменной, правая сокращается по высоте, а верхяя и нихняя сторона форматки напротив удлиняются, что и создает эффект «развалившейся форматки упавшей на бок».

если заглянуть во внутрь нового формата (kicad_pcb), то можно увидеть, что сохраняется только формат листа, а его ориентация нет. Похоже, недоработка...

 

2. Если пользователь pcbnew захочет распечатать избранные слои топологии и выберет опцию «по странице на слой», то получит несколько безымянных листов, если была выбрана печать без рамки, или столько же листов с поименованных за счет штампа в рамке, но каждый из листов будет иметь большой штамп первого листа. Так вот, на мой взгляд, не лучше ли будет сделать как в схематике: первый лист с большим штампом, а последующие с малым? Если это покажется спорным, можно будет сделать чекбокс для выбора старого варианта.

Тоже задумывался об этом. По свободе займусь.

 

[Aldan 0]

если заглянуть во внутрь нового формата (kicad_pcb), то можно увидеть, что сохраняется только формат листа, а его ориентация нет. Похоже, недоработка...

Так выходит, что и другие форматки при сохранении в kicad_pcb могут развалиться? Действительно, недоработка...

Тоже задумывался об этом. По свободе займусь.

Как сугубый пользователь могу только пожелать удачи: Удачи! :)

[Сергей Борщ 121]

Так вот, на мой взгляд, не лучше ли будет сделать как в схематике: первый лист с большим штампом, а последующие с малым?

А кто будет решать, какой из слоев будет на первом листе?

 

[baranovskiykonstantin 0]

А кто будет решать, какой из слоев будет на первом листе?

Предлагаю такой выход. Сейчас в PCBnew есть два варианта печати:

1. "По странице на слой" - указанные слои печатаются на отдельных листах с большим штампом.

2. "Одна страница" - указанные слои сводятся и печатаются на одном листе с большим штампом.

Добавляем еще один вариант:

3. "Комбинированный" (над названием нужно поработать:) ) - на первом листе с большим штампом печатаются все указанные слои сведенные вместе (общий вид), а на последующих, с малым штампом, каждый слой в отдельности.