Occa: cmake 지원

내 2센트...

내가 사용하는 많은 소프트웨어 패키지(예: VTK)는 cmake를 사용하여 구성 및 구축되지만 한 가지는 싫어합니다. 작성해야 하는 cmake 언어와 코드가 아니라 매우 모호한 makefile "구성 요소"에 대해 깊고 난독화된 디렉토리 구조로 생성합니다. 따라서 cmake가 실패하는 이유, 컴파일이 제대로 되지 않는 이유 또는 빌드를 조정하는 방법을 알아내는 것은 (적어도 저에게는) 사소한 노력이 될 수 있습니다.

구성 사양에 따라 현재 빌드 환경에 대한 메이크 파일을 생성하는 것은 일반적으로 좋은 일이지만 생성기가 무엇이든 IMHO는 읽기 가능하고 잠재적으로 조정할 수 있는 단일의 단순하고 간단한 메이크파일만 생성해야 합니다(예: 유서 깊은 'configure ' 하다). 그것은 확실히 cmake가 아닙니다!

안녕 폴,

나는 그것을 좋아하지 않지만 일단 프로젝트에 설치하면 꽤 견고합니다. 주요 이점은 통합 및 테스트입니다. 예를 들어 - 가정 - OCCA를 다소 큰 코드로 통합하기 시작하고 소스를 3rdparty라는 디렉토리에 넣고 cmake를 사용하는 경우 cmake에 새 디렉토리 add_directory(...) . 그런 다음 "상위" CMakeLists.txt의 컴파일러 및 기타 사양을 사용하여 OCCA를 자동으로 빌드합니다. 테스트 드라이버(초기)에서 OCCA에 종속성을 추가하고 나중에 더 많은 소스/기타 디렉토리에 종속성을 추가하면 간단할 것입니다.

cmake에 대한 나의 경험에 따르면 "make" 수준에서 문제가 있는 경우 일반적으로 문제는 최상위 수준에서 cmake를 너무 많이 전문화했기 때문입니다(예: 명시적 컴파일러 플래그 강제 적용...). 대부분의 문제에서 make VERBOSE=1 은 무엇이 잘못되었는지 알아내기 위해 전체 컴파일 라인(잘라내고 붙여넣을 수 있음)을 표시합니다(& 그런 다음 cmake(make가 아님)를 변경).

우리는 또한 항상 ctest를 사용합니다...

여하튼, 이것에 관하여 물을 시험하고 싶었다.

최상의,

아믹

저는 그것의 팬입니다( 아마도 너무 많이 그렇겠지만 ). 사실, CMake 지원이 제가 가장 먼저 찾았던 것입니다. 나는 모든 종속성(예: GooFit )을 extern의 git 하위 모듈로 관리하고 사용자가 하위 모듈에 대해 모르는 경우 CMake가 사용자를 위해 해당 항목을 확인하고 CMake는 모든 종속성을 결합합니다. CMake의 가장 큰 장점은 모든 작업 방식을 지원한다는 것입니다. 예를 들어 Xcode와 같은 IDE를 사용하려는 경우 CMake를 사용하는 경우에만 쉽습니다. CCache, 디버그 빌드, clang-tidy 등을 아주 쉽게 추가할 수 있습니다.

@henryiii IDE 통합이 있다면 좋은 생각 같습니다!

make 는 대부분의 장소에서 바로 찾을 수 있기 때문에 Makefile 빌드를 제거하는 것을 주저하지만 함께 CMake 지원을 추가할 수 있습니다. make 및 cmake 빌드로 테스트를 실행하도록 CI 구성을 업데이트할 수 있습니다.

시간이 되시면 핵심 CMake 파일로 PR을 할 수 있나요? 도움이 된다면 빌드 시 예상되는 모든 환경 변수/부작용을 추가할 수 있습니다.

현재 신규/예상 OCCA 사용자(HPC 프로그래머)는 OCCA 소스를 다운로드하고 make 를 입력하기만 하면 됩니다. 매우 간단합니다. 나에게 OCCA 가치 제안은 빌드 시스템이 아니라 병렬 프로그래밍 영역에서 제공하는 뛰어난 기능에 100% 기반을 두고 있습니다. 그럼에도 불구하고 OCCA가 cmake 기반 빌드로 이동하는 데 약간의 부가 가치가 있을지도 모르겠습니다.

cmake 코딩에 정통한 사람이 필수 cmake 파일을 작성하고 pull 요청을 통해 OCCA에 기여할 수 있습니까? 그것은 일부 사람들이 가지고 있는 것처럼 보이는 우려를 만족시키고 실제로 OCCA를 사용하는 데 도움이 될 수 있습니다.

cmake의 주제로 돌아가서 어쨌든 우리 중 일부에게는 "마일리지가 다를 수 있습니다." 진심으로, 만약 내가 현재의 초보자 이전 단계를 넘어선 수준에서 cmake 언어 코드를 작성/디버그/수정하는 방법을 실제로 배운다면 cmake에 대한 열정이 크게 높아질 것이라고 확신합니다. 그 동안 누군가의 잘못 작성된/오래된 CMakeLists.txt 및/또는 버그가 있거나 잘못 작성된 Find*.cmake 파일이 방금 다운로드한 일부 패키지에 대해 제대로 작동하는 문제에 직면했을 때 평가를 위한 github, 부정적인 평가의 불쾌한 감각을 가질 수 있습니다!

@pdhahn 명확히 하자면 , "컴파일할 유일한 유형 make " 빌드를 제거하지 않을 것이라고 생각합니다. 확실히 정리가 필요하지만(#149) 사용자가 설치 및 사용을 간단하게 하는 것이 여기에서 최우선 순위입니다.

CMake를 추가하면 이미 CMake를 사용하는 프로젝트에서 OCCA를 사용하는 데 도움이 되며 이 IDE 통합으로 개발자의 삶을 더 쉽게 만드는 것처럼 보입니다.

@dmed256 맞습니다 . IDE는 OCCA에 사소하지 않은 부가 가치가 될 수 있는 것처럼 들립니다!

그러나 최소한 Eclipse 및 Qt Creator와 같이 널리 사용되는 다양한 IDE를 수용해야 합니다.

CMake는 IDE뿐만 아니라 모든 종류의 도구(및 모든 종류의 도구가 지원)를 지원합니다. 모든 주요 IDE는 CMake에서 지원하거나 CMake에서 지원합니다. CLion, Qt Creator, Eclip, Xcode 등 또한 link-what-you-use, include-what-you-use, clang-tidy, ccache, 다양한 테스트 통합, 패키징 등을 지원합니다.

CMake 빌드가 잘 작동했다면 결국 Makefile이 CMake를 호출하도록 할 수 있습니다. 이전에 GooFit에서 이 작업을 수행한 적이 있습니다. makefile이 CMake를 다운로드하고 호출하도록 할 수도 있습니다. 이렇게 하면 어디에서나 최신 버전에서 작동할 수 있습니다(실행 중인 위치에 따라 linux 또는 macos 바이너리를 다운로드하는 간단한 토글만 있으면 됩니다).

앞으로 몇 주 안에 occa를 평가하고 CMake 지원을 도울 수 있기를 바랍니다.

@henryiii 그건 말이 됩니다. 우리에게는 시간이 너무 많습니다. :) 그럼에도 불구하고 CMake의 조언에 감사드립니다!

@hknibbe2 , @SFrijters , @amikstcyr , @JamesEggleton 의 모든 작업에 감사드립니다 🎉