Сборка из исходников, вопросы по сборке будут жить здесь. Опции

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

Вопрос по кросс-сборке.
Задача: на машине с Linux Mint 14 (64 бита) собрать КиКАД для 32-битного виндовса. С wxWidgets проблем нет, указал --host=i686-w64-mingw32 --prefix=$BUILD_DIR/../install/wx-win, все собралось и установилось. Теперь сборка собственно КиКАДа. В доке такой вариант сборки не описан или я его не нашел. Гуглением выяснил, что надо создать файл (win-cross.cmake) примерно следующего содержания

CODE

# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Windows)

# which compilers to use for C and C++
SET(CMAKE_RC_COMPILER  i686-w64-mingw32-windres)
SET(CMAKE_C_COMPILER   i686-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER i686-w64-mingw32-g++)

# here is the target environment located
SET(CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32)

# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

и указать его cmake ключем -DCMAKE_TOOLCHAIN_FILE=../win-cross.cmake. Также указал путь к wx согласно инструкции: -DwxWidgets_ROOT_DIR=$BUILD_DIR/../install/wx-win"
Теперь cmake находит работающий компилятор и OpenGL но вылетает на поиске wxWidgets.

Возможно кто-то уже имеет опыт такой кросс-сборки? Как его заставить? Я, конечно, могу полезть копать внутренности CMakeModules/FindwxWidgets.cmake, но возможно кто-то уже прошел по этим граблям?

[zöner]

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

[AVL]

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

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

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

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

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

[AVL]

В настоящее время мы имеем дело с шестью видами сборок:
- «интернациональные» тестовые и стабильные, т. е. исходные сборки, (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]

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

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

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

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

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

[AVL]

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

Извините, не пойму о чем речь.

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

Сейчас и так все изменения из lp:kicad сливаются к нам (синхронизируется в нашу сторону). За исключением вырезанного BOM.
Синхронумерацию не представляю как сделать с lp:kicad, да и зачем это делать?

[Aldan]

Извините, не пойму о чем речь.

AVL, не принимайте на свой счет мое утверждение, что «затронутые проблемы интересуют только break и меня» т. к. я говорил о «народном мнении» дополнительно к обмену мнениями с Вами в нашей беседе. То есть Вы могли бы сейчас не отвечать на мое сообщение и все было бы в рамках нормы. Но коль скоро Вы просите пояснений, попробую выразиться более пространно. Итак, я писал:

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

Здесь я напоминаю Ваши слова:

могу предложить такой вариант, дожидаемся, когда менеджер компонентов+GOST-doc-gen станет "стабильным" и мержим этот код с последним стабильным релизом lp:kicad. Получаем, надеюсь, "стабильный" агрегированный релиз.

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

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

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

Сообщение отредактировал Aldan - Jun 11 2013, 22:41