Сообщение Re[12]: Raspberry Pi dev device. от 25.03.2023 16:00
Изменено 25.03.2023 16:01 Евгений Музыченко
Re[12]: Raspberry Pi dev device.
Здравствуйте, /aka/, Вы писали:
A>Ты мыслишь категориями "ставим кросс-систему, и крутая магия создаёт нам бинарник, а если не создаёт, то она кривая".
Нет, я мыслю примерно так: "если моя основная рабочая система, где все удобно настроено, может собрать бинарники для другой целевой системы, под которой я не работаю регулярно, и там нет удобной среды для сборки, то откуда вообще может взяться идея делать это непосредственно на целевой системе?".
A>"Hello, world" для малины не нужно кросс-компилировать. Он и на самой малине скомпилируется за секунду.
Вот в этом-то все и дело. За десятилетия развития программирования сложилась вполне адекватная практика: средства разработки должны находиться и работать в той системе, где ведется эта самая разработка, а на целевые системы, где разработки не ведется, должны поступать уже готовые бинарники. От этого отступают лишь при крайней необходимости. Когда-то давно любой *nix автоматически являлся и системой разработки по себя, поэтому наличие в нем средств разработки было вполне оправдано. Когда же стали делать на базе него системы, где разработки не предполагалось, следовало как можно быстрее избавляться от традиции прилагать к каждому экземпляру системы еще и комплект из компилятора/линкера, заголовков и библиотек, как когда-то отказались от комплектации каждого автомобиля сундуком с инструментами и запчастями. Но традиция оказалась настолько прилипчивой, что идея жить на вечной стройке завоевала массы, и теперь вам от нее никуда не деться. Именно отсюда и растет корень многих ваших проблем.
A>Кросс-компилировать для малины может понадобится большие штуки, которые на малине будут собираться часами. Это значит мегабайты исходных кодов самого приложения и десятки посторонних библиотек, которых гарантированно не будет в самой прямой кросс-системе.
Так их и не должно там быть. Кросс-система — это набор базовых средств (компилятор, линкер и прочие build tools, стандартные заголовки, библиотеки, универсальные скрипты), с помощью которых можно собирать хоть "hello, world", хоть линукс, под любую из необходимых платформ. Все остальное добавляется отдельно, в явном виде, в нужном сочетании.
Соответственно, если разработка приложения ведется на той самой малине, то логично, чтобы все это было там. Если же разработка ведется в другой системе, то все это логично ставить в нее, а на малине, где не ведется разработка, вообще нет оснований держать что-то из этого.
A>И все эти десятки чужих библиотек, подобранных автором целевого продукта по функционалу, а не по качеству подготовки к кросс-компиляции, нужно допилить и кросс-компилировать. В этом трах.
Потому и трах, что разработчики этих библиотек, грубо говоря, привыкли и работать, и есть, и спать на одном месте, раскладывая всё необходимое вокруг себя, на расстоянии вытянутой руки. О том, что существуют рабочие кабинеты, кухни, столовые и спальни, а также ящики и шкафы, они либо не догадываются (если слаще морковки ничего не видали), либо убеждены, что все это лишнее, и настоящему линуксоиду только вредит.
Забавно, что винда и ее средства разработки, где изначально все было свалено в одну кучу, давно вышли из этого состояния, а в линуксе, вырасшем из униха с его строгим и разумным разделением по принадлежности разных средств, так и остался в идеологии 70-80-х.
A>Теперь представь, что таких SDK надо поставить тридцать.
Да хоть сто, если они сделаны минимально грамотно, а потому не конфликтуют ни друг с другом, ни с системой сборки. Главное, что их достаточно поставить в одну систему — основную, рабочую. А с целевой контактировать лишь постольку, поскольку это нужно для тестирования и отладки.
A>Потому что сейчас модно не писать руками то, что можно подтянуть из чужой библиотеки, и плевать на качество оформления библиотеки, у меня же собралось.
А качество оформления непосредственно вытекает из устоявшейся практики. Вот в унихах изначально была логика распределения и файлов по каталогам, и прав по пользователям, поэтому с этим изначально был относительный порядок. В досе/винде ничего этого не было, поэтому было принято "валить все в систему", и в этом говнище тоже "все собиралось". Потом MS нашел в себе силы поломать эту практику, и уже давно все выглядит достаточно пристойно, в кучу валят лишь самые отморозки. А линукс, наоборот, так и тянет эту порочную практику. Если даже сейчас начать изо всех сил ее искоренять, пройдет лет пять-семь, пока оно сдвинется. Так что вам еще долго с этим жить.
A>Ты мыслишь категориями "ставим кросс-систему, и крутая магия создаёт нам бинарник, а если не создаёт, то она кривая".
Нет, я мыслю примерно так: "если моя основная рабочая система, где все удобно настроено, может собрать бинарники для другой целевой системы, под которой я не работаю регулярно, и там нет удобной среды для сборки, то откуда вообще может взяться идея делать это непосредственно на целевой системе?".
A>"Hello, world" для малины не нужно кросс-компилировать. Он и на самой малине скомпилируется за секунду.
Вот в этом-то все и дело. За десятилетия развития программирования сложилась вполне адекватная практика: средства разработки должны находиться и работать в той системе, где ведется эта самая разработка, а на целевые системы, где разработки не ведется, должны поступать уже готовые бинарники. От этого отступают лишь при крайней необходимости. Когда-то давно любой *nix автоматически являлся и системой разработки по себя, поэтому наличие в нем средств разработки было вполне оправдано. Когда же стали делать на базе него системы, где разработки не предполагалось, следовало как можно быстрее избавляться от традиции прилагать к каждому экземпляру системы еще и комплект из компилятора/линкера, заголовков и библиотек, как когда-то отказались от комплектации каждого автомобиля сундуком с инструментами и запчастями. Но традиция оказалась настолько прилипчивой, что идея жить на вечной стройке завоевала массы, и теперь вам от нее никуда не деться.
Именно отсюда и растет корень многих ваших проблем.A>Кросс-компилировать для малины может понадобится большие штуки, которые на малине будут собираться часами. Это значит мегабайты исходных кодов самого приложения и десятки посторонних библиотек, которых гарантированно не будет в самой прямой кросс-системе.
Так их и не должно там быть. Кросс-система — это набор базовых средств (компилятор, линкер и прочие build tools, стандартные заголовки, библиотеки, универсальные скрипты), с помощью которых можно собирать хоть "hello, world", хоть линукс, под любую из необходимых платформ. Все остальное добавляется отдельно, в явном виде, в нужном сочетании.
Соответственно, если разработка приложения ведется на той самой малине, то логично, чтобы все это было там. Если же разработка ведется в другой системе, то все это логично ставить в нее, а на малине, где не ведется разработка, вообще нет оснований держать что-то из этого.
A>И все эти десятки чужих библиотек, подобранных автором целевого продукта по функционалу, а не по качеству подготовки к кросс-компиляции, нужно допилить и кросс-компилировать. В этом трах.
Потому и трах, что разработчики этих библиотек, грубо говоря, привыкли и работать, и есть, и спать на одном месте, раскладывая всё необходимое вокруг себя, на расстоянии вытянутой руки. О том, что существуют рабочие кабинеты, кухни, столовые и спальни, а также ящики и шкафы, они либо не догадываются (если слаще морковки ничего не видали), либо убеждены, что все это лишнее, и настоящему линуксоиду только вредит.
Забавно, что винда и ее средства разработки, где изначально все было свалено в одну кучу, давно вышли из этого состояния, а в линуксе, вырасшем из униха с его строгим и разумным разделением по принадлежности разных средств, так и остался в идеологии 70-80-х.
A>Теперь представь, что таких SDK надо поставить тридцать.
Да хоть сто, если они сделаны минимально грамотно, а потому не конфликтуют ни друг с другом, ни с системой сборки. Главное, что их достаточно поставить в одну систему — основную, рабочую. А с целевой контактировать лишь постольку, поскольку это нужно для тестирования и отладки.
A>Потому что сейчас модно не писать руками то, что можно подтянуть из чужой библиотеки, и плевать на качество оформления библиотеки, у меня же собралось.
А качество оформления непосредственно вытекает из устоявшейся практики. Вот в унихах изначально была логика распределения и файлов по каталогам, и прав по пользователям, поэтому с этим изначально был относительный порядок. В досе/винде ничего этого не было, поэтому было принято "валить все в систему", и в этом говнище тоже "все собиралось". Потом MS нашел в себе силы поломать эту практику, и уже давно все выглядит достаточно пристойно, в кучу валят лишь самые отморозки. А линукс, наоборот, так и тянет эту порочную практику. Если даже сейчас начать изо всех сил ее искоренять, пройдет лет пять-семь, пока оно сдвинется. Так что вам еще долго с этим жить.
Re[12]: Raspberry Pi dev device.
Здравствуйте, /aka/, Вы писали:
A>Ты мыслишь категориями "ставим кросс-систему, и крутая магия создаёт нам бинарник, а если не создаёт, то она кривая".
Нет, я мыслю примерно так: "если моя основная рабочая система, где все удобно настроено, может собрать бинарники для другой целевой системы, под которой я не работаю регулярно, и там нет удобной среды для сборки, то откуда вообще может взяться идея делать это непосредственно на целевой системе?".
A>"Hello, world" для малины не нужно кросс-компилировать. Он и на самой малине скомпилируется за секунду.
Вот в этом-то все и дело. За десятилетия развития программирования сложилась вполне адекватная практика: средства разработки должны находиться и работать в той системе, где ведется эта самая разработка, а на целевые системы, где разработки не ведется, должны поступать уже готовые бинарники. От этого отступают лишь при крайней необходимости. Когда-то давно любой *nix автоматически являлся и системой разработки под себя, поэтому наличие в нем средств разработки было вполне оправдано. Когда же стали делать на базе него системы, где разработки не предполагалось, следовало как можно быстрее избавляться от традиции прилагать к каждому экземпляру системы еще и комплект из компилятора/линкера, заголовков и библиотек, как когда-то отказались от комплектации каждого автомобиля сундуком с инструментами и запчастями. Но традиция оказалась настолько прилипчивой, что идея жить на вечной стройке завоевала массы, и теперь вам от нее никуда не деться. Именно отсюда и растет корень многих ваших проблем.
A>Кросс-компилировать для малины может понадобится большие штуки, которые на малине будут собираться часами. Это значит мегабайты исходных кодов самого приложения и десятки посторонних библиотек, которых гарантированно не будет в самой прямой кросс-системе.
Так их и не должно там быть. Кросс-система — это набор базовых средств (компилятор, линкер и прочие build tools, стандартные заголовки, библиотеки, универсальные скрипты), с помощью которых можно собирать хоть "hello, world", хоть линукс, под любую из необходимых платформ. Все остальное добавляется отдельно, в явном виде, в нужном сочетании.
Соответственно, если разработка приложения ведется на той самой малине, то логично, чтобы все это было там. Если же разработка ведется в другой системе, то все это логично ставить в нее, а на малине, где не ведется разработка, вообще нет оснований держать что-то из этого.
A>И все эти десятки чужих библиотек, подобранных автором целевого продукта по функционалу, а не по качеству подготовки к кросс-компиляции, нужно допилить и кросс-компилировать. В этом трах.
Потому и трах, что разработчики этих библиотек, грубо говоря, привыкли и работать, и есть, и спать на одном месте, раскладывая всё необходимое вокруг себя, на расстоянии вытянутой руки. О том, что существуют рабочие кабинеты, кухни, столовые и спальни, а также ящики и шкафы, они либо не догадываются (если слаще морковки ничего не видали), либо убеждены, что все это лишнее, и настоящему линуксоиду только вредит.
Забавно, что винда и ее средства разработки, где изначально все было свалено в одну кучу, давно вышли из этого состояния, а в линуксе, вырасшем из униха с его строгим и разумным разделением по принадлежности разных средств, так и остался в идеологии 70-80-х.
A>Теперь представь, что таких SDK надо поставить тридцать.
Да хоть сто, если они сделаны минимально грамотно, а потому не конфликтуют ни друг с другом, ни с системой сборки. Главное, что их достаточно поставить в одну систему — основную, рабочую. А с целевой контактировать лишь постольку, поскольку это нужно для тестирования и отладки.
A>Потому что сейчас модно не писать руками то, что можно подтянуть из чужой библиотеки, и плевать на качество оформления библиотеки, у меня же собралось.
А качество оформления непосредственно вытекает из устоявшейся практики. Вот в унихах изначально была логика распределения и файлов по каталогам, и прав по пользователям, поэтому с этим изначально был относительный порядок. В досе/винде ничего этого не было, поэтому было принято "валить все в систему", и в этом говнище тоже "все собиралось". Потом MS нашел в себе силы поломать эту практику, и уже давно все выглядит достаточно пристойно, в кучу валят лишь самые отморозки. А линукс, наоборот, так и тянет эту порочную практику. Если даже сейчас начать изо всех сил ее искоренять, пройдет лет пять-семь, пока оно сдвинется. Так что вам еще долго с этим жить.
A>Ты мыслишь категориями "ставим кросс-систему, и крутая магия создаёт нам бинарник, а если не создаёт, то она кривая".
Нет, я мыслю примерно так: "если моя основная рабочая система, где все удобно настроено, может собрать бинарники для другой целевой системы, под которой я не работаю регулярно, и там нет удобной среды для сборки, то откуда вообще может взяться идея делать это непосредственно на целевой системе?".
A>"Hello, world" для малины не нужно кросс-компилировать. Он и на самой малине скомпилируется за секунду.
Вот в этом-то все и дело. За десятилетия развития программирования сложилась вполне адекватная практика: средства разработки должны находиться и работать в той системе, где ведется эта самая разработка, а на целевые системы, где разработки не ведется, должны поступать уже готовые бинарники. От этого отступают лишь при крайней необходимости. Когда-то давно любой *nix автоматически являлся и системой разработки под себя, поэтому наличие в нем средств разработки было вполне оправдано. Когда же стали делать на базе него системы, где разработки не предполагалось, следовало как можно быстрее избавляться от традиции прилагать к каждому экземпляру системы еще и комплект из компилятора/линкера, заголовков и библиотек, как когда-то отказались от комплектации каждого автомобиля сундуком с инструментами и запчастями. Но традиция оказалась настолько прилипчивой, что идея жить на вечной стройке завоевала массы, и теперь вам от нее никуда не деться.
Именно отсюда и растет корень многих ваших проблем.A>Кросс-компилировать для малины может понадобится большие штуки, которые на малине будут собираться часами. Это значит мегабайты исходных кодов самого приложения и десятки посторонних библиотек, которых гарантированно не будет в самой прямой кросс-системе.
Так их и не должно там быть. Кросс-система — это набор базовых средств (компилятор, линкер и прочие build tools, стандартные заголовки, библиотеки, универсальные скрипты), с помощью которых можно собирать хоть "hello, world", хоть линукс, под любую из необходимых платформ. Все остальное добавляется отдельно, в явном виде, в нужном сочетании.
Соответственно, если разработка приложения ведется на той самой малине, то логично, чтобы все это было там. Если же разработка ведется в другой системе, то все это логично ставить в нее, а на малине, где не ведется разработка, вообще нет оснований держать что-то из этого.
A>И все эти десятки чужих библиотек, подобранных автором целевого продукта по функционалу, а не по качеству подготовки к кросс-компиляции, нужно допилить и кросс-компилировать. В этом трах.
Потому и трах, что разработчики этих библиотек, грубо говоря, привыкли и работать, и есть, и спать на одном месте, раскладывая всё необходимое вокруг себя, на расстоянии вытянутой руки. О том, что существуют рабочие кабинеты, кухни, столовые и спальни, а также ящики и шкафы, они либо не догадываются (если слаще морковки ничего не видали), либо убеждены, что все это лишнее, и настоящему линуксоиду только вредит.
Забавно, что винда и ее средства разработки, где изначально все было свалено в одну кучу, давно вышли из этого состояния, а в линуксе, вырасшем из униха с его строгим и разумным разделением по принадлежности разных средств, так и остался в идеологии 70-80-х.
A>Теперь представь, что таких SDK надо поставить тридцать.
Да хоть сто, если они сделаны минимально грамотно, а потому не конфликтуют ни друг с другом, ни с системой сборки. Главное, что их достаточно поставить в одну систему — основную, рабочую. А с целевой контактировать лишь постольку, поскольку это нужно для тестирования и отладки.
A>Потому что сейчас модно не писать руками то, что можно подтянуть из чужой библиотеки, и плевать на качество оформления библиотеки, у меня же собралось.
А качество оформления непосредственно вытекает из устоявшейся практики. Вот в унихах изначально была логика распределения и файлов по каталогам, и прав по пользователям, поэтому с этим изначально был относительный порядок. В досе/винде ничего этого не было, поэтому было принято "валить все в систему", и в этом говнище тоже "все собиралось". Потом MS нашел в себе силы поломать эту практику, и уже давно все выглядит достаточно пристойно, в кучу валят лишь самые отморозки. А линукс, наоборот, так и тянет эту порочную практику. Если даже сейчас начать изо всех сил ее искоренять, пройдет лет пять-семь, пока оно сдвинется. Так что вам еще долго с этим жить.