Lapack: Системы сборки

Чтобы добавить в список, сборки CMake в настоящее время (по всей видимости) поддерживают возможность сборки только выбранных частей библиотеки (REAL, DOUBLE, COMPLEX и / или DOUBLE COMPLEX), в то время как сборки только для Makefile - нет. (Я изменил файлы Makefile в копии, которую мы распространяем с помощью OpenBLAS, и при желании могу создать PR - нужно будет переделать файлы, чтобы пропустить некоторые изменения, которые здесь не актуальны)

Сборки CMake в настоящее время (похоже) поддерживают возможность сборки только выбранных частей библиотеки (REAL, DOUBLE, COMPLEX и / или DOUBLE COMPLEX)

Этот вариант работал в последний раз, когда я его пробовал (примерно в мае 2020 года).

В сборке CMake есть несколько вариантов, здесь я перечисляю самые важные для меня:

• создание общих или статических библиотек
• включены или отключены тесты
• 64- или 32-битные индексы
• оптимизированные и отладочные сборки
• опции для библиотеки генератора матриц (TMG), использование других библиотек BLAS, BLAS ++, LAPACK ++ ...

Отличная идея. Сборки, работающие на моей машине с make, но не на ci с CMake, несколько раз сводили меня с ума.

Технически, я думаю, что Makefile также поддерживает многие из этих опций (вы можете просто отредактировать свой make.inc). Если вам нужна сборка без тестов, вы можете построить с помощью make lib . Но что очень важно, создание общей библиотеки не поддерживается. Большинство людей используют LAPACK как разделяемую библиотеку, поэтому CMake для меня явный победитель.

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

Я подозреваю, что уже будет много патчей (например, в дистрибутивах linux, которые упаковывают Lapack) для создания общих библиотек с помощью gmake. Не должно быть слишком сложно добавить параметр BUILD_SHARED в make.inc, такой как BUILD_DEPRECATED, который уже существует (и оба они довольно неясны в сборке CMake, если кто-то еще не знает, что ccmake и cmake-gui существуют).

Не должно быть слишком сложно добавить параметр BUILD_SHARED в make.inc, такой как BUILD_DEPRECATED, который уже существует (и оба они довольно неясны в сборке CMake, если кто-то еще не знает, что ccmake и cmake-gui существуют).

Нет необходимости работать с ccmake чтобы установить какие-либо из этих параметров. Вы можете использовать командную строку, аналогичную сценарию configure сгенерированному autotools:

$ cmake -DBUILD_SHARED_LIBS=ON -DBUILD_COMPLEX=OFF -DBUILD_DEPRECATED=ON -- ../lapack/
[snip]
-- Build deprecated routines: ON
-- Build single precision real: ON
-- Build double precision real: ON
-- Build single precision complex: OFF
-- Build double precision complex: ON
[snip]
$ git -C ~/lapack rev-parse HEAD
6e125a41a7d4905d905a7467d3239d3f0d14b22c

Вы, конечно, можете, я хочу сказать, что нет очевидной документации, кроме чтения CMakelists.txt (тогда как README указывает на предварительно настроенные файлы make.inc для gmake). ccmake и cmake-gui показывают список доступных опций, но он будет утерян для всех, кто не знаком с cmake.

Если мы напишем документацию по использованию CMAKE, мы сможем использовать меня как пользователя-подопытного кролика, поскольку я никогда не использовал CMAKE.

Читая весь разговор, я чувствую, что Makefile находится в LAPACK только для меня. ;)

Ну, я не знаю.

Да: поддержка нескольких систем сборки приводит к несоответствиям. Так что я вижу аргумент в пользу того, чтобы иметь только один. (Будь то CMAKE, make или мезон.) (О да, я тоже никогда не использовал мезон, если вам интересно.)

Я беспокоюсь о переходе на CMAKE, потому что я не только не знаю, как его использовать, но и не знаю, как его поддерживать. Однако похоже, что у нас есть замечательное сообщество, которое может помочь, поэтому моя неспособность работать над этой частью проекта не кажется проблемой, кроме того, мне, вероятно, следует изучить CMAKE.

Все: Выскажите, пожалуйста, свое мнение в этой ветке.

Кажется, что большинство из нас хотели бы (1) удалить make и удалить мезон; (2) перейти только к CMAKE; (3) добавьте хорошую документацию по использованию CMAKE. Я согласен.

Я собираюсь разослать несколько писем другим сопровождающим пакетов здесь и там, чтобы спросить, как у них дела и каково их мнение по этому поводу.

@ martin-frbg: как это делается в OpenBLAS?

OpenBLAS имеет Makefiles как свою «традиционную» систему сборки, которая «заведомо работает», а CMAKE как изначально созданную пользователем альтернативу, которая по-прежнему выдаёт предупреждение о том, что генерируемые им файлы могут не точно соответствовать тому, что будет делать сборка Makefile.
Мне не очень нравится CMAKE, но я научился создавать рабочие (хотя, возможно, иногда нестандартные) файлы сборки cmake. На мой взгляд, файлы Makefile должны остаться (и я считаю, что gmake по-прежнему более распространен, чем cmake). Я не знаю истории мезонной поддержки - _если_ это был разовый «переброшенный через забор» вклад, о котором никто не знает или которого не заботится достаточно, чтобы держать его в курсе, я думаю, нет смысла держать его при себе.

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

Сборка Meson была спущена с парашютом в LAPACK в PR # 311.

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

Я связался с @therault, чтобы он @therault . Спасибо @therault!

Open MPI использует только autoconf (automake, autoconf, configure, Makefiles).

Для PaRSEC и DPLASMA мы используем только CMake, и чтобы помочь пользователям, которые привыкли настраивать, @abouteiller создал сценарий, который использует синтаксис configure и вызывает CMake с собственным синтаксисом.

Я знаю один крупный проект, в котором пытались поддерживать как configure, так и CMake. Он медленно развивался в ситуации, когда 100% функций были доступны в CMake, а в configure поддерживалось все меньше и меньше новых функций. Я считаю, что они перестали поддерживать версию configure.

Поддерживать две системы сборки для кода сложно: теоретически система сборки должна работать с любым кодом, и, таким образом, поддержка двух должна быть возможной (с высокими затратами для сопровождающих, чтобы поддерживать их синхронизацию, что является причиной того, что configure был исключен из этого другого проекта, сопровождающий решил, что у него есть дела поважнее). На практике иногда необходимо адаптировать код к системе сборки, чтобы упростить работу. Когда это происходит, одна из двух систем сборки должна использовать обходные пути и хаки, чтобы вести себя как другая и в соответствии с кодом.

В конце концов, CMake или configure, оба разочаруют. Мы программисты / математики / мы создаем алгоритмы ... Потратив время на то, чтобы понять, почему на этой машине с такой комбинацией компиляторов и флагов код не компилируется должным образом, это никому не нравится. Хуже того, попытка найти, как сделать то или иное, с помощью CMake или autoconf, сведет вас к минимуму :) Работая с обоими, я могу гарантировать, что вы будете жаловаться на них обоих :) Поддержание одного - верный способ жаловаться вдвое меньше.

Сегодня я поддерживаю CMake по единственной причине: CMake отлично справляется с созданием файлов Ninja вместо файлов Makefile. Ninja компилирует PaRSEC в два-три раза быстрее, чем Make -j. Теперь, возможно, configure / autoconf также может генерировать файлы Ninja, я никогда не пробовал ... Если вы никогда не пробовали ninja раньше, и если LAPACK имеет версию CMake, я предлагаю вам попробовать cmake -G Ninja (после установки Ninja на вашу машину). Для компиляции вы вызываете «ninja» в каталоге, в котором выполняли cmake, вместо «make». Вот увидишь, это потрясающе :)

Я с радостью предоставлю упомянутый сценарий соединения configure-to-cmake в LAPACK, если вас это интересует.
(чтобы уточнить, этот скрипт не основан на autoconf / m4, это простой скрипт, который преобразует configure --with-feature=value в вызов cmake -DFEATURE=value , с немного большей полировкой).

LAPACK даже не использует configure - и я согласен, что, вероятно, было бы сложно поддерживать систему на основе autoconf / automake / configure одновременно с cmake, поскольку сами автоинструменты постоянно «развиваются» и зависят от макросов m4 и прочего.

Я беспокоюсь о переходе на CMAKE, потому что я не только не знаю, как его использовать, но и не знаю, как его поддерживать.

Это основная причина придерживаться Make-файлов.

Все: Выскажите, пожалуйста, свое мнение в этой ветке.

Сборка Meson должна быть удалена. Никто не использует его, никто не знает, как его поддерживать, исходный автор представил неполную сборку и никогда не вернулся после того, как его изменения были объединены. Сколько людей знали, что существует сборка Meson до того, как я открыл этот выпуск?

CMake - это портативная система сборки с простым синтаксисом и полностью настраиваемыми сборками. Можно установить параметры для конкретного файла, компилятора или целевого объекта (например, для выборочного включения функций, которых нет в стандартной библиотеке C, таких как gethostname() ). CMake имеет надежное управление объектными файлами; это позволяет вам продолжать набирать make для обновления ваших сборок, даже если вы переключили ветки git. CMake прекрасно взаимодействует с остальной частью экосистемы UNIX: вы можете вызывать произвольные программы и действовать в соответствии с их выводом. Например, вы можете вызвать pkg-config, чтобы найти другие пакеты.

Впервые я использовал CMake в 2016 году, и с тех пор я постоянно использовал его для создания кода для систем Linux, Mac, iOS и Android на архитектурах с наборами инструкций x86, x86-64, armv7 и aarch64. Он доступен во всех основных дистрибутивах Linux и на всех суперкомпьютерах, к которым у меня есть доступ (Grid 5000, Jean Zay, JUWELS, GRICAD, Eagle II). Для суперкомпьютеров обычно доступно несколько версий, включая старые выпуски и самые свежие (3.18+). Единственная платформа, на которой я боролся с доступностью CMake, - это CentOS 7, но вы всегда можете загрузить тарбол CMake и использовать сценарий начальной загрузки внутри тарбола для сборки CMake только с помощью GNU Make.

CMake у меня просто работает.

Мой опыт работы с другими системами сборки следующий:

• Bazel: огромное количество памяти, невозможно запустить на Raspberry Pi с 1 ГБ памяти, настаивает на построении всех зависимостей и статическом связывании всего.
• Автоинструменты: как разработчик без опыта, как пользователь сценарий configure очень удобен, потому что он может показать вам все доступные параметры (CMake делает это с ccmake только после запуска cmake однажды).

Сегодня я поддерживаю CMake по единственной причине: CMake отлично справляется с созданием файлов Ninja вместо файлов Makefile. Ninja компилирует PaRSEC в два-три раза быстрее, чем Make -j.

Отлично, Ninja не мог скомпилировать Фортран в прошлом, ср. ninja # 1265 , т.е. в некоторых дистрибутивах это не будет работать (Debian 9?).

Я бы определенно сказал, что в этом случае проще и достаточно обычных make-файлов.
Сопровождение программного обеспечения в кластере HPC Я очень разочарован использованием Cmake.

1. Разработчикам сложно следовать стандартным схемам именования, что затрудняет сборку из-за чрезмерного чтения документации. Каждый пакет выполняет некоторую «настройку» имен, которые подходят их проектам. Это приводит к нестандартным схемам именования. (немного верно для autoconf +, но здесь все стандартизировано больше)
2. Когда что-то ломается в cmake, для его отладки требуется эксперт по cmake, мне все еще очень сложно отлаживать вещи ... :(
3. Трудно использовать файлы конфигурации (нет make.inc ), это заставляет указывать все параметры Bulild в командной строке во время сборки.

С другой стороны, cmake тоже делает приятные вещи:

1. Упрощенная поддержка Windows
2. Более автоматическая обработка зависимостей и включение файлов cmake для других проектов (это приятное преимущество)

Однако я не думаю, что для очень простой системы сборки LAPACK есть хорошие и плохие. Текущая система сборки работает десятилетиями, и люди к ней привыкли.
Кроме того, для быстрой параллельной сборки это можно тривиально добавить в текущую систему make-файлов ...

На самом деле у меня нет предпочтений, но должно быть абсолютно ясно, какие параметры поддерживаются какой системой сборки, если поддерживается больше ...

Я чувствую, что у меня такая же ситуация, как и у вас @langou .

Я не знаю cmake. Мне удалось использовать его только для этого проекта, потому что вся конфигурация уже была на месте, и я открыл конфигурацию travis и скопировал, вставив строки, которые он выполняет. Я не думаю, что это просто потому, что я неопытен. Makefile немного менее волшебный и кажется более низким уровнем. Это то, что, вероятно, находит отклик у людей, которые склонны работать над этим проектом.
Если бы чисто для личного использования, я бы продолжил использовать gmake, но тогда нам пришлось бы поместить все функции, которые в настоящее время доступны только в cmake, в Makefile. Особенно цель разделяемой библиотеки.

Однако я не могу игнорировать все приятные функции, которые, похоже, предлагает cmake. В конечном счете, я думаю, что cmake или gmake подойдут. Нам просто нужно выбрать один.

Я сторонний голос, но как человек, который помогает поддерживать Lapack в conda -forge , наличие CMake в системе сборки будет иметь несколько преимуществ (менее хакерский , встроенная поддержка Windows и т. Д.).

Требуется некоторое привыкание к синтаксису CMake, но у меня сложилось впечатление, что это хорошо поддерживаемая и хорошо документированная программа, которая успешно решает / абстрагируется от множества сложных проблем сборки. Я также занимаюсь упаковкой других библиотек и (субъективно) вижу, что все больше и больше переходят на CMake.

Просто еще одна точка данных извне; В нашей работе, которая включает в себя довольно много построений C / C ++, мы переходим к Meson после того, как слишком много боролись с CMake. Длинный список проблем с ним хорошо задокументирован в другом месте, поэтому я их пропускаю.

В проекте SciPy мы также попытаемся в какой-то момент использовать CMake или Meson, поскольку Python distutils выводится из эксплуатации.

Я согласен, что поддержка трех систем сборки приведет к несоответствиям и / или дополнительной работе для сопровождающих. Однако, исходя из приведенных выше комментариев и, на мой взгляд, у каждого пользователя есть свой способ создания кода. В частности, я согласен с комментарием @therault :

Мы программисты / математики / мы создаем алгоритмы ... Потратив время на то, чтобы понять, почему на этой машине с такой комбинацией компиляторов и флагов код не компилируется должным образом, это никому не нравится. Хуже того, попытка найти, как сделать то или иное, с помощью CMake или autoconf, сведет вас к минимуму :) Работая с обоими, я могу гарантировать, что вы будете жаловаться на них обоих :) Поддержание одного - верный способ жаловаться вдвое меньше.

Одна из идей обойти проблему с несколькими системами сборки:

• Создайте больше конфигураций в CI, чтобы охватить все поддерживаемые системы сборки. Таким образом, мы гарантируем, что все системы сборки работают с основными функциями.
• Представьте все и предложите использовать одну из систем сборки в README. Пример: _Мы предлагаем использовать CMake, если вам нужно создавать общие и статические библиотеки, ..._, как упоминалось @ martin-frbg, @ christoph-conrads и @thijssteel в этом потоке. (Я не знал, что в репозитории есть система сборки Meson. Думаю, нам следует либо добавить ее в README, либо прекратить поддержку этой опции.)

Насколько я понимаю, проблема с флагом recursive связана с процедурами тестирования xeigtstz (см. Https://github.com/Reference-LAPACK/lapack/issues/335# issuecomment-485021575). Когда эта проблема будет исправлена, я считаю, что мы решим либо

1. добавить флаг в конфигурацию CMake по умолчанию и везде, где он отсутствует, или
2. убрать флаг с файлов make.inc.* .

Небольшое недоразумение относительно -frecursive Я думаю - это необходимо для правильного функционирования многопоточного кода, поэтому его не следует удалять из файлов сборки в целом. Однако побочным эффектом является то, что он помещает в стек локальные массивы, которые в случае xeigtstz оказываются чрезвычайно большими. Удаление этой опции (только) из TESTING / EIG Makefile могло бы помочь в простом случае, но, похоже, это подразумевается при компиляции с помощью `-fopenmp ', так что это не общее решение для необычно больших требований к ограничению стека этого теста.

так вот почему.
Я согласен, что LAPACK - это «простая» библиотека - достаточно иметь систему make, и этого хватило на долгое время.
Но но но .. есть винда .. и только из-за винды пришлось принести cmake. Первоначально над конфигурацией работали люди из CMake, но теперь я думаю, что мы сами по себе, и, как @langou , мы на самом деле не осваиваем ее.
Сейчас большинство программ, основанных на LAPACK, используют Cmake, и мы знаем из отзывов пользователей, что им это нравится.

Итак, если нам нужно выбрать одну систему сборки: это должна быть Cmake ... к сожалению, в настоящее время, но, к счастью, в будущем.

Мой голос: следуйте советам @abouteiller и @ @therault и используйте только одну систему сборки, таким образом, cmake.

Сейчас большинство программ, основанных на LAPACK, используют Cmake, и мы знаем из отзывов пользователей , что им это нравится.

Я открыл этот выпуск и предложил использовать только одну систему сборки. Я предполагал, что навыки работы с Makefile и CMake распределены примерно равномерно. Пожалуйста, поправьте, если я ошибаюсь, но у меня сложилось впечатление, что это не так среди постоянных участников LAPACK : Makefiles кажутся популярными, а знания CMake кажутся слабыми. Более того, после двухдневного обсуждения флаги -frecursive по-видимому, являются единственной разницей между сборкой CMake и Makefile и тем фактом, что в Travis CI используется только CMake. Нет смысла навязывать одну систему сборки, которая делает пользователей счастливыми, если она отгоняет основных участников.

(Мое мнение о том, кто является постоянным участником, основано на просмотре первых пяти страниц принятых запросов на вытягивание.)

Согласен .. Кстати, рекурсивные флаги в конфигурациях CMake и Makefile по умолчанию с # 492. Итак, я думаю, нам просто нужно включить сборку Makefile в Travis CI.

PR # 500 устраняет несоответствия между системами сборки Makefile и CMake, о которых здесь говорится. См. Https://github.com/Reference-LAPACK/lapack/pull/500#issuecomment -788164244

Привет @ilayn. Спасибо за информацию о Meson / CMake / Makefile. Приятно иметь обратную связь со стороны и получать информацию о том, чем занимаются другие проекты. Мы не можем поддерживать все три системы и на данный момент предпочитаем CMake и Makefile, поэтому мы, скорее всего, выведем Meson из эксплуатации. Не говоря уже о том, что мы никогда не будем использовать Meson, но на данный момент у нас нет ресурсов для его поддержки. Это мое мнение. Думаю, мы скоро представим PR о выводе из эксплуатации Meson. Жюльен.