The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Выпуск распределенной системы управления исходными текстами ..."
Отправлено Lefsha, 01-Янв-21 14:39 
> "Дикий путь", "неестественно"... Ты смотришь на git сверху-вниз, поэтому тебе и дико,
> и неестественно. git создавался снизу-вверх, и если ты с этой перспективы
> посмотришь, то всё встанет на свои места.
> Представь себе, что у тебя нет git, но ты хочешь работать с
> сорцами как-то так, будто он есть. Что ты будешь делать? Создавать
> копии директорий? Но это писанины куча, поэтому ты скорее всего напишешь

1. Я НЕ хочу работать с сорцами!
2. Я хочу просто скомпилировать то, что я скачал с того же github.
3. В зависимости от системы сборки, сама сборка засирает репозиторий.
При этом "make clean" или "make distclean" не очищает дир. полностью.
Новая сборка зависит от предыдущих. Это бесит, но это реальность.
4. Чаще, чем хотелось бы приходится патчить сборку, потому как она просто не работает
или работает не так. Это сам по себе итеративный процесс. Далеко не всегда работает.
Приходится сбрасываться и начинать заново. На 5-6 раз работает. НО. чтобы воспроизводимо
что-то менять нужно сбрасывать все в ноль. Иначе опять изменения идут по-верх других
изменений.
5. Разумеется все делается скриптами. Физически невозможно все править ручками и потом
еще помнить все проделанные шаги и повторять их раз за разом.
6. Иногда к счастью, иногда к сожалению разработка тоже не стоит на месте.
Если делать изменения в постоянно меняющемся коде, это самоубийство. Это только имеет смысл
в 2х случаях. Если сборка прошла успешно и хочется обновится на новую версию или когда нет шансов
собрать программу и остается надежда, что все исправлено в новой версии.

По опыту дай бог 50% всего компилируется без проблем. Я не знаю чем думают разработчики,
но факт в том, что часть программ собирается "через версию", часть не собирается вообще.
Обычно в таких случаях авторы не предлагают референсную процедуру сборки.

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

Я не знаю, зачем авторы так поступают. Есть ощущения, что они вообще никогда не тестируют
то что пишут.

Очень часто у них стоят определенные версии библиотек, но они сами не в курсе и другим не говорят, что сборка зависит от определенной версии.

Все что написано на C, С++ это мрак. Так же как и системы сборки make и cmake.

Cargo из Rust это просто другой уровень. Проблем на порядок меньше.

P.S. Варианты писать баг-репорты в upstream не предлагать. Стандартный ответ - у меня все работает. Или реакция как тут на форуме. Задаешь нормальный вопрос - тебя грязью обольют с ног до головы.

Люди в своей массе дебилоиды.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
  Введите код, изображенный на картинке: КОД
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру