Получается сейчас на сборочном компе должен быть Интернет обязательно, чтобы cmake
подгрузил boost-библиотеку с sf. Для меня это не всегда удобно.

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

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

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


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

на


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

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

Установлен 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. После установки собралось.

Сообщение отредактировал Барановский Константин - Jun 6 2013, 08:43

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

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

Сообщение отредактировал zöner - Jun 9 2013, 09:59

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

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

Либо собрать из исходников: 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

у меня свежесобранный 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

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

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

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

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

Даже если не отказываться от исходных 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.: Похоже мы начали обсуждать вопросы не связанные с библиотеками. Просьба к администратору - перебросить сообщения в ветку "ГОСТ-сборки: тестовые и стабильные", либо хотя бы в "Сборка из исходников".

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

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

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

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