Вопрос Как запустить программу из исходных кодов в линуксе без всяких make install?
- Автор темы San4o03
- Дата начала
программисты никак без компиляции ничего не проверят. Проверяют тестами, дебагерром. а "всякие" make install нужны для компиляции. При следующей компиляции компилятор компилирует лишь измененные файлы и с ними связанные
>Как запустить программу из исходных кодов в линуксе ...
Никак
>без всяких make install?
Именно шаг инсталляции необязателен для проверки функциональности необязателен, это задача тестов.
>както же программисты проверяют свои проги без собирания и компиляции?!
Умом.
>не так же что кусок кода изменил и чтобы его проверить полчаса компилирует и инсталлирует.
Сборка некоторых приложений может занимать несколько дней и более. Эта часть автоматизируется и собирается ночами на отдельных серверах, продукт на выходе называется "ночной сборкой".
Общие принципы
1). Применяют модульный подход - задача состоит из кусочков, статических и динамических библиотек, подпроектов и прочего, функциональность каждого можно проверить независимо с использованием моков
2). Модульную функциональность проверяют unit-тестами, которые обычно запускаются после сборки. Эти тесты специально пишут таким образом, чтобы они выполнялись тысячами и миллионами за минуты, каждый из них тестирует какую-то примитивную вещь.
3). Банальные ошибки в коде сперва проверяют статистическими анализаторами, для этого сборка не требуется.
4). Для больших проектов, как указал выше, используются ночные сборки. Когда уже невозможно сделать полную пересборку проекта, берется ночная сборка со всеми отладочными файлами, после правок в каком-то модуле используется не полная, а частичная перекомпиляция, при которой пересобирается только та часть, где были внесены правки. Плюс используются прекомпилируемые заголовки, которые сильно ускоряют частичную сборку.
5) Большая часть программистов в крупных проектах никак не отвечает за сборку всего проекта целиком, у них зачастую просто нет прав и доступа к коду. Они работают со своим модулем по спецификации/тех.заданию, когда реализовывают - отправляют в свою ветку для тестирования фич. Из этих веток другие люди (зачастую даже не программисты) выковыривают нужные части черри-пикингом и сливают все в тестовую ветку. Ветка на серверах автоматически вытаскивается системами сборки, собирается и начинается выполнение тестов. Тесты для новых фич пишутся заранее, зачастую вообще отдельными программистами. После того как прошли юнит-тесты, начинаются интеграционные, отслеживающие ошибки, возникающие при взаимодействии разных модулей. Если какие-то интеграционные ошибки возникли - их будут смотреть люди, которые писали интерфейс взаимодействия (это тех. лиды и аналитики), в таком случае до реализующих низовую часть программистов эта ошибка может вообще не дойти, если в их реализации методов нет ошибок, хотя именно их код мог породить ошибки интеграции.
6) и так далее, тысячи их
Никак
>без всяких make install?
Именно шаг инсталляции необязателен для проверки функциональности необязателен, это задача тестов.
>както же программисты проверяют свои проги без собирания и компиляции?!
Умом.
>не так же что кусок кода изменил и чтобы его проверить полчаса компилирует и инсталлирует.
Сборка некоторых приложений может занимать несколько дней и более. Эта часть автоматизируется и собирается ночами на отдельных серверах, продукт на выходе называется "ночной сборкой".
Общие принципы
1). Применяют модульный подход - задача состоит из кусочков, статических и динамических библиотек, подпроектов и прочего, функциональность каждого можно проверить независимо с использованием моков
2). Модульную функциональность проверяют unit-тестами, которые обычно запускаются после сборки. Эти тесты специально пишут таким образом, чтобы они выполнялись тысячами и миллионами за минуты, каждый из них тестирует какую-то примитивную вещь.
3). Банальные ошибки в коде сперва проверяют статистическими анализаторами, для этого сборка не требуется.
4). Для больших проектов, как указал выше, используются ночные сборки. Когда уже невозможно сделать полную пересборку проекта, берется ночная сборка со всеми отладочными файлами, после правок в каком-то модуле используется не полная, а частичная перекомпиляция, при которой пересобирается только та часть, где были внесены правки. Плюс используются прекомпилируемые заголовки, которые сильно ускоряют частичную сборку.
5) Большая часть программистов в крупных проектах никак не отвечает за сборку всего проекта целиком, у них зачастую просто нет прав и доступа к коду. Они работают со своим модулем по спецификации/тех.заданию, когда реализовывают - отправляют в свою ветку для тестирования фич. Из этих веток другие люди (зачастую даже не программисты) выковыривают нужные части черри-пикингом и сливают все в тестовую ветку. Ветка на серверах автоматически вытаскивается системами сборки, собирается и начинается выполнение тестов. Тесты для новых фич пишутся заранее, зачастую вообще отдельными программистами. После того как прошли юнит-тесты, начинаются интеграционные, отслеживающие ошибки, возникающие при взаимодействии разных модулей. Если какие-то интеграционные ошибки возникли - их будут смотреть люди, которые писали интерфейс взаимодействия (это тех. лиды и аналитики), в таком случае до реализующих низовую часть программистов эта ошибка может вообще не дойти, если в их реализации методов нет ошибок, хотя именно их код мог породить ошибки интеграции.
6) и так далее, тысячи их