возможно, есть смысл сделать редактор атрибутов элементов схемы в виде таблицы.
что-то типа CvPcb, но для всех свойств, чтобы быстро заполнять/менять.
Полная версия этой страницы: Сборка из исходников
Форум разработчиков электроники ELECTRONIX.ru > Печатные платы (PCB) > Разрабатываем ПП в САПР - PCB development > KiCAD
Цитата(zöner @ Jun 9 2013, 13:58) 
возможно, есть смысл сделать редактор атрибутов элементов схемы в виде таблицы.
что-то типа CvPcb, но для всех свойств, чтобы быстро заполнять/менять.
что-то типа CvPcb, но для всех свойств, чтобы быстро заполнять/менять.
Ну так это уже можно делать в GOST менеджере компонентов.
где ? не могу найти
Цитата(zцner @ Jun 9 2013, 14:33)
где ? не могу найти
Либо собрать из исходников: 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 не наблюдаю.
пункта Tools->GOST Tools не наблюдаю.
Цитата(zöner @ Jun 9 2013, 15:29)
у меня свежесобранный BZR-4182-GOST, под линухом.
пункта Tools->GOST Tools не наблюдаю.
пункта Tools->GOST Tools не наблюдаю.
В данном случае BZR-4182-GOST - это из ветки lp:kicad.
А нужна ветка lp:~kicad-gost-committers/kicad/kicad
В ветке lp:~kicad-gost-committers/kicad/kicad сейчас актуальная ревизия 4142, и она как ни странно новее и функциональнее ревизии 4182 из ветки lp:kicad
Если честно, в плане обозначения ревизий готовых сборок я и сам понять не могу где какая ветка. Нужно совместно определить правило как давать имя файлу результирующей (бинарной) сборки.
По крайней мере, первый шаг - предлагаю организовать структуру директорий как описано в сообщении.
Цитата(zöner @ Jun 9 2013, 15:29)
у меня свежесобранный BZR-4182-GOST, под линухом. пункта Tools->GOST Tools не наблюдаю.
Если уж завсегдатаи нашего форума потеряли нить рассуждения и запутались в сборках, то нарастание хаоса дошло уже до критической отметки. Видимо, надо уже что-то делать, а именно, отсекать лишнее.
В настоящее время мы имеем дело с шестью видами сборок:
- «интернациональные» тестовые и стабильные, т. е. исходные сборки,
- ГОСТ-сборки тестовые и стабильные,
- ГОСТ-сборки с генератором перечня тестовые и (обещаны) стабильные.
Первая пара сборок нас не интересует, а вот со второй и третей парой сборок надо бы разобраться.
Цитата(AVL @ Jun 9 2013, 15:56)
Если честно, в плане обозначения ревизий готовых сборок я и сам понять не могу где какая ветка. Нужно совместно определить правило как давать имя файлу результирующей (бинарной) сборки.
В свое время faa взял на себя труд русифицировать Кикад и породил, таким образом, ГОСТ-сборки. С этого момента все «наши особенности» сборок всегда были в ее ГОСТ-части. Например, недавний патч Константина Барановского органически вписался в ГОСТ-сборку ибо он за бугром никому не нужен, а нужен только нам.
С появлением генератора перечня появилась еще одна ветка и с какой целью это было сделано, лично мне не понятно. Более того, в этой новой ветке своя нумерация не соответствующая другим веткам.
Возникает вопрос, а почему генератор перечня породил новую ветку, а не вписался в нашу ГОСТ- «добавку» как все, что было до этого момента? На мой взгляд, право на жизнь имеет только та ветка, которая обладает наибольшей полнотой. Если это ветка с генератором перечня, то нужно оставить только ее и все. Только тогда не будет распыления сил и путаницы. Кроме того, нужно восстановить соответствие нумерации Жан Пьеровских сборок нашим, чтобы окончательно не запутаться. Само название ГОСТ-сборка уже подразумевает, что она гораздо полнее исходной за счет всех наших нововведений.
Так что я за то, чтобы прекратить не нужное дробление на дополнительные ветки и вернуться к обычному понятию «ГОСТ-сборка». Сила в простоте...
Цитата(Aldan @ Jun 9 2013, 16:37)
В настоящее время мы имеем дело с шестью видами сборок:
- «интернациональные» тестовые и стабильные, т. е. исходные сборки, (1)
- ГОСТ-сборки тестовые и стабильные, (2)
- ГОСТ-сборки с генератором перечня тестовые и (обещаны) стабильные. (3)
Первая пара сборок нас не интересует, а вот со второй и третей парой сборок надо бы разобраться.
- «интернациональные» тестовые и стабильные, т. е. исходные сборки, (1)
- ГОСТ-сборки тестовые и стабильные, (2)
- ГОСТ-сборки с генератором перечня тестовые и (обещаны) стабильные. (3)
Первая пара сборок нас не интересует, а вот со второй и третей парой сборок надо бы разобраться.
Даже если не отказываться от исходных 2-х пар сборок, то предлагаю добавлять слово COMMITTERS в имена файлов третьей пары сборок. Также добавлю в исходники это слово, чтобы оно отображалось в наименовании программы при запуске, аналогично отображению слова GOST как это было.
То есть получится:
1) без доп.слов (как это и есть)
2) GOST (как это и есть)
3) GOST (как это сейчас) переделать на GOST-COMMITTERS
GOST-COMMITTERS будет давать знать, что сборка на основе ветки lp:~kicad-gost-committers/kicad/kicad
Цитата(Aldan @ Jun 9 2013, 16:37)
С появлением генератора перечня появилась еще одна ветка и с какой целью это было сделано, лично мне не понятно. Более того, в этой новой ветке своя нумерация не соответствующая другим веткам.
Возникает вопрос, а почему генератор перечня породил новую ветку, а не вписался в нашу ГОСТ- «добавку» как все, что было до этого момента? На мой взгляд, право на жизнь имеет только та ветка, которая обладает наибольшей полнотой. Если это ветка с генератором перечня, то нужно оставить только ее и все. Только тогда не будет распыления сил и путаницы. Кроме того, нужно восстановить соответствие нумерации Жан Пьеровских сборок нашим, чтобы окончательно не запутаться. Само название ГОСТ-сборка уже подразумевает, что она гораздо полнее исходной за счет всех наших нововведений.
Так что я за то, чтобы прекратить не нужное дробление на дополнительные ветки и вернуться к обычному понятию «ГОСТ-сборка». Сила в простоте...
Возникает вопрос, а почему генератор перечня породил новую ветку, а не вписался в нашу ГОСТ- «добавку» как все, что было до этого момента? На мой взгляд, право на жизнь имеет только та ветка, которая обладает наибольшей полнотой. Если это ветка с генератором перечня, то нужно оставить только ее и все. Только тогда не будет распыления сил и путаницы. Кроме того, нужно восстановить соответствие нумерации Жан Пьеровских сборок нашим, чтобы окончательно не запутаться. Само название ГОСТ-сборка уже подразумевает, что она гораздо полнее исходной за счет всех наших нововведений.
Так что я за то, чтобы прекратить не нужное дробление на дополнительные ветки и вернуться к обычному понятию «ГОСТ-сборка». Сила в простоте...
первоначальные 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.
Более того, мой опыт дурака говорит, что для соблюдения синхронизации номеров с исходной веткой достаточно вести отдельную ветку именно генератора с менеджером, как это сделал Константин Барановский для своего плагина, а не для полной сборки, которая перерастает в форк, который просто не потянуть малыми силами ГОСТ-разработчиков.
На мой взгляд, а дураку ведь все можно, очевидно, что давно нужно принять политическое решение о том, что Жан Пьер со своим приближением никогда не даст развиваться ГОСТ-сборке в необходимой полноте по той простой причине, что наши ГОСТ-примочки остальному миру не нужны. После осознания это факта становится ясно, что надо делать свою ветку, максимально синхронную с основной, но имеющую свои примочки, разрешение на которые не нужно спрашивать у Жан Пьера. Собственно, Вами и создана такая ветка, осталось только наладить максимальную синхронизацию в том числе и синхронумерацию. Если приложить голову, то все это можно сделать. Так, по крайней мере, на мой дурной взгляд видно.
Хотелось бы услышать народное мнение по данному вопросу.
Так вот, я не могу придумать пользователя ГОСТ-сборок, который откажется от генератора перечня с менеджером и поставит себе такую же сборку, но без них. При таком раскладе совершенно не понятно зачем нужна прежняя ветка ГОСТ-сборок, если уже есть более полная ветка GOST-COMMITTERS? Получается, что тестовых сборок можно найти на все вкусы, а вот на стабильные с генератором перечня и менеджером сил уже не остается. Я в это въехать никак не могу!
Цитата(AVL @ Jun 9 2013, 18:20)
Любая bazzar ветка (их уже сейчас 44 штуки у проекта KiCad) имеет собственную нумерацию ревизий. Так устроена bazzar и куча других VCS. Может быть не удобно, но это факт.
Вы же сами писали, что когда устаканится стабильная сборка и созреет генератор с менеджером, то их будут «мержить». Если я правильно понимаю, ничто не мешает дать такой сборке номер, соответствующий ее исходному с указанием, что это GOST-COMMITTERS.
Более того, мой опыт дурака говорит, что для соблюдения синхронизации номеров с исходной веткой достаточно вести отдельную ветку именно генератора с менеджером, как это сделал Константин Барановский для своего плагина, а не для полной сборки, которая перерастает в форк, который просто не потянуть малыми силами ГОСТ-разработчиков.
Цитата(AVL @ Jun 9 2013, 18:20)
если бы не создал ветку lp:~kicad-gost-committers/kicad/kicad, то тем, кому по крайней мере нужны генератор КД + менеджер компонентов + конвертер pcad2kicadsch, ждали бы до второго пришествия.
На мой взгляд, а дураку ведь все можно, очевидно, что давно нужно принять политическое решение о том, что Жан Пьер со своим приближением никогда не даст развиваться ГОСТ-сборке в необходимой полноте по той простой причине, что наши ГОСТ-примочки остальному миру не нужны. После осознания это факта становится ясно, что надо делать свою ветку, максимально синхронную с основной, но имеющую свои примочки, разрешение на которые не нужно спрашивать у Жан Пьера. Собственно, Вами и создана такая ветка, осталось только наладить максимальную синхронизацию в том числе и синхронумерацию. Если приложить голову, то все это можно сделать. Так, по крайней мере, на мой дурной взгляд видно.
Хотелось бы услышать народное мнение по данному вопросу.
Aldan
Мой "опыт дурака" говорит то же самое.
Мой "опыт дурака"
говорит то же самое.
Цитата(break @ Jun 10 2013, 12:55)
Aldan
Мой "опыт дурака" говорит то же самое.
Мой "опыт дурака"
говорит то же самое.break, благодарю, что откликнулись. Выходит, что затронутая проблема интересует только Вас и меня, а остальным до лампочки.., впрочем, все как всегда и наш форум не исключение. Не привыкли еще в нашей стране высказывать свое мнение, а жаль.
Цитата(Aldan @ Jun 9 2013, 19:53)
Вы же сами писали, что когда устаканится стабильная сборка и созреет генератор с менеджером, то их будут «мержить». Если я правильно понимаю, ничто не мешает дать такой сборке номер, соответствующий ее исходному с указанием, что это GOST-COMMITTERS.
Более того, мой опыт дурака говорит, что для соблюдения синхронизации номеров с исходной веткой достаточно вести отдельную ветку именно генератора с менеджером, как это сделал Константин Барановский для своего плагина, а не для полной сборки, которая перерастает в форк, который просто не потянуть малыми силами ГОСТ-разработчиков.
Более того, мой опыт дурака говорит, что для соблюдения синхронизации номеров с исходной веткой достаточно вести отдельную ветку именно генератора с менеджером, как это сделал Константин Барановский для своего плагина, а не для полной сборки, которая перерастает в форк, который просто не потянуть малыми силами ГОСТ-разработчиков.
Извините, не пойму о чем речь.
Цитата(Aldan @ Jun 9 2013, 19:53)
После осознания это факта становится ясно, что надо делать свою ветку, максимально синхронную с основной, но имеющую свои примочки, разрешение на которые не нужно спрашивать у Жан Пьера. Собственно, Вами и создана такая ветка, осталось только наладить максимальную синхронизацию в том числе и синхронумерацию. Если приложить голову, то все это можно сделать.
Сейчас и так все изменения из lp:kicad сливаются к нам (синхронизируется в нашу сторону). За исключением вырезанного BOM.
Синхронумерацию не представляю как сделать с lp:kicad, да и зачем это делать?
Цитата(AVL @ Jun 12 2013, 01:10)
Извините, не пойму о чем речь.
AVL, не принимайте на свой счет мое утверждение, что «затронутые проблемы интересуют только break и меня» т. к. я говорил о «народном мнении» дополнительно к обмену мнениями с Вами в нашей беседе. То есть Вы могли бы сейчас не отвечать на мое сообщение и все было бы в рамках нормы. Но коль скоро Вы просите пояснений, попробую выразиться более пространно. Итак, я писал:
Цитата(Aldan @ Jun 9 2013, 19:53)
Вы же сами писали, что когда устаканится стабильная сборка и созреет генератор с менеджером, то их будут «мержить». Если я правильно понимаю, ничто не мешает дать такой сборке номер, соответствующий ее исходному с указанием, что это GOST-COMMITTERS.
Здесь я напоминаю Ваши слова:
Цитата(AVL @ May 23 2013, 09:00)
могу предложить такой вариант, дожидаемся, когда менеджер компонентов+GOST-doc-gen станет "стабильным" и мержим этот код с последним стабильным релизом lp:kicad. Получаем, надеюсь, "стабильный" агрегированный релиз.
При этом я вопрошаю, а что же мешает при этой сборке указать номер основной стабильной ветки, на основании которой она сделана и только после этого выложить на наш фтп? А в свойствах сборки указать, что эта сборка GOST-COMMITTERS, если это так необходимо. Вроде бы мысль моя простая и понятная, не так ли?
Далее я писал:
Цитата(Aldan @ Jun 9 2013, 19:53)
Более того, мой опыт дурака говорит, что для соблюдения синхронизации номеров с исходной веткой достаточно вести отдельную ветку именно генератора с менеджером, как это сделал Константин Барановский для своего плагина, а не для полной сборки, которая перерастает в форк, который просто не потянуть малыми силами ГОСТ-разработчиков.
Здесь я пишу о том, что если бы Вы свой генератор с менеджером разрабатывали как некий отдельный продукт, который бы имел свою нумерацию и «мержился» бы с основным пакетом при сборке, то не возникла бы ситуация назревания форка, который, как я писал, не потянуть малыми силами ГОСТ-разработчиков.
Сейчас нумерация Ваших сборок ничего не говорит о версии сборки, на основании которой она сделана, да и о версии Вашего генератора с менеджером тоже ничего не говорит. Если бы у Вас была отдельная ветка генератора с менеджером со своей нумерацией, который бы «прикручивался при сборке», а сама сборка бы имела номер соответствующий основной ветке, а в инфо на сборку была бы указана текущая версия генератора с менеджером, то информация была бы исчерпывающей и вся путаница с версиями бы исчезла.
Правда, если так сделать, то Вы будете разработчиком лишь русифицированной ГОСТ-сборки Кикада, но, похоже, у Вас более глобальные амбиции - завлечь на свою ветку всех отвергнутых Жан Пьером, а это уже совсем другая история...
-=-=-=-=-=-=-=-
AVL, если теперь Вам все стало понятно, можете мне не отвечать. Мне к уже сказанному все равно добавить уже нечего. Дождусь когда ГОСТ-сборка с генератором и менеджером хоть немного устаканится, тогда и потестирую. Может быть тогда что-то и напишу.
Честно говоря, проблема версий совершенно не волнует. Для работы это почти не важно. Для работы важно знать какие новые печеньки появились, чтобы осознанно качать. Я чаще качаю чисто из любопытства или периодично раз в несколько месяцев, смотря сколько работы, чтобы попытаться увидеть новшества 
Билды и версии нужны разработчикам, чтобы не потеряться )))
Тут нужно понимать, что люди работают над проектом по доброте душевной, и грызть мозг еще из-за такой мелочи ... нафиг нужно
Билды и версии нужны разработчикам, чтобы не потеряться )))Тут нужно понимать, что люди работают над проектом по доброте душевной, и грызть мозг еще из-за такой мелочи ... нафиг нужно
Цитата(tema-electric @ Jun 12 2013, 06:02)
грызть мозг еще из-за такой мелочи ... нафиг нужно
Если мои слова воспринимаются в таком деструктивном ключе, то я, конечно, умолкаю. Действительно, надо же знать меру "улучшательству", а то ведь можно и отбить всякую охоту к работе. Пусть все развивается так, как удобно тем, кто работает, а пользователи уж как-то приспособятся
Цитата(Aldan @ Jun 12 2013, 02:37)
При этом я вопрошаю, а что же мешает при этой сборке указать номер основной стабильной ветки, на основании которой она сделана и только после этого выложить на наш фтп? А в свойствах сборки указать, что эта сборка GOST-COMMITTERS, если это так необходимо. Вроде бы мысль моя простая и понятная, не так ли?
...
Здесь я пишу о том, что если бы Вы свой генератор с менеджером разрабатывали как некий отдельный продукт, который бы имел свою нумерацию и «мержился» бы с основным пакетом при сборке, то не возникла бы ситуация назревания форка, который, как я писал, не потянуть малыми силами ГОСТ-разработчиков.
Сейчас нумерация Ваших сборок ничего не говорит о версии сборки, на основании которой она сделана, да и о версии Вашего генератора с менеджером тоже ничего не говорит. Если бы у Вас была отдельная ветка генератора с менеджером со своей нумерацией, который бы «прикручивался при сборке», а сама сборка бы имела номер соответствующий основной ветке, а в инфо на сборку была бы указана текущая версия генератора с менеджером, то информация была бы исчерпывающей и вся путаница с версиями бы исчезла.
...
Здесь я пишу о том, что если бы Вы свой генератор с менеджером разрабатывали как некий отдельный продукт, который бы имел свою нумерацию и «мержился» бы с основным пакетом при сборке, то не возникла бы ситуация назревания форка, который, как я писал, не потянуть малыми силами ГОСТ-разработчиков.
Сейчас нумерация Ваших сборок ничего не говорит о версии сборки, на основании которой она сделана, да и о версии Вашего генератора с менеджером тоже ничего не говорит. Если бы у Вас была отдельная ветка генератора с менеджером со своей нумерацией, который бы «прикручивался при сборке», а сама сборка бы имела номер соответствующий основной ветке, а в инфо на сборку была бы указана текущая версия генератора с менеджером, то информация была бы исчерпывающей и вся путаница с версиями бы исчезла.
Здесь придется указывать 2 ревизии тогда: первая - номер из lp:kicad/stable (вбивать при каждом коммите руками), вторая - номер из lp:~kicad-gost-committers/kicad/kicad.
По скольку будет следующая ситуация:
ответвились мы к примеру от ревизии 4020 ветки lp:kicad/stable. Далее ветка 4020 не меняется какое-то время, а мы за это время в свою стабильную ветку сделали 3 своих корректирующие баги коммита. Поэтому придется указывать 2 ревизии.
Теперь вопрос, а надо ли это? Почему мы не можем обойтись автоматическим механизмом вставки ревизии? У потенциальной ветки lp:~kicad-gost-committers/kicad/kicad-stable будет собственная нумерация ревизий точно так же как и у lp:kicad/stable собственная нумерация, не совпадающая с lp:kicad.
По суфиксу GOST-COMMITTERS)-stable можно будет понять, что это из GOST-COMMITTERS стабильной ветки. То есть номер уникальный в целом.
Если необходимо будет поднять информацию из чего произошли исходники конкретной ревизии, так это все есть в рамках инструментария bazaar (смотрим bzr qlog), там видны все слияния. Также можно это посмотреть на launchpad для интересующей ветки в комментариях коммитов.
С другой стороны, могу понять, что номер ревизии из lp:kicad/stable может быть полезным, если кто-то захочет опубликовать баг здесь: https://bugs.launchpad.net/kicad.
То есть пользователь видит проблему в конкретной сборке GOST-COMMITTERS)-stable, смотрит какая у нее ревизия соответствующая lp:kicad/stable, устанавливает соответстующую сборку lp:kicad/stable, проверяет, если проблема сохраняется, то публикует баг здесь: https://bugs.launchpad.net/kicad.
То есть вопрос, можем ли мы обойтись выяснением ревизии через bzr qlog / launchpad сайт? Или это очень не удобно и нужно все-таки руками вписывать номер ревизии из lp:kicad/stable в нашу стабильную ветку как доп.информацию?
Цитата(Aldan @ Jun 12 2013, 02:37)
Правда, если так сделать, то Вы будете разработчиком лишь русифицированной ГОСТ-сборки Кикада, но, похоже, у Вас более глобальные амбиции - завлечь на свою ветку всех отвергнутых Жан Пьером, а это уже совсем другая история...
Ветка lp:~kicad-gost-committers/kicad/kicad не ограничивается ГОСТом как таковым. Сюда может добавляться любая полезная функциональность. Помимо генератора КД + менеджера компонентов, в этой ветке также уже есть конвертер pcad2kicad и реанимированный BOM.
Насчет завлекания, ветка в плане разработки ориентирована на:
1) новых разработчиков, которые просто изначально начали работать в lp:~kicad-gost-committers/kicad/kicad, например, узнали про нее из данного форума.
2) разработчиков, которые видят, что происходит в lp:kicad и не жаждут желанием отправлять патчи в lp:kicad по той или иной причине.
3) разработчиков, у которых уже есть печальный опыт попыток работы с lp:kicad
4) разработчиков из lp:kicad (вдруг кто-то из их админов захочет к нам присоединиться
я если что не против)
Цитата(AVL @ Jun 12 2013, 13:15)
То есть вопрос, можем ли мы обойтись выяснением ревизии через bzr qlog / launchpad сайт? Или это очень не удобно и нужно все-таки руками вписывать номер ревизии из lp:kicad/stable в нашу стабильную ветку как доп.информацию?
Я думаю, что иметь номер ревизии из lp:kicad/stable сразу в about будет весьма полезно. Иначе часть багрепортов будет потеряна: не каждый из пользователей станет заниматься выяснением ревизии через bzr qlog / launchpad сайт.
ИМХО, ревизию lp:kicad можно указывать в комментарии к мержу.
Если уж фактически форкнулись, то для разработчиков будет вполне достаточно.
При багрепорте можно посмотреть, когда и с какой ревизией мержились, и фиксилось ли это в жпш-ветке.
Кстати, а когда (от какой ревизии) отпочковались?
Может уже пора там патч формировать и сюда накатывать? Они там довольно активно ваяют.
Если уж фактически форкнулись, то для разработчиков будет вполне достаточно.
При багрепорте можно посмотреть, когда и с какой ревизией мержились, и фиксилось ли это в жпш-ветке.
Кстати, а когда (от какой ревизии) отпочковались?
Может уже пора там патч формировать и сюда накатывать? Они там довольно активно ваяют.
Цитата(AVL @ Jun 12 2013, 10:15)
Здесь придется указывать 2 ревизии...
AVL, все сводится к вопросу: оставить все по-прежнему, интегрируя в основную сборку свои ГОСТ-фичи, или же организовать новую ветку Кикад, что неминуемо выльется в форк невзирая на все усилия по синхронизации.
Цитата(faa @ Jun 12 2013, 12:44)
Если уж фактически форкнулись
А вот и ответ на вопрос - «фактически форкнулись», т. е. выбор сделан. Так что все мои прежние вопросы и предложения были изначально бессмысленными, поэтому забудьте все, что я писал и я смиренно умолкаю
Цитата(faa @ Jun 12 2013, 13:44)
Кстати, а когда (от какой ревизии) отпочковались?
Ну изначально я делал ветку от ревизии 3592 lp:kicad (02 июня 2012 года) когда начал работу по интеграции и переработке pcad2kicad. С того времени периодически подтягиваю измения из lp:kicad к себе.
Цитата(faa @ Jun 12 2013, 13:44)
Может уже пора там патч формировать и сюда накатывать? Они там довольно активно ваяют.
Не пойму какой патч
Последний раз 07 июня 2013 года подтягивал изменения из lp:kicad (их ревизия 4199) в lp:~kicad-gost-committers/kicad/kicad (наша ревизия 4137).
Изменения из lp:kicad подтягиваю простой командой:
bzr merge lp:kicad
В большинстве случаев мерж выполняется автоматом. Но иногда могут быть конфликты, когда в lp:kicad кто-то изменил файлы, которые также менялись в lp:~kicad-gost-committers/kicad/kicad.
Эти дни пока больше не мержил с lp:kicad, потому что они сделали еще более глубокую вырезку функциональности BOM. Придется еще больше удаленных ими исходников брать на наше сопровождение. Я сейчас занят интеграцией новых форматок.
Цитата(Aldan @ Jun 12 2013, 14:06)
AVL, все сводится к вопросу: оставить все по-прежнему, интегрируя в основную сборку свои ГОСТ-фичи, или же организовать новую ветку Кикад, что неминуемо выльется в форк невзирая на все усилия по синхронизации.
А вот и ответ на вопрос - «фактически форкнулись», т. е. выбор сделан. Так что все мои прежние вопросы и предложения были изначально бессмысленными, поэтому забудьте все, что я писал и я смиренно умолкаю
А вот и ответ на вопрос - «фактически форкнулись», т. е. выбор сделан. Так что все мои прежние вопросы и предложения были изначально бессмысленными, поэтому забудьте все, что я писал и я смиренно умолкаю
Я пока не воспринимаю lp:~kicad-gost-committers/kicad/kicad как полноценный форк. Не превышен некий порог, чтобы это так назвать.
Пока делаются максимальные усилия не рассинхронизироваться с lp:kicad. На данный момент можно одни нажатием влить lp:~kicad-gost-committers/kicad/kicad в lp:kicad, было бы желание со стороны lp:kicad. И точно так же пока еще достаточно гладко вливаются изменения из lp:kicad в lp:~kicad-gost-committers/kicad/kicad.
Цитата(AVL @ Jun 12 2013, 15:30)
Я пока не воспринимаю lp:~kicad-gost-committers/kicad/kicad как полноценный форк. Не превышен некий порог, чтобы это так назвать.
Пока делаются максимальные усилия не рассинхронизироваться с lp:kicad.
Пока делаются максимальные усилия не рассинхронизироваться с lp:kicad.
AVL, на мой взгляд, чем больше будет нововведений в вашей ветке, тем труднее будет обеспечивать ее синхронизацию с основной и, во избежание нарастающих непродуктивных потерь ресурса разработчиков, постепенно вожжи соответствия будут отпущены. Это очевидная ситуация сидения между двух стульев, так что просто придется принять окончательное решение о форке раз уж движение в эту сторону одобрено. Ну, а вести форк малыми силами та еще задача, и неприятностей на таком пути может быть предостаточно.
Кроме того, оцените реальное положение вещей: faa — в последнее время надолго выпадает даже из общения, Константин Барановский тоже серьезно занят, viknn — не обновлял документацию к Кикаду с марта 2012 из-за своей загруженности, и т. д. Все это означает, что у разработчиков Кикад-ГОСТ катастрофически не хватает сил и времени, поэтому получится ли в такой ситуации тянуть форк — большой вопрос.
И еще, человечество не зря разделило программные продукты на тестовые и стабильные, дабы для конечных пользователей доходили именно стабильные финальные релизы. Однако, в нашей с Вами беседе выяснилась Ваша нелюбовь к стабильном сборкам из-за их отсталости и я просто не уверен в том, что теперь, после того, как «форкнулись», увижу еще хоть одну из них.
AVL, прошу Вас, не отвечайте мне, чтобы и я не должен был Вам отвечать. Благоразумнее завершить нашу беседу на эту тему. Сейчас все решит то, как все ГОСТ-разработчики выработают новые правила игры и все придет к некому новому общему знаменателю.
зачем Make танет boost из сети, если у меня уже установлен libboost-dev ?
Цитата(zцner @ Jun 12 2013, 19:50)
зачем Make танет boost из сети, если у меня уже установлен libboost-dev ?
Я не вникал в эту часть, но на сколько понимаю, он тянет boost конкретной версии, и скорее всего не проверяет наличие никаких установленных пакетов. В любой момент разработчиками KiCad может быть принято решение перейти на другую версию boost, и тогда будет автоматом при сборке KiCad перезакачана соответствующая версия boost.
Повторно реанимирован BOM ("eeschema->Tools->Generate Bill of Materials") после очередной попытки в lp:kicad вырезать все до корня.
На текущий момент lp:~kicad-gost-committers/kicad/kicad полностью синхронизирован с lp:kicad.
Актуальная ревизия 4146 в lp:~kicad-gost-committers/kicad/kicad, которая соответствует ревизии 4209 lp:kicad (testing)
На текущий момент lp:~kicad-gost-committers/kicad/kicad полностью синхронизирован с lp:kicad.
Актуальная ревизия 4146 в lp:~kicad-gost-committers/kicad/kicad, которая соответствует ревизии 4209 lp:kicad (testing)
Спасибо!
А 4209 lp:kicad - это stable или нет?
А 4209 lp:kicad - это stable или нет?
Цитата(AHTOXA @ Jun 13 2013, 07:45)
Спасибо!
А 4209 lp:kicad - это stable или нет?
А 4209 lp:kicad - это stable или нет?
Нет.
Не собирается последняя ревизия кикада у меня.
ветка: http://bazaar.launchpad.net/~kicad-gost-co...rs/kicad/kicad/
ревизия: 4053
Ошибка связана с BOM.
Со своей стороны я проделал:
1) чистил билд, пересобирал.
2) чистил и билд и саму папку с исходниками, потом делал bzr revert для восстановления файлов. Проверял через bzr status что исходники чистые.
Я бы мог снести совсем папку с исходниками (включая копию базара), но на мой взгляд это не поможет.
PS: откатился до 4052 - собралось.
ветка: http://bazaar.launchpad.net/~kicad-gost-co...rs/kicad/kicad/
ревизия: 4053
Ошибка связана с BOM.
Код
[ 58%] Building CXX object eeschema/CMakeFiles/eeschema.dir/dialogs/dialog_bom.cpp.o
/home/Data/Soft/GOST/kicad-gost.bzr/eeschema/dialogs/dialog_bom.cpp: In destructor ‘virtual DIALOG_BOM::~DIALOG_BOM()’:
/home/Data/Soft/GOST/kicad-gost.bzr/eeschema/dialogs/dialog_bom.cpp:226: error: no match for ‘operator<<’ in ‘list << STRING_FORMATTER::GetString()()’
/usr/include/wx-2.8/wx/string.h:992: note: candidates are: wxString& wxString::operator<<(const wxString&)
/usr/include/wx-2.8/wx/string.h:1003: note: wxString& wxString::operator<<(const wxChar*)
/usr/include/wx-2.8/wx/string.h:1006: note: wxString& wxString::operator<<(wxChar)
/usr/include/wx-2.8/wx/string.h:1010: note: wxString& wxString::operator<<(const wxWCharBuffer&)
/usr/include/wx-2.8/wx/string.h:1060: note: wxString& wxString::operator<<(int)
/usr/include/wx-2.8/wx/string.h:1063: note: wxString& wxString::operator<<(unsigned int)
/usr/include/wx-2.8/wx/string.h:1066: note: wxString& wxString::operator<<(long int)
/usr/include/wx-2.8/wx/string.h:1069: note: wxString& wxString::operator<<(long unsigned int)
/usr/include/wx-2.8/wx/string.h:1073: note: wxString& wxString::operator<<(long long int)
/usr/include/wx-2.8/wx/string.h:1079: note: wxString& wxString::operator<<(long long unsigned int)
/usr/include/wx-2.8/wx/string.h:1086: note: wxString& wxString::operator<<(float)
/usr/include/wx-2.8/wx/string.h:1089: note: wxString& wxString::operator<<(double)
/usr/include/wx-2.8/wx/icon.h:48: note: wxVariant& operator<<(wxVariant&, const wxIcon&)
/usr/include/wx-2.8/wx/icon.h:48: note: wxIcon& operator<<(wxIcon&, const wxVariant&)
/usr/include/wx-2.8/wx/image.h:74: note: wxVariant& operator<<(wxVariant&, const wxImage&)
/usr/include/wx-2.8/wx/image.h:74: note: wxImage& operator<<(wxImage&, const wxVariant&)
/usr/include/wx-2.8/wx/bitmap.h:36: note: wxVariant& operator<<(wxVariant&, const wxBitmap&)
/usr/include/wx-2.8/wx/bitmap.h:36: note: wxBitmap& operator<<(wxBitmap&, const wxVariant&)
/usr/include/wx-2.8/wx/colour.h:49: note: wxVariant& operator<<(wxVariant&, const wxColour&)
/usr/include/wx-2.8/wx/colour.h:49: note: wxColour& operator<<(wxColour&, const wxVariant&)
/usr/include/wx-2.8/wx/longlong.h:1071: note: wxTextOutputStream& operator<<(wxTextOutputStream&, long long int)
/usr/include/wx-2.8/wx/longlong.h:1070: note: wxTextOutputStream& operator<<(wxTextOutputStream&, long long unsigned int)
/usr/include/wx-2.8/wx/string.h:1649: note: std::ostream& operator<<(std::ostream&, const wxString&)
/home/Data/Soft/GOST/kicad-gost.bzr/eeschema/dialogs/dialog_bom.cpp: In member function ‘void DIALOG_BOM::installPluginsList()’:
/home/Data/Soft/GOST/kicad-gost.bzr/eeschema/dialogs/dialog_bom.cpp:247: error: no matching function for call to ‘BOM_CFG_READER_PARSER::BOM_CFG_READER_PARSER(wxArrayString*, const wxChar*, const wchar_t [8])’
/home/Data/Soft/GOST/kicad-gost.bzr/eeschema/dialogs/dialog_bom.cpp:76: note: candidates are: BOM_CFG_READER_PARSER::BOM_CFG_READER_PARSER(wxArrayString*, const char*, const wxString&)
/home/Data/Soft/GOST/kicad-gost.bzr/eeschema/dialogs/dialog_bom.cpp:61: note: BOM_CFG_READER_PARSER::BOM_CFG_READER_PARSER(const BOM_CFG_READER_PARSER&)
make[2]: *** [eeschema/CMakeFiles/eeschema.dir/dialogs/dialog_bom.cpp.o] Ошибка 1
make[1]: *** [eeschema/CMakeFiles/eeschema.dir/all] Ошибка 2
make: *** [all] Ошибка 2
/home/Data/Soft/GOST/kicad-gost.bzr/eeschema/dialogs/dialog_bom.cpp: In destructor ‘virtual DIALOG_BOM::~DIALOG_BOM()’:
/home/Data/Soft/GOST/kicad-gost.bzr/eeschema/dialogs/dialog_bom.cpp:226: error: no match for ‘operator<<’ in ‘list << STRING_FORMATTER::GetString()()’
/usr/include/wx-2.8/wx/string.h:992: note: candidates are: wxString& wxString::operator<<(const wxString&)
/usr/include/wx-2.8/wx/string.h:1003: note: wxString& wxString::operator<<(const wxChar*)
/usr/include/wx-2.8/wx/string.h:1006: note: wxString& wxString::operator<<(wxChar)
/usr/include/wx-2.8/wx/string.h:1010: note: wxString& wxString::operator<<(const wxWCharBuffer&)
/usr/include/wx-2.8/wx/string.h:1060: note: wxString& wxString::operator<<(int)
/usr/include/wx-2.8/wx/string.h:1063: note: wxString& wxString::operator<<(unsigned int)
/usr/include/wx-2.8/wx/string.h:1066: note: wxString& wxString::operator<<(long int)
/usr/include/wx-2.8/wx/string.h:1069: note: wxString& wxString::operator<<(long unsigned int)
/usr/include/wx-2.8/wx/string.h:1073: note: wxString& wxString::operator<<(long long int)
/usr/include/wx-2.8/wx/string.h:1079: note: wxString& wxString::operator<<(long long unsigned int)
/usr/include/wx-2.8/wx/string.h:1086: note: wxString& wxString::operator<<(float)
/usr/include/wx-2.8/wx/string.h:1089: note: wxString& wxString::operator<<(double)
/usr/include/wx-2.8/wx/icon.h:48: note: wxVariant& operator<<(wxVariant&, const wxIcon&)
/usr/include/wx-2.8/wx/icon.h:48: note: wxIcon& operator<<(wxIcon&, const wxVariant&)
/usr/include/wx-2.8/wx/image.h:74: note: wxVariant& operator<<(wxVariant&, const wxImage&)
/usr/include/wx-2.8/wx/image.h:74: note: wxImage& operator<<(wxImage&, const wxVariant&)
/usr/include/wx-2.8/wx/bitmap.h:36: note: wxVariant& operator<<(wxVariant&, const wxBitmap&)
/usr/include/wx-2.8/wx/bitmap.h:36: note: wxBitmap& operator<<(wxBitmap&, const wxVariant&)
/usr/include/wx-2.8/wx/colour.h:49: note: wxVariant& operator<<(wxVariant&, const wxColour&)
/usr/include/wx-2.8/wx/colour.h:49: note: wxColour& operator<<(wxColour&, const wxVariant&)
/usr/include/wx-2.8/wx/longlong.h:1071: note: wxTextOutputStream& operator<<(wxTextOutputStream&, long long int)
/usr/include/wx-2.8/wx/longlong.h:1070: note: wxTextOutputStream& operator<<(wxTextOutputStream&, long long unsigned int)
/usr/include/wx-2.8/wx/string.h:1649: note: std::ostream& operator<<(std::ostream&, const wxString&)
/home/Data/Soft/GOST/kicad-gost.bzr/eeschema/dialogs/dialog_bom.cpp: In member function ‘void DIALOG_BOM::installPluginsList()’:
/home/Data/Soft/GOST/kicad-gost.bzr/eeschema/dialogs/dialog_bom.cpp:247: error: no matching function for call to ‘BOM_CFG_READER_PARSER::BOM_CFG_READER_PARSER(wxArrayString*, const wxChar*, const wchar_t [8])’
/home/Data/Soft/GOST/kicad-gost.bzr/eeschema/dialogs/dialog_bom.cpp:76: note: candidates are: BOM_CFG_READER_PARSER::BOM_CFG_READER_PARSER(wxArrayString*, const char*, const wxString&)
/home/Data/Soft/GOST/kicad-gost.bzr/eeschema/dialogs/dialog_bom.cpp:61: note: BOM_CFG_READER_PARSER::BOM_CFG_READER_PARSER(const BOM_CFG_READER_PARSER&)
make[2]: *** [eeschema/CMakeFiles/eeschema.dir/dialogs/dialog_bom.cpp.o] Ошибка 1
make[1]: *** [eeschema/CMakeFiles/eeschema.dir/all] Ошибка 2
make: *** [all] Ошибка 2
Со своей стороны я проделал:
1) чистил билд, пересобирал.
2) чистил и билд и саму папку с исходниками, потом делал bzr revert для восстановления файлов. Проверял через bzr status что исходники чистые.
Я бы мог снести совсем папку с исходниками (включая копию базара), но на мой взгляд это не поможет.
PS: откатился до 4052 - собралось.
Цитата(tema-electric @ Jun 17 2013, 11:00)
Не собирается последняя ревизия кикада у меня.
ветка: http://bazaar.launchpad.net/~kicad-gost-co...rs/kicad/kicad/
ревизия: 4053
Ошибка связана с BOM.
...
Со своей стороны я проделал:
1) чистил билд, пересобирал.
2) чистил и билд и саму папку с исходниками, потом делал bzr revert для восстановления файлов. Проверял через bzr status что исходники чистые.
Я бы мог снести совсем папку с исходниками (включая копию базара), но на мой взгляд это не поможет.
PS: откатился до 4052 - собралось.
ветка: http://bazaar.launchpad.net/~kicad-gost-co...rs/kicad/kicad/
ревизия: 4053
Ошибка связана с BOM.
...
Со своей стороны я проделал:
1) чистил билд, пересобирал.
2) чистил и билд и саму папку с исходниками, потом делал bzr revert для восстановления файлов. Проверял через bzr status что исходники чистые.
Я бы мог снести совсем папку с исходниками (включая копию базара), но на мой взгляд это не поможет.
PS: откатился до 4052 - собралось.
Не знаю как под linux, но под MacOSX Lion вчера собралось без проблем http://electronix.ru/forum/index.php?s=&am...t&p=1170514
P.S. Вы наверно допустили описку - последняя версия 4153.
Цитата(tema-electric @ Jun 17 2013, 11:00)
Не собирается последняя ревизия кикада у меня.
ветка: http://bazaar.launchpad.net/~kicad-gost-co...rs/kicad/kicad/
ревизия: 4053
Ошибка связана с BOM.
[code][ 58%] Building CXX object eeschema/CMakeFiles/eeschema.dir/dialogs/dialog_bom.cpp.o
/home/Data/Soft/GOST/kicad-gost.bzr/eeschema/dialogs/dialog_bom.cpp: In destructor ‘virtual DIALOG_BOM::~DIALOG_BOM()’:
/home/Data/Soft/GOST/kicad-gost.bzr/eeschema/dialogs/dialog_bom.cpp:226: error: no match for ‘operator<<’ in ‘list << STRING_FORMATTER::GetString()()’
...
Со своей стороны я проделал:
1) чистил билд, пересобирал.
2) чистил и билд и саму папку с исходниками, потом делал bzr revert для восстановления файлов. Проверял через bzr status что исходники чистые.
Я бы мог снести совсем папку с исходниками (включая копию базара), но на мой взгляд это не поможет.
PS: откатился до 4052 - собралось.
ветка: http://bazaar.launchpad.net/~kicad-gost-co...rs/kicad/kicad/
ревизия: 4053
Ошибка связана с BOM.
[code][ 58%] Building CXX object eeschema/CMakeFiles/eeschema.dir/dialogs/dialog_bom.cpp.o
/home/Data/Soft/GOST/kicad-gost.bzr/eeschema/dialogs/dialog_bom.cpp: In destructor ‘virtual DIALOG_BOM::~DIALOG_BOM()’:
/home/Data/Soft/GOST/kicad-gost.bzr/eeschema/dialogs/dialog_bom.cpp:226: error: no match for ‘operator<<’ in ‘list << STRING_FORMATTER::GetString()()’
...
Со своей стороны я проделал:
1) чистил билд, пересобирал.
2) чистил и билд и саму папку с исходниками, потом делал bzr revert для восстановления файлов. Проверял через bzr status что исходники чистые.
Я бы мог снести совсем папку с исходниками (включая копию базара), но на мой взгляд это не поможет.
PS: откатился до 4052 - собралось.
Судя по логам ошибка в файле (dialog_bom.cpp), который добавили в lp:kicad.
Просьба собрать ревизию 4214 lp:kicad, если будет та же ошибка, то вижу варианты:
1) написать им багрепорт
2) подождать и сами исправят в lp:kicad
3) нам самим исправить
Цитата(AVL @ Jun 17 2013, 15:11)
Просьба собрать ревизию 4214 lp:kicad, если будет та же ошибка, то вижу варианты:
Где бы ее взять еще 4214
. Может я не на той ветке сижу? Код
Tree is up to date at revision 4153 of branch http://bazaar.launchpad.net/~kicad-gost-committers/kicad/kicad
Цитата(tema-electric @ Jun 17 2013, 13:40)
Где бы ее взять еще 4214 . Может я не на той ветке сижу?
. Может я не на той ветке сижу? Код
Tree is up to date at revision 4153 of branch http://bazaar.launchpad.net/~kicad-gost-committers/kicad/kicad
Не на той
Я предложил собрать ветку lp:kicad.
Цитата(tema-electric @ Jun 17 2013, 13:40)
Где бы ее взять еще 4214 . Может я не на той ветке сижу?
. Может я не на той ветке сижу? Код
Tree is up to date at revision 4153 of branch http://bazaar.launchpad.net/~kicad-gost-committers/kicad/kicad
Код
bzr branch lp:kicad kicad-last
bzr co kicad-last kicad4214 --revision 4214 --lightweight
bzr co kicad-last kicad4214 --revision 4214 --lightweight
В ходе этих двух нехитрых команд у вас в текущей директории появятся две субдиректории kicad-last и kicad4214 - вторую и используйте для сборки.
Цитата(AVL @ Jun 17 2013, 16:56)
Не на той
Я предложил собрать ветку lp:kicad.
Я предложил собрать ветку lp:kicad.
Да, я малость затупил
. 4214 тоже падает в том же месте. Дообрезались .
Цитата(tema-electric @ Jun 17 2013, 14:44)
Да, я малость затупил . 4214 тоже падает в том же месте. Дообрезались .
. 4214 тоже падает в том же месте. Дообрезались .Сможете отправить багрепорт на launchpad со ссылкой на 4214 lp:kicad ?
Цитата(AVL @ Jun 17 2013, 19:05)
Сможете отправить багрепорт на launchpad со ссылкой на 4214 lp:kicad ?
Я слабо представляю, как это сделать
Знал бы, без вопросов отправил бы. Цитата(AVL @ Jun 17 2013, 19:05)
Сможете отправить багрепорт на launchpad со ссылкой на 4214 lp:kicad ?
Я слабо представляю, как это сделать
Знал бы, без вопросов отправил бы. Если вздумаете инструкцию писать, можно в отдельную тему выделить, чтобы любители жаловаться знали
Цитата(AVL @ Jun 17 2013, 12:11)
Просьба собрать ревизию 4214 lp:kicad, если будет та же ошибка, то вижу варианты:
Последние 4214 и 4153 для Win собираются без ошибок (wx 2.9.4, gcc 4.7.2)
4153 не собралось.
Ошибка:
Линукс, магея1, gcc 4.5.2.
UPD: 4214 тоже не собирается - ошибка та же.
Багрепорт отправил.
Ошибка:
Код
/home/faa/rpmbuild/BUILD/kicad-gost-dev/eeschema/dialogs/dialog_bom.cpp: In destructor ‘virtual DIALOG_BOM::~DIALOG_BOM()’:
/home/faa/rpmbuild/BUILD/kicad-gost-dev/eeschema/dialogs/dialog_bom.cpp:226:30: ошибка: no match for ‘operator<<’ in ‘list << STRING_FORMATTER::GetString()()’
/home/faa/rpmbuild/BUILD/kicad-gost-dev/eeschema/dialogs/dialog_bom.cpp:226:30: ошибка: no match for ‘operator<<’ in ‘list << STRING_FORMATTER::GetString()()’
Линукс, магея1, gcc 4.5.2.
UPD: 4214 тоже не собирается - ошибка та же.
Багрепорт отправил.
Цитата(tema-electric @ Jun 17 2013, 17:29)
Я слабо представляю, как это сделать Знал бы, без вопросов отправил бы. Если вздумаете инструкцию писать, можно в отдельную тему выделить, чтобы любители жаловаться знали
Знал бы, без вопросов отправил бы. Если вздумаете инструкцию писать, можно в отдельную тему выделить, чтобы любители жаловаться знали Инструкции толком то и не наберется. Вот ссылка, по которой можно добавить баг репорт: https://bugs.launchpad.net/kicad/+filebug
faa уже отправил багрепорт (https://bugs.launchpad.net/kicad/+bug/1191892).
А вот его уже и исправили в ревизии 4215 lp:kicad.
Влил это исправление в ревизии 4154 ветки lp:~kicad-gost-committers/kicad/kicad.
Цитата(AVL @ Jun 18 2013, 02:09)
Влил это исправление в ревизии 4154 ветки lp:~kicad-gost-committers/kicad/kicad.
Все собралось, спасибо
Цитата(faa @ Jun 12 2013, 13:44)
Если уж фактически форкнулись
faa, мне хотелось бы с Вашей помощью понять есть ли пути развития Кикад-ГОСТ кроме как ухода в форк, а также хочется понять какова свобода для определения содержания ГОСТ-сброк, т. е. что можно, а что нельзя в них «вливать»? Вот, например, Вы пишете:
Цитата(faa @ Feb 5 2010, 00:52)
Насчет толщины рисования шины посмотрю. Если решится просто - добавлю в гостовскую сборку.
Т.е. в данном случае Вы воспользовались тем, что свойства ГОСТ-сборки проявляются только в том случае, если пользоваться именно ею. Пользователи других сборок данное нововведение не будут иметь. Такая самостоятельность именно ГОСТ-подраздела сборки, наверно, не сильно контролируется Жан Пьером и полностью отдана Вам под Вашу ответственность.
Получается, что ГОСТ-сборка, хоть и не форк, а все же позволяет «вливать» необходимые для нас новшества и при этом она нисколько не теряет связь с основной веткой Кикад.
При таком раскладе ГОСТ-сборка является неким «контейнером» на основной ветке, позволяющим аккумулировать в себе нечто сверх того, что дает основная ветка.
Если это так, то зачем «форкаться»? Чем плох вариант развития, который был до последнего момента?
И вытекающий из этого вопрос: будут ли и дальше выпускаться стабильные ГОСТ-сборки или теперь будет только kicad_gost_commiters?
Кто-нибудь смог собрать bz4152 (из kicad-gost на фтп-сервере) в Debian Testing? Вываливается с криком «"You must use '--with-gnomeprint' or '--with-gtkprint' in your wx
library configuration."», а в сети не нашлось ничего, кроме совета пересобрать libwxgtk.
library configuration."», а в сети не нашлось ничего, кроме совета пересобрать libwxgtk.
Цитата(Canis Dirus @ Jun 22 2013, 21:52)
Кто-нибудь смог собрать bz4152 (из kicad-gost на фтп-сервере) в Debian Testing? Вываливается с криком «"You must use '--with-gnomeprint' or '--with-gtkprint' in your wx
library configuration."», а в сети не нашлось ничего, кроме совета пересобрать libwxgtk.
library configuration."», а в сети не нашлось ничего, кроме совета пересобрать libwxgtk.
Вот что интересно, я сижу в Debian 6.0.7 (Squeeze), и у меня до сих пор все собирается
Не смотря на активную рассылку по этой проблеме на developer mailing list.
Цитата(AVL @ Jun 23 2013, 00:11)
Вот что интересно, я сижу в Debian 6.0.7 (Squeeze), и у меня до сих пор все собирается
Это ненадолго:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644571
В testing соответствующий баг уже закрыт, а gtkprint ещё нет и не будет, пока wxgtk до 2.9 не обновят:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713864
Цитата(Canis Dirus @ Jun 29 2013, 07:56)
Это ненадолго:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644571
В testing соответствующий баг уже закрыт, а gtkprint ещё нет и не будет, пока wxgtk до 2.9 не обновят:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713864
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644571
В testing соответствующий баг уже закрыт, а gtkprint ещё нет и не будет, пока wxgtk до 2.9 не обновят:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713864
Видимо у меня нет проблем потому, что использую собранные из исходников wxWidgets-2.9.4.
Цитата(Canis Dirus @ Jun 22 2013, 21:52)
Кто-нибудь смог собрать bz4152 (из kicad-gost на фтп-сервере) в Debian Testing? Вываливается с криком «"You must use '--with-gnomeprint' or '--with-gtkprint' in your wx
library configuration."», а в сети не нашлось ничего, кроме совета пересобрать libwxgtk.
library configuration."», а в сети не нашлось ничего, кроме совета пересобрать libwxgtk.
Я не вникал, но какая-то доработка на этот счет сделана в ревизии 4230 ветки lp:kicad.
Ревизия 4169 ветки lp:~kicad-gost-committers/kicad/kicad уже имеет в себе последние изменения из lp:kicad.
Цитата(viknn @ Sep 13 2013, 22:53)
выложил исходники 4313 ...
Пытаюсь собрать под Debian 7 (386)- получаю "undefined reference to wxAui".
CODE
[ 57%] Building CXX object cvpcb/CMakeFiles/cvpcb.dir/class_library_listbox.cpp.o
[ 57%] Building CXX object cvpcb/CMakeFiles/cvpcb.dir/cvframe.cpp.o
[ 57%] Building CXX object cvpcb/CMakeFiles/cvpcb.dir/cvpcb.cpp.o
[ 57%] Building CXX object cvpcb/CMakeFiles/cvpcb.dir/listboxes.cpp.o
[ 57%] Building CXX object cvpcb/CMakeFiles/cvpcb.dir/menubar.cpp.o
[ 58%] Building CXX object cvpcb/CMakeFiles/cvpcb.dir/readwrite_dlgs.cpp.o
[ 58%] Building CXX object cvpcb/CMakeFiles/cvpcb.dir/tool_cvpcb.cpp.o
[ 58%] Building CXX object cvpcb/CMakeFiles/cvpcb.dir/dialogs/dialog_cvpcb_config.cpp.o
[ 58%] Building CXX object cvpcb/CMakeFiles/cvpcb.dir/dialogs/dialog_cvpcb_config_fbp.cpp.o
[ 58%] Building CXX object cvpcb/CMakeFiles/cvpcb.dir/dialogs/dialog_display_options.cpp.o
[ 58%] Building CXX object cvpcb/CMakeFiles/cvpcb.dir/dialogs/dialog_display_options_base.cpp.o
Linking CXX executable cvpcb
CMakeFiles/cvpcb.dir/class_DisplayFootprintsFrame.cpp.o: In function `DISPLAY_FOOTPRINTS_FRAME::OnUpdateLineDrawMode(wxUpdateUIEvent&)':
class_DisplayFootprintsFrame.cpp:(.text+0xe8b): undefined reference to `wxAuiToolBar::SetToolShortHelp(int, wxString const&)'
CMakeFiles/cvpcb.dir/class_DisplayFootprintsFrame.cpp.o: In function `DISPLAY_FOOTPRINTS_FRAME::OnUpdateTextDrawMode(wxUpdateUIEvent&)':
class_DisplayFootprintsFrame.cpp:(.text+0x1362): undefined reference to `wxAuiToolBar::SetToolShortHelp(int, wxString const&)'
CMakeFiles/cvpcb.dir/class_DisplayFootprintsFrame.cpp.o: In function `DISPLAY_FOOTPRINTS_FRAME::ReCreateHToolbar()':
class_DisplayFootprintsFrame.cpp:(.text+0x15a5): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
class_DisplayFootprintsFrame.cpp:(.text+0x15e3): undefined reference to `wxAuiToolBar::AddSeparator()'
class_DisplayFootprintsFrame.cpp:(.text+0x168a): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
class_DisplayFootprintsFrame.cpp:(.text+0x1779): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
class_DisplayFootprintsFrame.cpp:(.text+0x1874): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
class_DisplayFootprintsFrame.cpp:(.text+0x196f): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
class_DisplayFootprintsFrame.cpp:(.text+0x19b9): undefined reference to `wxAuiToolBar::AddSeparator()'
class_DisplayFootprintsFrame.cpp:(.text+0x1a78): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
class_DisplayFootprintsFrame.cpp:(.text+0x1ac2): undefined reference to `wxAuiToolBar::Realize()'
CMakeFiles/cvpcb.dir/class_DisplayFootprintsFrame.cpp.o: In function `DISPLAY_FOOTPRINTS_FRAME::ReCreateOptToolbar()':
class_DisplayFootprintsFrame.cpp:(.text+0x1ddd): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
class_DisplayFootprintsFrame.cpp:(.text+0x1eb4): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
class_DisplayFootprintsFrame.cpp:(.text+0x1f9d): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
class_DisplayFootprintsFrame.cpp:(.text+0x2095): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
class_DisplayFootprintsFrame.cpp:(.text+0x2190): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
class_DisplayFootprintsFrame.cpp:(.text+0x21da): undefined reference to `wxAuiToolBar::AddSeparator()'
class_DisplayFootprintsFrame.cpp:(.text+0x2299): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
class_DisplayFootprintsFrame.cpp:(.text+0x2394): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
class_DisplayFootprintsFrame.cpp:(.text+0x248f): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
class_DisplayFootprintsFrame.cpp:(.text+0x24d9): undefined reference to `wxAuiToolBar::Realize()'
CMakeFiles/cvpcb.dir/class_DisplayFootprintsFrame.cpp.o: In function `DISPLAY_FOOTPRINTS_FRAME::DISPLAY_FOOTPRINTS_FRAME(CVPCB_MAINFRAME*, wxString const&, wxPoint const&, wxSize const&, long)':
class_DisplayFootprintsFrame.cpp:(.text+0x29f1): undefined reference to `wxAuiManager::SetManagedWindow(wxWindow*)'
class_DisplayFootprintsFrame.cpp:(.text+0x2ad8): undefined reference to `wxAuiManager::AddPane(wxWindow*, wxAuiPaneInfo const&)'
class_DisplayFootprintsFrame.cpp:(.text+0x2bc4): undefined reference to `wxAuiManager::AddPane(wxWindow*, wxAuiPaneInfo const&)'
class_DisplayFootprintsFrame.cpp:(.text+0x2c9d): undefined reference to `wxAuiManager::AddPane(wxWindow*, wxAuiPaneInfo const&)'
class_DisplayFootprintsFrame.cpp:(.text+0x2d87): undefined reference to `wxAuiManager::AddPane(wxWindow*, wxAuiPaneInfo const&)'
class_DisplayFootprintsFrame.cpp:(.text+0x2e66): undefined reference to `wxAuiManager::AddPane(wxWindow*, wxAuiPaneInfo const&)'
class_DisplayFootprintsFrame.cpp:(.text+0x2ec2): undefined reference to `wxAuiManager::Update()'
CMakeFiles/cvpcb.dir/class_DisplayFootprintsFrame.cpp.o: In function `wxAuiPaneInfo::~wxAuiPaneInfo()':
class_DisplayFootprintsFrame.cpp:(.text._ZN13wxAuiPaneInfoD2Ev[_ZN13wxAuiPaneInf
oD5Ev]+0x25): undefined reference to `wxAuiPaneButtonArray::~wxAuiPaneButtonArray()'
CMakeFiles/cvpcb.dir/class_DisplayFootprintsFrame.cpp.o: In function `wxAuiPaneInfo::wxAuiPaneInfo(wxAuiPaneInfo const&)':
class_DisplayFootprintsFrame.cpp:(.text._ZN13wxAuiPaneInfoC2ERKS_[_ZN13wxAuiPane
InfoC5ERKS_]+0x168): undefined reference to `wxAuiPaneButtonArray::operator=(wxAuiPaneButtonArray const&)'
class_DisplayFootprintsFrame.cpp:(.text._ZN13wxAuiPaneInfoC2ERKS_[_ZN13wxAuiPane
InfoC5ERKS_]+0x192): undefined reference to `wxAuiPaneButtonArray::~wxAuiPaneButtonArray()'
CMakeFiles/cvpcb.dir/class_DisplayFootprintsFrame.cpp.o: In function `wxAuiPaneInfo::operator=(wxAuiPaneInfo const&)':
class_DisplayFootprintsFrame.cpp:(.text._ZN13wxAuiPaneInfoaSERKS_[_ZN13wxAuiPane
InfoaSERKS_]+0xb5): undefined reference to `wxAuiPaneButtonArray::operator=(wxAuiPaneButtonArray const&)'
CMakeFiles/cvpcb.dir/class_DisplayFootprintsFrame.cpp.o: In function `wxAuiPaneInfo::DefaultPane()':
class_DisplayFootprintsFrame.cpp:(.text._ZN13wxAuiPaneInfo11DefaultPaneEv[_ZN13w
xAuiPaneInfo11DefaultPaneEv]+0x49): undefined reference to `wxAuiPaneInfo::IsValid() const'
CMakeFiles/cvpcb.dir/class_DisplayFootprintsFrame.cpp.o: In function `wxAuiPaneInfo::wxAuiPaneInfo()':
class_DisplayFootprintsFrame.cpp:(.text._ZN13wxAuiPaneInfoC2Ev[_ZN13wxAuiPaneInf
oC5Ev]+0x133): undefined reference to `wxAuiPaneButtonArray::~wxAuiPaneButtonArray()'
CMakeFiles/cvpcb.dir/class_DisplayFootprintsFrame.cpp.o: In function `wxAuiPaneInfo::SetFlag(int, bool)':
class_DisplayFootprintsFrame.cpp:(.text._ZN13wxAuiPaneInfo7SetFlagEib[_ZN13wxAui
PaneInfo7SetFlagEib]+0x6d): undefined reference to `wxAuiPaneInfo::IsValid() const'
CMakeFiles/cvpcb.dir/class_DisplayFootprintsFrame.cpp.o: In function `wxAuiToolBar::wxAuiToolBar(wxWindow*, int, wxPoint const&, wxSize const&, long)':
class_DisplayFootprintsFrame.cpp:(.text._ZN12wxAuiToolBarC2EP8wxWindowiRK7wxPoin
tRK6wxSizel[_ZN12wxAuiToolBarC5EP8wxWindowiRK7wxPointRK6wxSizel]+0x1f): undefined reference to `vtable for wxAuiToolBar'
class_DisplayFootprintsFrame.cpp:(.text._ZN12wxAuiToolBarC2EP8wxWindowiRK7wxPoin
tRK6wxSizel[_ZN12wxAuiToolBarC5EP8wxWindowiRK7wxPointRK6wxSizel]+0xbf): undefined reference to `wxAuiToolBar::Init()'
class_DisplayFootprintsFrame.cpp:(.text._ZN12wxAuiToolBarC2EP8wxWindowiRK7wxPoin
tRK6wxSizel[_ZN12wxAuiToolBarC5EP8wxWindowiRK7wxPointRK6wxSizel]+0xef): undefined reference to `wxAuiToolBar::Create(wxWindow*, int, wxPoint const&, wxSize const&, long)'
class_DisplayFootprintsFrame.cpp:(.text._ZN12wxAuiToolBarC2EP8wxWindowiRK7wxPoin
tRK6wxSizel[_ZN12wxAuiToolBarC5EP8wxWindowiRK7wxPointRK6wxSizel]+0x101): undefined reference to `wxAuiToolBarItemArray::~wxAuiToolBarItemArray()'
class_DisplayFootprintsFrame.cpp:(.text._ZN12wxAuiToolBarC2EP8wxWindowiRK7wxPoin
tRK6wxSizel[_ZN12wxAuiToolBarC5EP8wxWindowiRK7wxPointRK6wxSizel]+0x113): undefined reference to `wxAuiToolBarItemArray::~wxAuiToolBarItemArray()'
class_DisplayFootprintsFrame.cpp:(.text._ZN12wxAuiToolBarC2EP8wxWindowiRK7wxPoin
tRK6wxSizel[_ZN12wxAuiToolBarC5EP8wxWindowiRK7wxPointRK6wxSizel]+0x133): undefined reference to `wxAuiToolBarItemArray::~wxAuiToolBarItemArray()'
CMakeFiles/cvpcb.dir/cvframe.cpp.o: In function `CVPCB_MAINFRAME::SaveSettings()':
cvframe.cpp:(.text+0x322): undefined reference to `wxAuiToolBar::GetToolToggled(int) const'
cvframe.cpp:(.text+0x33b): undefined reference to `wxAuiToolBar::GetToolToggled(int) const'
cvframe.cpp:(.text+0x358): undefined reference to `wxAuiToolBar::GetToolToggled(int) const'
CMakeFiles/cvpcb.dir/cvframe.cpp.o: In function `CVPCB_MAINFRAME::DisplayStatus()':
cvframe.cpp:(.text+0x2ebf): undefined reference to `wxAuiToolBar::GetToolToggled(int) const'
cvframe.cpp:(.text+0x2f84): undefined reference to `wxAuiToolBar::GetToolToggled(int) const'
CMakeFiles/cvpcb.dir/cvframe.cpp.o:cvframe.cpp:(.text+0x308f): more undefined references to `wxAuiToolBar::GetToolToggled(int) const' follow
CMakeFiles/cvpcb.dir/cvframe.cpp.o: In function `CVPCB_MAINFRAME::~CVPCB_MAINFRAME()':
cvframe.cpp:(.text+0x3c0a): undefined reference to `wxAuiManager::UnInit()'
CMakeFiles/cvpcb.dir/cvframe.cpp.o: In function `CVPCB_MAINFRAME::OnSelectComponent(wxListEvent&)':
cvframe.cpp:(.text+0x3ff6): undefined reference to `wxAuiToolBar::GetToolToggled(int) const'
cvframe.cpp:(.text+0x400f): undefined reference to `wxAuiToolBar::GetToolToggled(int) const'
cvframe.cpp:(.text+0x402c): undefined reference to `wxAuiToolBar::GetToolToggled(int) const'
CMakeFiles/cvpcb.dir/cvframe.cpp.o: In function `CVPCB_MAINFRAME::CVPCB_MAINFRAME(wxString const&, long)':
cvframe.cpp:(.text+0x6016): undefined reference to `wxAuiManager::SetManagedWindow(wxWindow*)'
cvframe.cpp:(.text+0x60e1): undefined reference to `wxAuiManager::AddPane(wxWindow*, wxAuiPaneInfo const&)'
cvframe.cpp:(.text+0x61cf): undefined reference to `wxAuiManager::AddPane(wxWindow*, wxAuiPaneInfo const&)'
cvframe.cpp:(.text+0x62cd): undefined reference to `wxAuiManager::AddPane(wxWindow*, wxAuiPaneInfo const&)'
cvframe.cpp:(.text+0x63cb): undefined reference to `wxAuiManager::AddPane(wxWindow*, wxAuiPaneInfo const&)'
cvframe.cpp:(.text+0x63f1): undefined reference to `wxAuiManager::Update()'
CMakeFiles/cvpcb.dir/tool_cvpcb.cpp.o: In function `CVPCB_MAINFRAME::ReCreateHToolbar()':
tool_cvpcb.cpp:(.text+0x143): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
tool_cvpcb.cpp:(.text+0x226): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
tool_cvpcb.cpp:(.text+0x26a): undefined reference to `wxAuiToolBar::AddSeparator()'
tool_cvpcb.cpp:(.text+0x349): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
tool_cvpcb.cpp:(.text+0x393): undefined reference to `wxAuiToolBar::AddSeparator()'
tool_cvpcb.cpp:(.text+0x492): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
tool_cvpcb.cpp:(.text+0x58d): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
tool_cvpcb.cpp:(.text+0x5d7): undefined reference to `wxAuiToolBar::AddSeparator()'
tool_cvpcb.cpp:(.text+0x696): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
tool_cvpcb.cpp:(.text+0x791): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
tool_cvpcb.cpp:(.text+0x7db): undefined reference to `wxAuiToolBar::AddSeparator()'
tool_cvpcb.cpp:(.text+0x89a): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
tool_cvpcb.cpp:(.text+0x8e4): undefined reference to `wxAuiToolBar::AddSeparator()'
tool_cvpcb.cpp:(.text+0x9a3): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
tool_cvpcb.cpp:(.text+0x9ed): undefined reference to `wxAuiToolBar::AddSeparator()'
tool_cvpcb.cpp:(.text+0x9fb): undefined reference to `wxAuiToolBar::AddSeparator()'
tool_cvpcb.cpp:(.text+0xd89): undefined reference to `wxAuiToolBar::ToggleTool(int, bool)'
tool_cvpcb.cpp:(.text+0xdaa): undefined reference to `wxAuiToolBar::ToggleTool(int, bool)'
tool_cvpcb.cpp:(.text+0xdc7): undefined reference to `wxAuiToolBar::ToggleTool(int, bool)'
tool_cvpcb.cpp:(.text+0xde1): undefined reference to `wxAuiToolBar::Realize()'
CMakeFiles/cvpcb.dir/tool_cvpcb.cpp.o: In function `wxAuiToolBar::AddTool(int, wxBitmap const&, wxBitmap const&, bool, wxObject*, wxString const&, wxString const&)':
tool_cvpcb.cpp:(.text._ZN12wxAuiToolBar7AddToolEiRK8wxBitmapS2_bP8wxObjectRK8wxS
tringS7_[_ZN12wxAuiToolBar7AddToolEiRK8wxBitmapS2_bP8wxObjectRK8wxStringS7_]+0x8
8
): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxBitmap const&, wxItemKind, wxString const&, wxString const&, wxObject*)'
../3d-viewer/lib3d-viewer.a(3d_frame.cpp.o): In function `EDA_3D_FRAME::EDA_3D_FRAME(PCB_BASE_FRAME*, wxString const&, long)':
3d_frame.cpp:(.text+0x16e2): undefined reference to `wxAuiManager::wxAuiManager(wxWindow*, unsigned int)'
3d_frame.cpp:(.text+0x1903): undefined reference to `wxAuiManager::SetManagedWindow(wxWindow*)'
3d_frame.cpp:(.text+0x19a3): undefined reference to `wxAuiManager::AddPane(wxWindow*, wxAuiPaneInfo const&)'
3d_frame.cpp:(.text+0x1ab2): undefined reference to `wxAuiManager::AddPane(wxWindow*, wxAuiPaneInfo const&)'
3d_frame.cpp:(.text+0x1b0e): undefined reference to `wxAuiManager::Update()'
3d_frame.cpp:(.text+0x1c2e): undefined reference to `wxAuiManager::~wxAuiManager()'
../3d-viewer/lib3d-viewer.a(3d_frame.cpp.o): In function `EDA_3D_FRAME::~EDA_3D_FRAME()':
3d_frame.cpp:(.text._ZN12EDA_3D_FRAMED2Ev[_ZN12EDA_3D_FRAMED5Ev]+0x37): undefined reference to `wxAuiManager::UnInit()'
3d_frame.cpp:(.text._ZN12EDA_3D_FRAMED2Ev[_ZN12EDA_3D_FRAMED5Ev]+0x7f): undefined reference to `wxAuiManager::~wxAuiManager()'
3d_frame.cpp:(.text._ZN12EDA_3D_FRAMED2Ev[_ZN12EDA_3D_FRAMED5Ev]+0xe1): undefined reference to `wxAuiManager::~wxAuiManager()'
../3d-viewer/lib3d-viewer.a(3d_toolbar.cpp.o): In function `EDA_3D_FRAME::ReCreateHToolbar()':
3d_toolbar.cpp:(.text+0x430): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0x46e): undefined reference to `wxAuiToolBar::AddSeparator()'
3d_toolbar.cpp:(.text+0x515): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0x553): undefined reference to `wxAuiToolBar::AddSeparator()'
3d_toolbar.cpp:(.text+0x60c): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0x704): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0x7ff): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0x8fa): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0x944): undefined reference to `wxAuiToolBar::AddSeparator()'
3d_toolbar.cpp:(.text+0xa03): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0xafe): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0xb48): undefined reference to `wxAuiToolBar::AddSeparator()'
3d_toolbar.cpp:(.text+0xc27): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0xd22): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0xd6c): undefined reference to `wxAuiToolBar::AddSeparator()'
3d_toolbar.cpp:(.text+0xe2b): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0xf26): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0xf70): undefined reference to `wxAuiToolBar::AddSeparator()'
3d_toolbar.cpp:(.text+0x102f): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0x112a): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0x1225): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0x1320): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0x136a): undefined reference to `wxAuiToolBar::AddSeparator()'
3d_toolbar.cpp:(.text+0x1429): undefined reference to `wxAuiToolBar::AddTool(int, wxString const&, wxBitmap const&, wxString const&, wxItemKind)'
3d_toolbar.cpp:(.text+0x1473): undefined reference to `wxAuiToolBar::Realize()'
../common/libpcbcommon.a(basepcbframe.cpp.o): In function `PCB_BASE_FRAME::OnUpdatePadDrawMode(wxUpdateUIEvent&)':
basepcbframe.cpp:(.text+0x26e0): undefined reference to `wxAuiToolBar::SetToolShortHelp(int, wxString const&)'
../common/libpcbcommon.a(basepcbframe.cpp.o): In function `PCB_BASE_FRAME::OnUpdateCoordType(wxUpdateUIEvent&)':
basepcbframe.cpp:(.text+0x29e7): undefined reference to `wxAuiToolBar::SetToolShortHelp(int, wxString const&)'
../common/libcommon.a(basicframe.cpp.o): In function `EDA_BASE_FRAME::~EDA_BASE_FRAME()':
basicframe.cpp:(.text+0x1d2): undefined reference to `wxAuiManager::~wxAuiManager()'
basicframe.cpp:(.text+0x26c): undefined reference to `wxAuiManager::~wxAuiManager()'
../common/libcommon.a(basicframe.cpp.o): In function `EDA_BASE_FRAME::EDA_BASE_FRAME(wxWindow*, ID_DRAWFRAME_TYPE, wxString const&, wxPoint const&, wxSize const&, long, wxString const&)':
basicframe.cpp:(.text+0xbe9): undefined reference to `wxAuiManager::wxAuiManager(wxWindow*, unsigned int)'
basicframe.cpp:(.text+0xe02): undefined reference to `wxAuiManager::~wxAuiManager()'
../common/libcommon.a(drawframe.cpp.o): In function `EDA_DRAW_FRAME::~EDA_DRAW_FRAME()':
drawframe.cpp:(.text+0x39b): undefined reference to `wxAuiManager::UnInit()'
../common/libcommon.a(drawframe.cpp.o): In function `EDA_DRAW_FRAME::OnUpdateGrid(wxUpdateUIEvent&)':
drawframe.cpp:(.text+0x170f): undefined reference to `wxAuiToolBar::SetToolShortHelp(int, wxString const&)'
../common/libcommon.a(dialog_about.cpp.o): In function `dialog_about::CreateNotebookHtmlPage(wxAuiNotebook*, wxString const&, wxBitmap const&, wxString const&)':
dialog_about.cpp:(.text+0x1094): undefined reference to `wxAuiNotebook::AddPage(wxWindow*, wxString const&, bool, wxBitmap const&)'
../common/libcommon.a(dialog_about.cpp.o): In function `dialog_about::CreateNotebookPageByCategory(wxAuiNotebook*, wxString const&, wxBitmap const&, Contributors const&)':
dialog_about.cpp:(.text+0x25b5): undefined reference to `wxAuiNotebook::AddPage(wxWindow*, wxString const&, bool, wxBitmap const&)'
../common/libcommon.a(dialog_about.cpp.o): In function `dialog_about::CreateNotebookPage(wxAuiNotebook*, wxString const&, wxBitmap const&, Contributors const&)':
dialog_about.cpp:(.text+0x2fe2): undefined reference to `wxAuiNotebook::AddPage(wxWindow*, wxString const&, bool, wxBitmap const&)'
../common/libcommon.a(dialog_about_base.cpp.o): In function `dialog_about_base::dialog_about_base(wxWindow*, int, wxString const&, wxPoint const&, wxSize const&, long)':
dialog_about_base.cpp:(.text+0x2303): undefined reference to `vtable for wxAuiNotebook'
dialog_about_base.cpp:(.text+0x2336): undefined reference to `wxAuiManager::wxAuiManager(wxWindow*, unsigned int)'
dialog_about_base.cpp:(.text+0x2344): undefined reference to `wxAuiTabContainer::wxAuiTabContainer()'
dialog_about_base.cpp:(.text+0x2389): undefined reference to `wxAuiNotebook::Init()'
dialog_about_base.cpp:(.text+0x23b9): undefined reference to `wxAuiNotebook::Create(wxWindow*, int, wxPoint const&, wxSize const&, long)'
dialog_about_base.cpp:(.text+0x23e3): undefined reference to `wxAuiTabContainer::~wxAuiTabContainer()'
dialog_about_base.cpp:(.text+0x23f7): undefined reference to `wxAuiManager::~wxAuiManager()'
collect2: error: ld returned 1 exit status
make[2]: *** [cvpcb/cvpcb] Ошибка 1
make[1]: *** [cvpcb/CMakeFiles/cvpcb.dir/all] Ошибка 2
make: *** [all] Ошибка 2
wxWidgets-2.9.5: configure --with-opengl --enable-unicode
kicad: cmake -DCMAKE_BUILD_TYPE=Release -DKICAD_GOST=ON -DKICAD_STABLE_VERSION=ON -DUSE_WX_GRAPHICS_CONTEXT=OFF -DUSE_WX_OVERLAY=OFF -DKICAD_SCRIPTING=OFF -DKICAD_SCRIPTING_MODULES=OFF -DKICAD_SCRIPTING_WXPYTHON=OFF ../../
Что я делаю не так?
P.S. 4212 собралась с теми же ключами...
Цитата(alex9 @ Sep 15 2013, 18:40)
Пытаюсь собрать под Debian 7 (386)- получаю "undefined reference to wxAui".
wxWidgets-2.9.5: configure --with-opengl --enable-unicode
Что я делаю не так?
wxWidgets-2.9.5: configure --with-opengl --enable-unicode
Что я делаю не так?
Видать aui не включено. Больше года назад было как-то так, из того что я находил
Код
3. Сборка wxWidgets
cd wxWidgets-2.9.1
cd build-release
../configure --enable-unicode --disable-debuge --disable-shared --enable-monolithic --with-opengl --with-odbc --with-aui
make
make install
cd wxWidgets-2.9.1
cd build-release
../configure --enable-unicode --disable-debuge --disable-shared --enable-monolithic --with-opengl --with-odbc --with-aui
make
make install
В этом посте была ссылка на pdf по сборке под виндой и линуксом.
Цитата(tema-electric @ Sep 16 2013, 18:53)
Видать aui не включено. Больше года назад было как-то так, из того что я находил
В этом посте была ссылка на pdf по сборке под виндой и линуксом.
Код
3. Сборка wxWidgets
cd wxWidgets-2.9.1
cd build-release
../configure --enable-unicode --disable-debuge --disable-shared --enable-monolithic --with-opengl --with-odbc --with-aui
make
make install
cd wxWidgets-2.9.1
cd build-release
../configure --enable-unicode --disable-debuge --disable-shared --enable-monolithic --with-opengl --with-odbc --with-aui
make
make install
В этом посте была ссылка на pdf по сборке под виндой и линуксом.
Не помогло.
В pdf про aui нет ничего - видать, это какая-то новая фишка.
Цитата(alex9 @ Sep 16 2013, 21:00)
Не помогло.
В pdf про aui нет ничего - видать, это какая-то новая фишка.
В pdf про aui нет ничего - видать, это какая-то новая фишка.
Вместо --with-aui пробуйте --enable-aui
Цитата(AVL @ Sep 16 2013, 22:16)
Вместо --with-aui пробуйте --enable-aui
Тоже не помогло.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.