2009-07-09 3 views
10

Windows 및 Linux (RHEL) 플랫폼을 대상으로하는 C++ 프로젝트에 참여했습니다. 지금까지 Visual Studio 2008에서 개발이 완료되었습니다. Linux 컴파일시에는 VS 솔루션/perojects 파일을 읽고 Linux 컴퓨터에서 원격 컴파일 한 타사 Visual Studio 플러그인을 사용했습니다.Windows 및 Linux 모두에서 C++ 빌드

최근 결정은 제 3 자 플러그인을 포기하는 것이 었습니다.

이제 내 큰 관심사는 빌드 시스템입니다. 크로스 플랫폼 빌드 도구를 둘러 보았습니다. 이 방법으로 두 세트의 빌드 파일 (예 : vcproj/Windows 용 솔루션 및 Linux 용 파일)을 유지 관리 할 필요가 없습니다.

다음 후보가 있습니다. a. Scons b. cmake

크로스 플랫폼 개발 도구에 대해 어떻게 생각하십니까?

나를 괴롭히는 또 다른 요점은 Visual Studio (+ Visual Assist)가 vcproj 파일없이 많은 기능을 잃어 버리게된다는 것입니다. 도구로 문제를 어떻게 처리 할 수 ​​있습니까?

감사 디마

PS 1 :이 (가) 파이썬을 사용 및 cmake가 타당성 언어 (나는 그것이 승자 기능은 대한 아니라고 이해하고 사용하는 반면 따라서는, 유연 것을 내가 SCons는에 대해 같은입니다 빌드 시스템) (b) 자체 포함 (cmake와 마찬가지로 Linux에서 메이크 파일을 생성 할 필요가 없음).

왜 Scons가 좋지 않습니까? 왜 당신의 프로젝트에서 결정은 cmake를 사용하는 것이 었나요?

+0

아웃 시스템은 최대 두 개의 플랫폼을 대상으로하므로 cmake가 "over kill"이 아닌지 궁금합니다. 내가 우려하는 또 다른 점은 빌드가 재현 가능해야한다는 것입니다 (처음부터 두 번 빌드하면 * SAME * 제품이 정확하게 제공됩니다). 물론 네이티브 빌드 시스템을 사용하면 대상에 가깝습니다. cmake가 그것을 깨뜨리고 컴파일하는 사람의 설정에 따라 vcproj/makefiles를 생성 할 수 있습니까 (예 : Windows의 경우 개발자가 개인 컴퓨터에서 컴파일합니까?). – dimba

+0

Visual Assist에 대한 메모 만 있습니다. 빈 솔루션을 사용할 때 디렉토리에서 파일을로드하는 옵션이 있습니다. –

답변

10

CMake를 사용하면 Visual Studio 솔루션과 프로젝트 파일을 계속 사용할 수 있습니다. Cmake는 소스 코드 자체를 빌드하지 않고 빌드 파일을 생성합니다. Linux의 경우 Code :: Blocks, KDevelop 또는 일반 메이크 파일 또는 다른 더 밀교적인 선택이 될 수 있습니다. Windows의 경우 Visual Studio 프로젝트 파일 일 수도 있고 MacOS의 다른 파일 일 수도 있습니다. 그래서 Visual Studio 솔루션과 프로젝트는 CMakeLists.txt에서 생성됩니다. 이것은 큰 프로젝트에서 잘 작동합니다. 예 : 현재 Ogre3d는 모든 플랫폼 (Windows, Linux, MacOS 및 IPhone)에서 CMake를 사용하며 실제로 잘 작동합니다.

나는 scons에 관해서 많이 모른다. 그러나 나는 단지 하나의 라이브러리를 만들고 리눅스에서만 사용했다. 그래서 나는 공정한 땅에서이 둘을 비교할 수 없다. 그러나 우리의 멀티 플랫폼 프로젝트의 경우 CMake는 충분히 강력합니다.

+0

CMake는 꽤 좋습니다 - VS 프로젝트 파일을 다시 생성 *하므로 "프로젝트 파일을 계속 사용할 수 있습니다"라고 부분적으로 오해의 소지가 있습니다. Windows를 포함하는 많은 OS (Windows 만이 "어려운"것입니다 ...) 사이의 호환성이 필요하고 Visual Studio를 사용하고자하는 경우 유일한 솔루션으로 C++ 프로젝트에서이 솔루션을 적극 권장합니다. – Arafangion

+0

내 답변의 나머지 부분이 문제가 해결되기를 바랍니다. :) 당신 말이 맞아요. 현재 가지고있는 솔루션 파일은 생성 된 솔루션 파일로 대체됩니다. CMake는 솔루션 자체에 몇 가지 프로젝트를 추가 할 것입니다 (ALL_PROJECTS, INSTALL, ZERO_CHECK). 처음에는 어색함을 느낄 수 있습니다. 특히 INSTALL. 솔루션의 모든 부분을 빌드하고 생성 된 DLL, EXE 및 CMakeFiles.txt에 지정된 다른 파일을 대상 디렉토리에 복사하여 NSIS 또는 다른 패키지 도구를 실행하여 설치 패키지를 만들 수 있습니다. – haffax

+0

SCons *가 VS 프로젝트 파일을 생성 할 수 있다는 점은 주목할 가치가 있습니다. –

3

필자는 전에 Scons를 사용하지 않았으므로 어떻게 작동하는지 말할 수는 없지만 CMake는 꽤 잘 작동합니다.

대상 플랫폼에 필요한 빌드 파일을 생성하여 작동합니다.

VC++를 대상으로 사용하는 경우 VS에서 솔루션 및 프로젝트 파일을 생성하므로 원시 VS 프로젝트 인 것처럼 나타납니다. 유일한 차이점은 VS를 통해 직접 프로젝트 또는 솔루션을 편집하면 프로젝트/솔루션 파일을 덮어 쓰므로 다음에 CMake를 실행할 때 변경 사항이 지워지게된다는 것입니다.

그래서 CMake 파일을 변경해야합니다.

0

이전에는 많이 했었습니다. 우리가 한 일은 gnu를 사용하여 거의 모든 시간에 windows를 포함합니다.

Linux의 경우 gnu make를 원하면 Windows에서 프로젝트 파일을 사용할 수 있습니다.

대상 파일이 (경로명 문제, \ vs/etc)과 다를 수 있기 때문에 크로스 플랫폼 makefile을 작성하는 좋은 방법은 없습니다. 일반적으로 다양한 플랫폼에 걸쳐 코드를 조정하여 미묘한 차이를 고려해야하므로 파일을 만들거나 다른 플랫폼을 확인하는 것이 어쨌든 발생해야합니다.

많은 OS 프로젝트는 zlib와 같이 Makefile.win, Makefile.linux 등과 같이 다른 플랫폼에서 Makefile을 유지 관리합니다.

+0

CMake 같은 것을 사용하는 것에 비해 장점은 무엇입니까? CMake를 사용하면 한 세트의 빌드 파일을 관리해야하며 여전히 좋아하는 IDE를 최대한 활용하여 완전히 활용할 수 있습니다. – haffax

+0

하나의 장점은 모든 OS의 모든 단점을 해결하는 단일 크로스 플랫폼 스크립트를 파악하는 것보다 각 시스템에 표준 스크립트를 사용하는 것이 더 쉬울 수 있다는 것입니다. 그래도 여전히 많은 복제 노력이 필요합니다 ... – Arafangion

2

우리는 많은 수의 핵심 라이브러리와 해당 라이브러리를 기반으로하는 응용 프로그램을 보유하고 있습니다. 우리는 각 프로젝트 나 라이브러리에 대해 Visual Studio 솔루션을 사용하여 Linux 및 Windows에서 Makefile 기반 빌드 시스템을 유지 관리합니다.

우리가 필요로하는대로 잘 작동한다는 것을 알았습니다. 각 라이브러리 또는 앱은 크로스 컴파일을 염두에두고 (예 : 특정 플랫폼 API 사용 안함) Linux 또는 Windows에서 개발되었습니다. 우리는 파일 경로, 쓰레드 등과 같은 것들을 위해 부스트를 사용합니다. 특정한 경우 템플릿/# 정의를 사용하여 플랫폼 별 솔루션 (예 : 이벤트)을 선택합니다. 준비가되면 다른 시스템 (Linux 또는 Windows)으로 이동하고, 다시 컴파일하고, 경고/오류를 수정하고 테스트합니다.

두 플랫폼에서 교차 컴파일 할 수있는 도구를 찾는 데 시간을 소비하는 대신 각 플랫폼에 가장 적합한 시스템을 사용하고 특정 문제를 수정하고 소프트웨어를 개선하는 데 시간을 소비합니다.

우리는 Windows atm에서만 GUI 응용 프로그램을 가지고 있습니다. 그래서 크로스 컴파일 할 GUI가 없습니다. Windows와 Linux가 공유하는 대부분의 개발은 서버 측 네트워킹 (소켓, TCP/IP, UDP ...) 및 Linux의 클라이언트 측 도구와 Windows의 GUI 응용 프로그램입니다.

소스 코드 버전 관리에 perforce를 사용하면 Linux Makefile 시스템이 Windows VS에 필요한 것보다 훨씬 더 유연하다는 것을 알 수 있습니다. 특히 우리가 공통 디렉토리를 가리킬 필요가있는 여러 작업 공간 (소스 코드 버전의 뷰)을 사용하는 경우. Linux에서는 환경 변수를 업데이트하기 위해 스크립트를 자동으로 실행할 수 있습니다. Visual Studio에서 환경 변수를 참조하는 것은보기/분기간에 자동으로 업데이트하기가 쉽지 않기 때문에 매우 유연하지 않습니다.

동기화 질문 재 :

난 당신이 두 개의 빌드 시스템은 리눅스와 윈도우 사이에 동기화 얻을 있는지 확인하는 방법을 요구하는 가정합니다. 우리는 실제로 Linux의 Hudson과 Windows의 CruiseControl을 사용하고 있습니다. (저는 크루즈 컨트롤이있는 Windows가 처음이었습니다. Hudson이 Linux 버전을 설치했을 때 환경이 좋았으므로 이제는 환경이 더 좋았습니다). 우리 시스템은 항상 실행되고 있습니다. 무언가가 업데이트되면 테스트되고 릴리스됩니다 (Windows 또는 Linux 버전). 그렇게하지 않으면 즉시 알 수 있습니다. 테스트하는 동안 모든 최신 기능이 완벽하게 작동하는지 확인합니다. 나는 그것이다고 생각한다. 어둠의 마법은 포함되어 있지 않다.

오, 당신은 빌드 스크립트를 의미합니다 ... 각 응용 프로그램은 자체 솔루션을 가지고 있습니다. 솔루션에서 당신은 의존성을 설정합니다. 리눅스 쪽에서는 각 프로젝트에 대한 메이크 파일과 모든 종속성을 처리하는 프로젝트 디렉토리에 빌드 스크립트가 있습니다. 이것은 주로 코어 라이브러리를 빌드하고 주어진 응용 프로그램에 필요한 특정 프레임 워크를 몇 개 만드는 것을 의미합니다. 각 플랫폼마다 다르다는 것을 알 수 있듯이, 디렉토리로 변경하고 필수 프로젝트를 만드는 스크립트를 빌드하는 라인을 추가하는 것은 쉽습니다.

일관된 방식으로 프로젝트를 설정하는 데 도움이됩니다.

Windows에서 프로젝트를 열고 종속성 프로젝트를 추가하십시오. 다시 말하면 마법과 관련이 없습니다.이러한 종류의 작업은 개발과 관련이 있습니다. 예를 들어 프로젝트에 새로운 기능을 추가하고 프레임 워크와 헤더를 연결해야하는 경우를들 수 있습니다. 따라서 필자가 생각하기에 기능을 구현할 때 개발자가 수행하는 작업의 일부이기 때문에 이러한 작업을 자동화 할 이유가 없습니다.

+0

다양한 빌드 스크립트가 동기화되지 않는 방법을 말하면 제가 투표 할 것입니다. (지속적인 통합 서버는 편도 일 것입니다) – Arafangion

+0

쉽게 upvotes 가치가 있습니다! – Arafangion

1

KDE 개발자가 CMake over SCons를 선택하기로 한 결정에 대한 설명은 article입니다. 그러나 나는이 기사가 거의 3 살이라는 점을 지적 했으므로 scons가 개선되었을 것입니다.

Here은 SCons와 다른 건축 도구를 비교 한 것입니다.

+0

또한 SCons는보다 일반적인 반면 CMake는 특정 언어에 편향되어 있습니다. – Arafangion

3

또 다른 옵션은 premake입니다. 그것은 정의 파일로부터 솔루션을 생성한다는 점에서 cmake와 같습니다. 오픈 소스이며 최신 버전은 Lua 스크립팅을 사용하여 매우 맞춤 설정할 수 있습니다. 우리는 너무 많은 문제없이 사용자 정의 플랫폼 지원을 추가 할 수있었습니다. 상황에 따라 Visual Studio 및 GNU makefile 표준을 모두 지원합니다.

Premake 4.0 Homepage

CruiseControl을 연속 통합을위한 좋은 선택을 참조하십시오. Mono를 사용하여 Linux에서 성공을 거두었습니다.

+1

나는 몇몇 주요 프로젝트에 사용되는 CMake와 SCons에 비해 인기/커뮤니티/지원이 부족하기 때문에 premake를 추천하지 않습니다. –

관련 문제