2009-03-16 4 views
1

프로덕션 및 디버그 빌드가있는 일반적으로 세 개의 활성 분기가있는 소스 트리에서 두 개 이상의 대상을 빌드합니다. 지금까지 필자는 특정 소스 트리의 Makefile을 포함하는 컴파일 플래그를 정의하는 공통 Makefile을 포함하는 대상을 정의하는 개인 Makefile을 사용했습니다. 이것은 효과가 있지만 도움이되지만 더 좋은 방법이 있다고 생각합니다.sqlite를 사용하여 Makefile 빌드 플래그를 관리하십시오.

sqlite3 데이터베이스를 사용하여 빌드 플래그의 전체 목록을 저장하고 구성하고 싶습니다. 컴파일시 데이터베이스는 프로젝트 버전, 플랫폼 및 dev/production을 기반으로 플래그를 생성하고 빌드를 시작하도록 생성 된 것으로 쿼리됩니다.

이 데이터베이스는 모든 개발 빌드에 대한 현재 설정을 문서화하고 추적 할 수있는 단일 장소입니다. 저장된 플래그의 기본 세트는 버전, 대상 플랫폼에서보다 세부적인 플래그에 의해 무시되고 품질 수준을 구축합니다.

이와 비슷한 것을 구현하는 과정에서 데이터베이스를 조작하고 플래그를 가져 오거나 설정하는 소수의 셸 스크립트를 만들어 내 실험실의 다른 개발자가이를 더 쉽게 채택 할 수 있도록 허용합니다.

이것은 이미 완료 되었습니까? 이런 식의 예가 있습니까?

이 문제를 해결하는 다른 방법이 있습니까?

두 가지 : * 원래 프로젝트의 Makefile을 수정할 수 없습니다. * 코드베이스의 기존 모듈에서 디버깅 수준을 활성화하는 데 필요한플래그를 구성하는 데 필요한 숫자가 수백 개가되기 때문에 automake와 같은 것을 사용하려고하면 성 가시고 어려울 수 있습니다.

답변

0

IMHO,이 데이터베이스는 과도한 사용입니다. makefile include를 사용하는 것은 이것을 처리하기위한 깔끔하고 간단한 방법입니다. 이 접근법에 대한 귀하의 우려 사항/문제점/문제점은 무엇입니까? 데이터베이스를 추가하거나 완전히 다른 빌드 시스템으로 전환하지 않고도 목표를 달성하기 위해 makefile을 재구성 할 수있는 방법이있을 수 있습니다.

1

좀 더 정교한 빌드 시스템을보고 싶습니다. ant, jam 및 기타 빌드 시스템 도구를 살펴보십시오. 당신이 기술하는 표준 GNU 방식은 ./configure (autoconf) 스크립트를 사용하는 것이지만, 다른 구성을 관리하는 것이 어렵다는 것을 알 수 있습니다.

자신의 Makefile 구성 시스템을 작성하는 것이 가능하지만 코드를 더 광범위하게 채택하려면 표준 빌드 시스템을 사용하는 것이 옳다고 생각합니다.

+0

프로젝트에 수십만 줄의 코드가 포함되어 있고 Makefile에 autoconf와 같은 것으로 변환되지 않아도 13 년의 조정이 있기 때문에 이는 원래 Makefile 소스와 별도로 수행해야합니다. –

+0

우와 ... 그 슬래시! – dicroce

+0

개미, 잼 및 autoconf가이 인스턴스에서 작동하지 않으므로 원래 Makefile을 다시 쓸 수 없습니다. –