Lapack: 시스템 구축

목록에 추가하기 위해 CMake 빌드는 현재 라이브러리의 선택 부분(REAL, DOUBLE, COMPLEX 및/또는 DOUBLE COMPLEX)만 빌드하는 옵션을 지원하지만 Makefile 전용 빌드는 지원하지 않습니다. (OpenBLAS와 함께 배포하는 복사본에서 Makefile을 변경했으며 원하는 경우 PR을 생성할 수 있습니다. 여기서 관련이 없는 일부 변경 사항을 제외하려면 다시 수정해야 합니다.)

CMake 빌드는 현재 라이브러리(REAL, DOUBLE, COMPLEX 및/또는 DOUBLE COMPLEX)의 일부만 빌드하는 옵션을 지원합니다.

이 옵션은 내가 마지막으로 시도했을 때 작동했습니다(2020년 5월경).

CMake 빌드에는 몇 가지 옵션이 있으며 여기에 가장 중요한 옵션을 나열합니다.

• 공유 또는 정적 라이브러리 구축
• 테스트 활성화 또는 비활성화
• 64비트 또는 32비트 인덱스
• 최적화 및 디버깅 빌드
• 매트릭스 생성기 라이브러리(TMG) 옵션, 다른 BLAS 라이브러리 사용, BLAS++, LAPACK++...

좋은 생각. make로 내 컴퓨터에서 작동하지만 CMake로 ci에서는 작동하지 않는 빌드는 나를 몇 번 미치게 만들었습니다.

기술적으로 Makefile은 이러한 옵션도 많이 지원한다고 생각합니다(make.inc를 편집하면 됩니다). 테스트 없이 빌드를 원하면 make lib 빌드할 수 있습니다. 그러나 결정적으로 공유 라이브러리 구축은 지원되지 않습니다. 대부분의 사람들은 LAPACK을 공유 라이브러리로 사용하므로 CMake가 저에게 확실한 승자가 됩니다.

우리가 끝내면 readme에 몇 가지 추가 빌드 지침을 추가하는 것이 좋습니다. 테스트를 빌드하고 실행하는 방법, 플래그, 특히 frecursive 플래그를 추가하는 방법. 아마도 공유 라이브러리를 사용하는 방법에 대한 약간의 메모일 수도 있습니다.

나는 gmake로 공유 라이브러리를 구축하기 위해 이미 많은 패치가 떠돌아다니고 있을 것이라고 생각합니다(예: lapack을 패키지하는 Linux 배포판). 이미 있는 BUILD_DEPRECATED와 같이 make.inc에 BUILD_SHARED 옵션을 추가하는 것은 너무 복잡하지 않아야 합니다(그리고 ccmake 및 cmake-gui가 존재한다는 것을 이미 알고 있지 않는 한 둘 다 CMake 빌드에서 꽤 모호합니다).

이미 있는 BUILD_DEPRECATED와 같이 make.inc에 BUILD_SHARED 옵션을 추가하는 것은 너무 복잡하지 않아야 합니다(그리고 ccmake 및 cmake-gui가 존재한다는 것을 이미 알고 있지 않는 한 둘 다 CMake 빌드에서 꽤 모호합니다).

이러한 옵션을 설정하기 위해 ccmake 로 작업할 필요가 없습니다. autotools에서 생성한 configure 스크립트와 유사한 명령줄을 사용할 수 있습니다.

$ 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는 gmake용으로 미리 구성된 make.inc 파일을 가리킵니다). ccmake 및 cmake-gui는 사용 가능한 옵션 목록을 표시하지만 cmake를 처음 사용하는 사람에게는 이 목록이 표시되지 않습니다.

CMAKE 사용법에 대한 문서를 작성하면 CMAKE를 사용한 적이 없기 때문에 저를 기니피그 사용자로 사용할 수 있습니다.

전체 대화를 읽으면서 Makefile이 LAPACK에 나만을 위한 것 같다는 생각이 듭니다. ;)

글쎄, 나는 모른다.

예: 여러 빌드 시스템을 유지 관리하면 불일치가 발생합니다. 그래서 나는 하나만 가지고 있다는 주장을 봅니다. (CMAKE, make 또는 meson이든간에.) (아, 나도 meson을 사용한 적이 없습니다.)

CMAKE로 옮겨갈까말까 고민중인데 사용방법을 모를 뿐만 아니라 유지관리도 잘 몰라서요. 그러나 우리에게는 도움을 줄 수 있는 훌륭한 커뮤니티가 있는 것 같으므로 프로젝트의 이 부분에서 일하지 못하는 것이 문제가 되지 않을 것 같습니다. 또한 CMAKE를 배워야 할 것 같습니다.

전체: 이 스레드에서 귀하의 의견을 표현해 주십시오.

우리 대부분은 (1) make를 제거하고 meson을 제거하고 싶어하는 것 같습니다. (2) CMAKE로만 이동합니다. (3) CMAKE 사용 방법에 대한 몇 가지 좋은 문서를 추가합니다. 난 괜찮아.

여기저기서 다른 패키지 관리자에게 몇 가지 이메일을 보내 어떻게 하고 있으며 이 문제에 대한 의견을 묻겠습니다.

@martin-frbg: OpenBLAS에서 이것이 어떻게 이루어지나요?

OpenBLAS에는 "작동하는 것으로 알려진" "전통적인" 빌드 시스템으로 Makefile이 있으며, 생성하는 파일이 Makefile 빌드가 수행하는 작업과 정확히 일치하지 않을 수 있다는 경고를 여전히 내뿜는 원래 사용자 제공 대안으로 CMAKE가 있습니다.
나는 CMAKE를 별로 좋아하지 않지만 작동하는(때로는 비정통적이지만) cmake 빌드 파일을 만드는 방법을 배웠습니다. 제 생각에는 Makefile이 남아 있어야 합니다(그리고 gmake가 여전히 cmake보다 더 널리 퍼져 있다고 생각합니다). 나는 중간자 지원의 역사를 모릅니다 - _만약_ 이것이 아무도 알지 못하거나 계속 업데이트할 만큼 신경쓰지 않는 일회성 "담장 너머로 던져진" 기여였다면, 나는 그것을 계속 유지하는 것이 거의 의미가 없다고 생각합니다.

나는 중간자 지원의 역사를 모릅니다. 이것이 아무도 알지 못하거나 업데이트를 유지하기에 충분히 신경쓰지 않는 일회성 "담장 너머로 던져진" 기고라면, 나는 그것을 유지하는 것이 거의 의미가 없다고 생각합니다.

Meson 빌드는 PR #311의 LAPACK으로 낙하산되었습니다.

흠. 그것이 3.9.0에 받아들여진다면(단지 개념 증명으로라도), 바로 다음 릴리스에서 그것을 다시 버리는 것이 조금 이상하게 보일 것입니다...

나는 @therault 에게 연락하여 그가 우리에게 자신의 의견을 @therault 가 말한

Open MPI는 autoconf(automake, autoconf, configure, Makefiles)만 사용합니다.

PaRSEC 및 DPLASMA의 경우 CMake만 사용하며 구성에 익숙한 사용자를 돕기 위해

나는 configure와 CMake를 모두 유지하려고 시도한 하나의 주요 프로젝트를 알고 있습니다. 기능의 100%를 CMake에서 사용할 수 있고 구성에서 지원되는 새로운 기능이 점점 줄어들고 있는 상황에서 천천히 발전했습니다. 나는 그들이 구성 버전 유지 관리를 중단했다고 생각합니다.

코드에 대해 두 개의 빌드 시스템을 유지 관리하는 것은 어렵습니다. 이론적으로 빌드 시스템은 모든 코드와 함께 작동해야 하므로 두 개를 유지하는 것이 가능해야 합니다(유지 관리자가 동기화를 유지하려면 비용이 많이 듭니다. configure가 다른 프로젝트에서 빠졌고, 유지 보수는 시간을 할애할 수 있는 더 좋은 일을 하기로 결정했습니다.) 실제로 코드를 빌드 시스템에 맞게 조정하여 작업을 더 깔끔하게 만들 필요가 있습니다. 그런 일이 발생하면 두 빌드 시스템 중 하나가 해결 방법과 해킹을 사용하여 코드에 따라 다른 시스템처럼 작동해야 합니다.

결국 CMake 또는 구성 모두 실망할 것입니다. 우리는 프로그래머/수학자/우리는 알고리즘을 하고 있습니다... 왜 그 기계에서 컴파일러와 플래그의 조합으로 코드가 제대로 컴파일되지 않는지 이해하기 위해 시간을 보냅니다. 아무도 그것을 좋아하지 않습니다. 설상가상으로, CMake 또는 autoconf를 사용하여 그 일을 하거나 다른 일을 하는 방법을 찾으려고 하면 벽에 부딪힐 것입니다 :) 두 가지를 모두 사용하면 두 가지 모두에 대해 불평하게 될 것입니다. 두 번 덜 불평하십시오.

오늘 저는 CMake를 선호하는 이유가 하나 있습니다. CMake는 Makefile 대신 Ninja 파일을 잘 생성합니다. Ninja는 Make -j보다 2~3배 빠르게 PaRSEC를 컴파일합니다. 이제 configure/autoconf가 Ninja 파일을 생성할 수도 있습니다. 저는 시도한 적이 없습니다... 이전에 ninja를 시도한 적이 없고 LAPACK에 CMake 버전이 있는 경우 cmake -G Ninja를 시도하는 것이 좋습니다(컴퓨터에 Ninja를 설치한 후). 컴파일하려면 'make' 대신 cmake를 실행한 디렉토리에서 'ninja'를 호출합니다. 당신은 볼 수 있습니다, 그것은 놀라운 :)

만약 당신이 관심을 가지고 있다면 LAPACK에 configure-to-cmake 글루 스크립트를 제공하게 되어 기쁩니다.
(이 스크립트는 autoconf/m4 기반이 아니며 configure --with-feature=value 를 cmake -DFEATURE=value 에 대한 호출로 변환하는 간단한 스크립트입니다.

LAPACK은 configure를 사용하지도 않습니다. autoconf/automake/configure 기반 시스템을 cmake와 동시에 유지하고 autotools 자체가 지속적으로 "진화"하고 m4 매크로 등에 의존하는 것이 고통스러울 것이라는 데 동의합니다.

CMAKE로 옮겨갈까말까 고민중인데 사용방법을 모를 뿐만 아니라 유지관리도 잘 몰라서요.

이것이 Makefiles를 고수하는 주요 이유입니다.

전체: 이 스레드에서 귀하의 의견을 표현해 주십시오.

Meson 빌드를 제거해야 합니다. 아무도 그것을 사용하지 않고, 아무도 그것을 유지 관리하는 방법을 모릅니다. 원래 작성자는 불완전한 빌드를 제출했으며 변경 사항이 병합된 후에는 돌아오지 않았습니다. 이 문제를 열기 전에 얼마나 많은 사람들이 Meson 빌드가 있다는 것을 알았습니까?

CMake는 간단한 구문과 완전히 구성 가능한 빌드가 있는 이식 가능한 빌드 시스템입니다. 파일별, 컴파일러별 또는 대상별 옵션을 설정할 수 있습니다(예: gethostname() 와 같은 C 표준 라이브러리에 없는 기능을 선택적으로 활성화하기 위해). CMake에는 강력한 개체 파일 관리 기능이 있습니다. 이렇게 하면 git 분기를 전환한 경우에도 make 를 계속 입력하여 빌드를 업데이트할 수 있습니다. CMake는 나머지 UNIX 에코시스템과 원활하게 상호 작용합니다. 임의의 프로그램을 호출하고 출력에 따라 작업할 수 있습니다. 예를 들어 pkg-config를 호출하여 다른 패키지를 찾을 수 있습니다.

CMake를 처음 사용한 것은 2016년이었고 그 이후로 x86, x86-64, armv7 및 aarch64 명령어 세트 아키텍처에서 Linux, Mac, iOS 및 Android 시스템용 코드를 빌드하는 데 계속 사용했습니다. 모든 주요 Linux 배포판과 내가 액세스할 수 있는 모든 슈퍼컴퓨터(Grid 5000, Jean Zay, JUWELS, GRICAD, Eagle II)에서 사용할 수 있습니다. 슈퍼컴퓨터는 일반적으로 이전 릴리스와 최신 릴리스(3.18+)를 포함하여 여러 버전을 사용할 수 있습니다. CMake 가용성에 어려움을 겪은 유일한 플랫폼은 CentOS 7이지만 항상 CMake tarball을 다운로드하고 tarball 내부의 부트스트랩 스크립트를 사용하여 GNU Make로만 CMake를 빌드할 수 있습니다.

CMake는 저에게 딱 맞습니다.

다른 빌드 시스템에 대한 제 경험은 다음과 같습니다.

• Bazel: 1GB 메모리가 있는 Raspberry Pi에서 실행할 수 없는 거대한 메모리 호그, 모든 종속성을 구축하고 모든 것을 정적으로 연결해야 함
• autotools를 다음 사용자로 개발자 경험이없는, 같은 configure 가 (당신이 사용할 수있는 모든 옵션을 표시 할 수 있기 때문에 스크립트가 매우 편리합니다 CMake 않습니다와 ccmake 에만 실행 후 cmake 한 번).

오늘 저는 CMake를 선호하는 이유가 하나 있습니다. CMake는 Makefile 대신 Ninja 파일을 잘 생성합니다. Ninja는 Make -j보다 2~3배 빠르게 PaRSEC를 컴파일합니다.

좋습니다. Ninja는 과거에 Fortran을 컴파일할 수 없었습니다. 참조. ninja #1265 , 즉, 일부 배포판에서는 작동하지 않습니다(Debian 9?).

이 경우 일반 makefile이 더 쉽고 충분하다고 말할 수 있습니다.
HPC 클러스터에서 소프트웨어 유지 Cmake 사용에 매우 실망했습니다.

1. 개발자는 과도한 문서 읽기로 인해 빌드를 어렵게 만드는 표준 명명 체계를 따르는 데 어려움을 겪습니다. 모든 패키지는 프로젝트에 맞는 이름을 "조정"합니다. 따라서 비표준 명명 체계로 끝납니다. (autoconf+의 경우 약간 사실이지만 여기서는 더 표준화되었습니다)
2. cmake에서 문제가 발생하면 디버그하려면 cmake 전문가가 필요합니다. 여전히 디버깅하는 데 매우 어려움을 겪습니다... :(
3. 구성 파일을 사용하기 어렵습니다( make.inc ). 이는 빌드 시 명령줄에서 모든 bulild-options를 강제로 지정합니다.

반면에 cmake는 다음과 같은 좋은 작업도 수행합니다.

1. 더 쉬운 창 지원
2. 종속성을 보다 자동으로 처리하고 다른 프로젝트에 cmake 파일을 포함합니다(좋은 이점).

그러나 LAPACK의 매우 간단한 빌드 시스템에는 좋고 나쁨이 없다고 생각합니다. 현재 빌드 시스템은 수십 년 동안 작동했으며 사람들은 이에 익숙합니다.
또한 빠른 병렬 빌드를 위해 현재 makefile 시스템에 간단하게 추가할 수 있습니다.

나는 실제로 선호하는 것이 없지만 더 많은 것이 지원된다면 어떤 빌드 시스템에서 어떤 옵션을 지원하는지 절대적으로 분명 해야합니다 ...

@langou 님 과 비슷한 상황인 것

나는 cmake를 모른다. 모든 구성이 이미 준비되어 있고 travis 구성을 열고 실행되는 행을 복사하여 붙여넣기하여 이 프로젝트에만 사용할 수 있었습니다. 경험이 부족해서만은 아닌 것 같아요. Makefile은 약간 덜 마법적이고 더 낮은 수준으로 느껴집니다. 그것은 아마도 이 프로젝트에서 일하는 경향이 있는 사람들에게 반향을 일으킬 것입니다.
순전히 개인적인 용도라면 gmake를 계속 사용할 것이지만 현재 cmake에서만 사용할 수 있는 모든 기능을 Makefile에 넣어야 합니다. 특히 공유 라이브러리 대상.

그러나 cmake가 제공하는 모든 멋진 기능을 무시할 수 없습니다. 궁극적으로 나는 cmake나 gmake가 잘 될 것이라고 생각합니다. 우리는 하나만 선택하면 됩니다.

저는 외부 목소리이지만 conda-forge 에서 해킹 , 기본 Windows 지원 등).

CMake 구문에 익숙해지려면 약간의 시간이 필요하지만, 내 인상은 이것이 잘 유지되고 문서화되어 있는 소프트웨어로, 많은 까다로운 빌드 문제를 성공적으로 해결/추상화했다는 것입니다. 다른 라이브러리 패키징에도 참여하고 있으며 (주관적으로) CMake로의 이동이 점점 더 많아지고 있습니다.

외부의 또 다른 데이터 포인트입니다. 상당한 양의 C/C++ 빌드를 포함하는 작업에서 CMake로 너무 많은 어려움을 겪은 후 Meson으로 이동합니다. 그것과 관련된 긴 문제 목록은 다른 곳에서 잘 문서화되어 있으므로 생략하겠습니다.

SciPy 프로젝트에서는 Python distutils 이 폐기되고 있기 때문에 어느 시점에서 CMake 또는 Meson을 사용하려고 시도할 것입니다.

세 가지 빌드 시스템을 유지 관리하면 유지 관리자에게 불일치 및/또는 추가 작업이 발생한다는 데 동의합니다. 그러나 위의 의견과 제 생각에는 각 사용자가 코드를 빌드하는 고유한 방법이 있습니다. 특히 @therault 의 의견에 동의합니다.

우리는 프로그래머/수학자/우리는 알고리즘을 하고 있습니다... 왜 그 기계에서 컴파일러와 플래그의 조합으로 코드가 제대로 컴파일되지 않는지 이해하기 위해 시간을 보냅니다. 아무도 그것을 좋아하지 않습니다. 설상가상으로, CMake 또는 autoconf를 사용하여 그 일을 하거나 다른 일을 하는 방법을 찾으려고 하면 벽에 부딪힐 것입니다 :) 두 가지를 모두 사용하면 두 가지 모두에 대해 불평하게 될 것입니다. 두 번 덜 불평하십시오.

여러 빌드 시스템의 문제를 피하기 위한 한 가지 아이디어는 다음과 같습니다.

• 지원되는 모든 빌드 시스템을 포함하도록 CI에서 더 많은 구성을 만듭니다. 이렇게 하면 모든 빌드 시스템이 기본 기능과 함께 작동함을 보장합니다.
• 모든 것을 제시하고 README에서 빌드 시스템 중 하나의 사용을 제안하십시오. 예: _이 스레드에서 @martin-frbg, @christoph-conrads 및 @thijssteel 이 언급한 대로 _공유 및 정적 라이브러리를 빌드해야 하는 경우 CMake를 사용하는 것이 좋습니다. (리포지토리에 Meson 빌드 시스템이 있는지 몰랐습니다. README에 추가하거나 이 옵션 유지 관리를 중단해야 한다고 생각합니다.)

내가 이해하는 한 recursive 플래그의 문제는 테스트 루틴 xeigtstz (https://github.com/Reference-LAPACK/lapack/issues/335# 참조). 문제의견-485021575). 이 문제가 해결되면 다음 중 하나를 결정해야 한다고 생각합니다.

1. 플래그를 기본 CMake 구성 및 누락된 다른 위치에 추가하거나
2. make.inc.* 파일에서 플래그를 제거합니다.

약간의 오해 wrt -frecursive 제 생각에는 이것은 다중 스레드 코드의 올바른 기능에 필요하므로 일반적으로 빌드 파일에서 제거해서는 안 됩니다. 그러나 부작용은 xeigtstz의 경우 매우 큰 로컬 배열을 스택에 배치한다는 것입니다. TESTING/EIG Makefile에서만 이 옵션을 제거하는 것은 간단한 경우에 도움이 되는 것처럼 보이지만 `-fopenmp'로 컴파일할 때 암시되는 것처럼 보이기 때문에 이것은 해당 테스트의 비정상적으로 큰 스택 제한 요구 사항에 대한 일반적인 솔루션이 아닙니다.

그래서 여기에 이유가 있습니다.
나는 LAPACK이 "단순한" 라이브러리라는 데 동의합니다. make 시스템만 있으면 충분하고 오랫동안 충분했습니다.
하지만 하지만.. 윈도우도 있고.. 윈도우 때문에 cmake를 가져와야 했습니다. 원래 CMake의 사람들이 구성 작업을 했지만 지금은 우리가 혼자인 것 같고 @langou 처럼 실제로 마스터하지 못하고 있습니다.
이제 LAPACK을 기반으로 하는 대부분의 소프트웨어는 Cmake를 사용하고 있으며 사용자 피드백을 통해 그들이 좋아한다는 것을 알고 있습니다.

따라서 하나의 빌드 시스템을 선택해야 하는 경우: 이것은 Cmake여야 합니다... 현재로서는 불행하지만 미래에는 다행입니다.

내 투표: @abouteiller 및 @ @therault 의 조언을

이제 LAPACK을 기반으로 하는 대부분의 소프트웨어는 Cmake를 사용하고 있으며 사용자 피드백을 통해 그들이 좋아한다는 것을 알고 있습니다.

나는 이 문제를 열고 단 하나의 빌드 시스템을 갖자고 제안했습니다. 내 가정은 Makefile과 CMake 기술이 거의 고르게 분포되어 있다는 것입니다. 내가 틀렸다면 정정해주세요. 하지만 내 인상은 이것이 일반 LAPACK 기고자 사이에서 사실이 아니라는 것입니다. Makefiles는 인기 있는 것 같고 CMake 지식은 강력하지 않은 것 같습니다. 게다가 이틀간의 토론 끝에 -frecursive 플래그는 분명히 CMake와 Makefile 빌드 사이의 유일한 차이점이며 Travis CI에서는 CMake만 사용된다는 사실입니다. 핵심 기여자를 몰아낸다면 사용자를 행복하게 만드는 하나의 빌드 시스템을 강요하는 것은 이치에 맞지 않습니다.

(정규 기여자가 누구인지에 대한 나의 판단은 수락된 풀 리퀘스트의 처음 5페이지를 보고 결정하는 것입니다.)

Agree.. BTW, 재귀 플래그는 #492가 있는 기본 CMake 및 Makefile 구성에 있습니다. 따라서 Travis CI에 Makefile 빌드를 포함하기만 하면 됩니다.

PR #500은 여기에 보고된 Makefile과 CMake 빌드 시스템 간의 불일치를 완화합니다. https://github.com/Reference-LAPACK/lapack/pull/500#issuecomment -788164244 참조

안녕하세요 @ilayn입니다. Meson / CMake / Makefile 정보 감사합니다. 외부 피드백을 받고 다른 프로젝트가 수행하는 작업에 대한 정보를 얻는 것이 좋습니다. 우리는 세 가지 시스템을 모두 지원할 수 없으며 현재로서는 CMake와 Makefile을 선호하므로 Meson을 폐기할 것입니다. Meson을 절대 사용하지 않을 것이라는 말은 아니지만 현재로서는 Meson을 유지 관리할 리소스가 없습니다. 이것은 내 의견입니다. 곧 Meson을 퇴역시키는 PR을 제출할 것입니다. 줄리앙.