플랫폼 특정 프로젝트 파일을 사용하거나 프로젝트 생성기를 사용하여 자동화를 빌드 하시겠습니까?

Question

그들

하나는 CMake입니다 비주얼 스튜디오 sln, vcproj, vcxproj 파일 또는 OS X를 아래 XCodexcodeproj 프로젝트와 같은 플랫폼 특정 프로젝트 파일을 생성 할 수있는 몇 가지 빌드 시스템이있다 그러나 나는 발견 그 지원 이것은 매우 제한적이며, 버그이며 VS (2010과 같은) 최신 버전으로 업데이트하기가 매우 어렵습니다.

또한, 적어도 CMake, 비주얼 스튜디오에 대한 속성 페이지에 대한 지원 누락이 관리하고 변화 프로젝트의 다양한 구성하기 어렵게됩니다 - 모든 프로젝트에 대한 코드 분석을 활성화/비활성화처럼.

위의 발행하면 해결 방법은 수동으로 각 플랫폼에 프로젝트 파일을 생성하는 것입니다 - 내 경우에는 두가 있지만, 더와 숫자가 너무 커서 안됩니다.

일반적인 빌드 자동화 스크립트에 특정 빌드 명령 플랫폼을 호출하는 것은 매우 쉽습니다. 예를 들어, 자신의 빌드 파트를 사용하지 않고이 프로젝트를 자동화하기 위해 waf (Python)을 사용했습니다./수리 프로젝트 발전기를 유지하기 위해 노력하고 또는 분리 된 프로젝트 파일을 유지 :

는 당신이 선택할 것입니다 무슨보고 싶은

?

Answer 1

우리가하는 일은 최선의 방법은 아니지만 실제로 잘 작동하며 유지 관리하기가 너무 어렵지 않다는 사실을 발견했습니다.

우리의 주요 플랫폼은 창, 거의 모든 개발은 VS IDE에서 수행된다. 다른 플랫폼 (현재는 일부 리눅스에만 해당)에서는 CMake를 독점적으로 사용합니다. 기본적으로 우리는 "프로젝트 생성기를 수리/유지"하는 방법을 선택했지만 Visual Studio 프로젝트 파일을 시작점으로 사용했습니다.

• 우리 모두 빌드 옵션은 속성 시트에서 설정
• 프로젝트의 모든 파일에 대한 컨테이너 비주얼 스튜디오 프로젝트 파일을 사용하여, 각 프로젝트는 표준 세트가 결국 몇 가지 여분의 시트는 특정에 끌어 라이브러리 등
• 하나의 배치에서 속성 시트를 추가/제거 할 수있는 간단한 스크립트가 있습니다.
• 모든 속성 시트에는 cmake 대응 항목이 있습니다. 두 디렉토리 모두 같은 디렉토리에 보관되며, 업데이트하면 항상 업데이트됩니다. 이것은 스크립트로는 끝나지 않으며, 나는 이것이 '복잡한'부분이라는 것을 인정한다. 매크로를 많이 사용하지만 항상 한 플랫폼에서만 사용할 수있는 옵션이 있지만 다른 플랫폼에서는 사용할 수있는 옵션이있다.
• 우리는 vcproj 파일을 cmake 파일로 변환하는 스크립트를 가지고 있습니다. 기본적으로 해당 cmake 속성 시트를 포함하고 vcproj에있는 모든 소스 파일을 포함하는 cmake 파일을 만듭니다.
• 마지막으로 우리가 사용하는 모든 플랫폼에서 실행되는 서버를 구축 썼다. 그것은 msbuild 또는 cmake를 사용하여 빌드되며,이 시스템이 작동하도록하는 열쇠입니다. 우리가 변경 한 각각의 변경 사항은 적어도 두 대의 시스템에서 빌드 + 테스트를 트리거하므로 모든 것이 원활 할 경우 immedeatly를 알 수 있습니다.

최근에 VS2010을 사용하기 시작했습니다. 마이그레이션에는 약 1 일 걸렸습니다. 먼저 VS에서 모든 프로젝트와 속성 시트를 변환 한 다음 스크립트에 조정을 적용하여 새로운 xml 파일 형식을 처리했습니다.

편집

미안하지만, 스크립트, 회사 정책을 게시 이해를 바랍니다 수 없습니다. 약간의 의사 코드는 문제가되지 않습니다. VS2008 프로젝트 파일의 속성 시트를 추가/제거하는 것은 이렇게되면 다음 CMakeLists를 들어

foreach proj in projectfiles //list of vcproj files 
    foreach config in configuration //configurations eg 'Debug|Win32, Debug|x64' 
    f = OpenFile(proj); 
     //find start of Configuration element, then get what's after InheritedPropertySheets= 
    propsheets = GetPropSheetsForConfig(f, config); 
    propsheets = DoAction(action, args, propsheets); //action is add/remove/.. with argument args 
    SetPropSheetsForConfig(f, propsheets); 

스크립트는 '포함 (..)'라인에서 작동 제외하고는이, 거의 동일 파일. vcproj에서 CMakeLists에

Convertig :

f = OpenFile(proj); 
projname = GetProjectName(f); 
sources = GetSourceFiles(f); //all File/RelativePath elements under Filter 'Source Files' 
sources = CheckFilter(sources); //apply rules to include/exclude platform specific files 
propsheets[] = GetPropSheetsForConfig(f, configs[]); 

fout = CreateCMakeFromProj(proj); //CMakeLists.txt in corresponding directory 
WriteCMakeHeader(fout, projname); 
WriteCMakeSources(sources); 
WriteCMakeIncludes(configs[], propsheets[]); //write includes, conditional on CMAKE_BUILD_TYPE 

빌드 서버는 이제 매우 고급 소재이지만, 처음에 그것은 단지 TCP 리스너이었다

• 기다리고 연결
• 은 선택 얻을 인수 (속성 시트/작업)
• 저장소의 업데이트
• 결국
• 시작 명령 행 전체 '오류'를 포함하는 라인을위한 파일에
• 구문 분석 파일을 + 테스트, 캡처 출력을 재 지정된 인수와 속성 시트의 배치 스크립트를 실행 메일이 결과

Answer 2

내 모든 프로젝트는 크로스 플랫폼이며, 제가 선호하는 것은 해결 방법입니다. Scons가 교차 플랫폼 프로젝트를 유지하는 것은 거의 또는 전혀 효과가 없습니다. 하나의 잘 정의 된 환경은 대부분의 프로젝트에서 작동하며 각 프로젝트/하위 프로젝트에 대한 템플릿을 사용합니다. 또한 빌드 프로세스를 완벽하게 제어 할 수 있으므로 도메인 특정 언어를 사용하고 코드 생성을 수행하며 소스 제어를 손쉽게 관리 할 수 ​​있습니다.

Answer 3

우리는 우리의 플랫폼 프로젝트 boost.build을 사용), 당신은 파이썬을 알고

학습 SCons는, 당신은이 개 위대한 기술하지 하나를 disconvering하는 파이썬을 알지 못하고 죽은 간단하다. C++ 라이브러리 프로젝트에서 잘 작동합니다. 우리는 하나의 스크립트 만 유지하면되고 Boost와 잘 통합되기 때문에 좋아합니다. 잘합니다.

매우 가파른 학습 곡선을 가지며 문서가 매우 열악합니다. 그러나 우리가 작업하고있는 두 플랫폼 인 Windows와 Linux에서도 잘 작동합니다.