[viknn 0]

Получается сейчас на сборочном компе должен быть Интернет обязательно, чтобы cmake

подгрузил boost-библиотеку с sf. Для меня это не всегда удобно.

[AVL 0]

Получается сейчас на сборочном компе должен быть Интернет обязательно, чтобы cmake

подгрузил boost-библиотеку с sf. Для меня это не всегда удобно.

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

Дальше Инет потребуется как обычно, если нужно выполнить bzr pull.

Повторная закачка boost по идее может инициироваться только на очередном bzr pull, cmake / make и то только в случае, если разработчики решили перейти на следующую версию boost.

[tema-electric 0]

А он ее разве не один раз грузит?

[baranovskiykonstantin 0]

Хочу собрать последний KiCAD из gost ветки, получаю ошибку:

[  0%] Performing patch step for 'boost'
bzr: ERROR: неизвестная команда «patch»
make[2]: *** [../.downloads-by-cmake/boost_1_53_0/src/boost-stamp/boost-patch] Ошибка 3
make[1]: *** [CMakeFiles/boost.dir/all] Ошибка 2
make: *** [all] Ошибка 2

 

Если исправить в CMakeModules/download_boost.cmake строку 51 с

    PATCH_COMMAND   bzr patch -p0 ${PROJECT_SOURCE_DIR}/patches/boost.patch

на

    PATCH_COMMAND   patch -p0 ${PROJECT_SOURCE_DIR}/patches/boost.patch

 

то получаю зависание на этапе

[  0%] Performing patch step for 'boost'

после которого ранее появлялась ошибка.

 

Установлен cmake 2.8.11, как описал AVL на предыдущей странице.

Может кто сталкивался?

 

cmake version 2.8.11

Bazaar (bzr) 2.6.0dev3

Platform: Linux-3.8.0-19-generic-i686-with-Ubuntu-13.04-raring

 

UPD:

не хватало bzrtools. После установки собралось.

Изменено 6 июня, 2013 пользователем Барановский Константин

[mobidev 0]

А он ее разве не один раз грузит?

 

Всё зависит от реализации, если реализация правильная, то она один раз загрузит архив, а в следующие разы будет просто проверять наличие и использовать существующий архив и/или разархивированный каталог, если же не повезёт с реализацией, то будет грузить каждый раз.

[zöner 0]

возможно, есть смысл сделать редактор атрибутов элементов схемы в виде таблицы.

что-то типа CvPcb, но для всех свойств, чтобы быстро заполнять/менять.

Изменено 9 июня, 2013 пользователем zöner

[AVL 0]

возможно, есть смысл сделать редактор атрибутов элементов схемы в виде таблицы.

что-то типа CvPcb, но для всех свойств, чтобы быстро заполнять/менять.

Ну так это уже можно делать в GOST менеджере компонентов.

[zöner 0]

где ? не могу найти

[AVL 0]

где ? не могу найти

Либо собрать из исходников: lp:~kicad-gost-committers/kicad/kicad

либо установить бинарники:

Для винды: ftp://ftp.kicad.ru/pub/kicad/install/win32/gost_commit

для ubuntu: http://electronix.ru/forum/index.php?act=a...st&id=77467

для Mac OS: http://www.mobile-systems.info/kicad/kicad...27_20130524.dmg

Ссылки разбросаны где попало, поэтому предложил организовать структуру директорий для веток на ftp.

 

Запуск в eeschema->Tools->GOST Tools

[zöner 0]

у меня свежесобранный BZR-4182-GOST, под линухом.

пункта Tools->GOST Tools не наблюдаю.

[AVL 0]

у меня свежесобранный BZR-4182-GOST, под линухом.

пункта Tools->GOST Tools не наблюдаю.

В данном случае BZR-4182-GOST - это из ветки lp:kicad.

А нужна ветка lp:~kicad-gost-committers/kicad/kicad

В ветке lp:~kicad-gost-committers/kicad/kicad сейчас актуальная ревизия 4142, и она как ни странно новее и функциональнее ревизии 4182 из ветки lp:kicad ;)

 

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

 

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

[Aldan 0]

у меня свежесобранный BZR-4182-GOST, под линухом. пункта Tools->GOST Tools не наблюдаю.

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

В настоящее время мы имеем дело с шестью видами сборок:

- «интернациональные» тестовые и стабильные, т. е. исходные сборки,

- ГОСТ-сборки тестовые и стабильные,

- ГОСТ-сборки с генератором перечня тестовые и (обещаны) стабильные.

Первая пара сборок нас не интересует, а вот со второй и третей парой сборок надо бы разобраться.

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

В свое время faa взял на себя труд русифицировать Кикад и породил, таким образом, ГОСТ-сборки. С этого момента все «наши особенности» сборок всегда были в ее ГОСТ-части. Например, недавний патч Константина Барановского органически вписался в ГОСТ-сборку ибо он за бугром никому не нужен, а нужен только нам.

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

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

Так что я за то, чтобы прекратить не нужное дробление на дополнительные ветки и вернуться к обычному понятию «ГОСТ-сборка». Сила в простоте...

[AVL 0]

В настоящее время мы имеем дело с шестью видами сборок:

- «интернациональные» тестовые и стабильные, т. е. исходные сборки, (1)

- ГОСТ-сборки тестовые и стабильные, (2)

- ГОСТ-сборки с генератором перечня тестовые и (обещаны) стабильные. (3)

Первая пара сборок нас не интересует, а вот со второй и третей парой сборок надо бы разобраться.

Даже если не отказываться от исходных 2-х пар сборок, то предлагаю добавлять слово COMMITTERS в имена файлов третьей пары сборок. Также добавлю в исходники это слово, чтобы оно отображалось в наименовании программы при запуске, аналогично отображению слова GOST как это было.

То есть получится:

1) без доп.слов (как это и есть)

2) GOST (как это и есть)

3) GOST (как это сейчас) переделать на GOST-COMMITTERS

GOST-COMMITTERS будет давать знать, что сборка на основе ветки lp:~kicad-gost-committers/kicad/kicad

 

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

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

Так что я за то, чтобы прекратить не нужное дробление на дополнительные ветки и вернуться к обычному понятию «ГОСТ-сборка». Сила в простоте...

первоначальные GOST сборки - это отдельная ветка с точки зрения сборок и в какой-то мере с точки зрения проекта.

GOST сборки с генератором ГОСТ КД + менеджер компонентов + pcad2kicadsch - это отдельная ветка еще и с точки зрения bazzar хранилища.

Любая bazaar ветка (их уже сейчас 44 штуки у проекта KiCad) имеет собственную нумерацию ревизий. Так устроена bazaar и куча других VCS. Может быть не удобно, но это факт.

Почему была создана отдельная ветка средствами bazaar? Я уже год жду, чтобы pcad2kicadsch добавили в ветку lp:kicad. Нет ни одного обоснованного аргумента против этого добавления. Но проект так и не добавлен. Та же участь ожидала и постигла генератор КД + менеджер компонентов. pcad2kicadpcb был добавлен в lp:kicad только спустя пол года удовлетворения капризов админов lp:kicad. Политику текущих админов ветки lp:kicad я не разделяю.

Соответственно, если бы не создал ветку lp:~kicad-gost-committers/kicad/kicad, то тем, кому по крайней мере нужны генератор КД + менеджер компонентов + конвертер pcad2kicadsch, ждали бы до второго пришествия.

 

P.S.: Похоже мы начали обсуждать вопросы не связанные с библиотеками. Просьба к администратору - перебросить сообщения в ветку "ГОСТ-сборки: тестовые и стабильные", либо хотя бы в "Сборка из исходников".

[Aldan 0]

Есть такое понятие - «эффект свежака», который иногда более грубо звучит как «эффект дурака» - это взгляд на проблему глазами непрофессионала. Пусть я буду этим дураком.

Так вот, я не могу придумать пользователя ГОСТ-сборок, который откажется от генератора перечня с менеджером и поставит себе такую же сборку, но без них. При таком раскладе совершенно не понятно зачем нужна прежняя ветка ГОСТ-сборок, если уже есть более полная ветка GOST-COMMITTERS? Получается, что тестовых сборок можно найти на все вкусы, а вот на стабильные с генератором перечня и менеджером сил уже не остается. Я в это въехать никак не могу!

Любая bazzar ветка (их уже сейчас 44 штуки у проекта KiCad) имеет собственную нумерацию ревизий. Так устроена bazzar и куча других VCS. Может быть не удобно, но это факт.

Вы же сами писали, что когда устаканится стабильная сборка и созреет генератор с менеджером, то их будут «мержить». Если я правильно понимаю, ничто не мешает дать такой сборке номер, соответствующий ее исходному с указанием, что это GOST-COMMITTERS.

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

если бы не создал ветку lp:~kicad-gost-committers/kicad/kicad, то тем, кому по крайней мере нужны генератор КД + менеджер компонентов + конвертер pcad2kicadsch, ждали бы до второго пришествия.

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

Хотелось бы услышать народное мнение по данному вопросу.

[break 0]

Aldan

Мой "опыт дурака" ;) говорит то же самое.