Сделать (установить из исходного) python без запуска тестов

Я компилирую python из исходного tar. Все работает хорошо, но тесты работают 2 часа и два раза. Как обойти эти тесты?

0:16:20 [178/405] test_inspect
0:16:26 [179/405] test_int
0:16:27 [180/405] test_int_literal
0:16:27 [181/405] test_io
0:18:18 [182/405] test_ioctl -- test_io passed in 1 min 51 sec
0:18:19 [183/405] test_ipaddress
0:18:22 [184/405] test_isinstance
0:18:23 [185/405] test_iter
0:18:24 [186/405] test_iterlen
0:18:25 [187/405] test_itertools
0:19:09 [188/405] test_json -- test_itertools passed in 44 sec
0:19:30 [189/405] test_keyword

В результате

make 7724,86s user 188,63s system 101% cpu 2:10:18,93 total

Я делаю его распределение следующим образом

PYTHON_VERSION = 3.6.1
PYTHON_URL = https://www.python.org/ftp/python/${PYTHON_VERSION}/Python-${PYTHON_VERSION}.tar.xz

wget -O dl/Python-${PYTHON_VERSION}.tar.xz ${PYTHON_URL}

cd dl 
tar xf Python-${PYTHON_VERSION}.tar.xz

mkdir -p dl/Python-${PYTHON_VERSION}-build/
cd Python-${PYTHON_VERSION} 
    ./configure --enable-optimizations --prefix=$$(pwd)-build --cache-file=$$(pwd)/cache-file

Эти команды запускают тесты дважды:

make -C dl/Python-${PYTHON_VERSION} -j8 
make -C dl/Python-${PYTHON_VERSION} -j8 install

p.s. Это часть другого файла make.

Ответы

Ответ 1

Опция configure --enable-optimizations позволяет запускать тестовые классы для генерации данных для профилирования Python. Результирующий бинарный файл python имеет лучшую производительность при выполнении кода python. Усовершенствования отмечены здесь

From configure help:
--enable-optimizations  Enable expensive optimizations (PGO, etc). Disabled by default.

Из википедии

 profile-guided optimisation uses the results of profiling test runs of the instrumented program to optimize the final generated code.

Короче говоря, вы не должны пропускать тесты при использовании --enable-optimizations, поскольку данные, необходимые для профилирования, генерируются при выполнении тестов. Вы можете запустить make -j8 build_all, а затем make -j8 install, чтобы пропустить тесты один раз (тесты все равно будут выполняться с помощью install target), но это приведет к поражению цели. Вместо этого вы можете сбросить флаг configure для лучшего времени сборки.

Ответ 2

Я сделал небольшое (быстрое) исследование по пропуску тестовых прогонов при создании Python, указав либо:

  • configure - передача некоторых аргументов (например, --without-tests, --disable-tests, --skip-tests)
  • make - указание некоторой переменной (через среду или командную строку)

Первые не дали никаких результатов. Последнее (путем поиска в шаблоне Makefile) показало, что выполнение теста вызывается, вызывая ${PYTHON_SRC_DIR}/Tools/scripts/run_tests.py(который устанавливает некоторые вещи и вызывает другой script, который вызывает другой,...). Обратите внимание, что я нашел файл на Python3.5 (.4) и Python3.6 (.4), но не на Python2.7 (.14). Немного больше исследований показали, что можно пропустить (выше) тестовый прогон. Что вам нужно сделать:

make -C dl/Python-${PYTHON_VERSION} -j8 EXTRATESTOPTS=--list-tests install

Примечания

  • Google не показывал ничего (релевантно) на EXTRATESTOPTS, поэтому я предполагаю, что не поддерживается официально
  • Вы также можете установить EXTRATESTOPTS=--list-tests как переменную среды, прежде чем запускать (внутреннее) make
  • Излишне говорить, что если во время сборки возникла некоторая "незначительная" ошибка (например, некритический внешний модуль (например, _ssl.so, например) не удалось построить), тестов не будет терпеть неудачу, поэтому вы найдете об этом во время выполнения (что было бы ужасно неприятно, если бы это произошло в производстве).

@EDIT0

После комментария @amohr я решил немного поиграть, поэтому я выполнил весь процесс:

  • configure (opts)
  • make (opts)
  • make install

на машине Lnx (Ubtu16) с двумя процессорами, где один (полный) тестовый запуск занимает ~ 24 минуты. Вот мои выводы (Python3.6):

  • Он успешно прошел на Python3.5 (.4)
  • Решение, которое я предложил ранее, работает на этапе 3 rd поэтому он пропускает тестовый прогон 2 nd: он работает на (root) Makefile test target (make test), который вызывается install

  • Что касается тестового прогона 1 st проверив Makefile и сделав вывод, вот что я обнаружил, что происходит при 2 nd (make):

    • Источники C строятся "нормально"
    • Выполняются тесты (я вычитал, что некоторые данные профиля хранятся где-то)
    • Источники C перестраиваются с разными флагами (например, в моем случае gcc -fprofile-generate был заменен на -fprofile-use -fprofile-correction - проверить [GNU]: параметры, которые Оптимизация управления для получения дополнительной информации), чтобы использовать информацию профиля, сгенерированную на предыдущем (вспомогательном) шаге.

  • Пропуск тестового прогона 1 st будет автоматически подразумевать без оптимизации. Путь достижения:

    • make build_all (при 2 nd) - как предложено другими ответами

      • Здесь находится фрагмент файла (root) Makefile, сгенерированный опцией configure ( с --enable-optimizations):

        all:            profile-opt
build_all:      check-clean-src $(BUILDPYTHON) oldsharedmods sharedmods gdbhooks \
                Programs/_testembed python-config

      • И вот один без:

        all:            build_all
build_all:      check-clean-src $(BUILDPYTHON) oldsharedmods sharedmods gdbhooks \
                Programs/_testembed python-config

      • Как видно, работа:

        • configure --enable-optimizations
        • make build_all

        идентичен:

        • configure
        • make
    • Вручную модифицирует (root) Makefile между 1 st (configure --enable-optimizations) и 2 nr (make) шагов:
      • Найти определение макроса PROFILE_TASK=-m test.regrtest --pgo (для меня это было вокруг строки ~ 250)
      • Добавить --list-tests в конец
      • Шаги ((2.) 1 и (2.) 3.) точно совпадают, а для (2.) 2. тесты не выполняются. Это может означать, что:
        • Источники сборки 2 nd идентичны 1 st (что сделало бы его совершенно бесполезным)
        • 2 nd выполняет некоторую оптимизацию (без какой-либо информации), что означает, что она может быть повреждена во время выполнения (я думаю/надеюсь, что это первый случай)

Ответ 3

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

 make -C dl/Python-${PYTHON_VERSION} -j8 build_all

Ответ 4

просто собрать и установить с

make -j8 build_all
make -j8 altinstall