1
배경
저는 현재 리팩토링 중입니다. 문제 중 하나는 포함 제품에서 사용되는 일반적인 경로에 대한 문자열 리터럴 (300 개 + 인스턴스)의 대규모 남용 사방에 (즉, /opt/dev에 대한 참조 및이 위치의 하위 경로)입니다 :큰 C/C++ 프로젝트의 컴파일시 GNU m4를 사용하십시오.
- C/C++ 소스 및 헤더 파일.
- python 스크립트.
- bash 스크립트.
- systemd 스크립트.
- 바이너리 이미지 (드라이버).
목표
우리의 코드가 분기되는 경우, 그래서 우리는 "한 번 쓰기 어디서나 사용"할 수 있습니다 나는 일반적인 매크로의 집합을 가진 파일을 정의하기 위해 GNU m4을 사용하고 싶습니다(일반적으로 신제품의 경우) 중복 된 문자열 리터럴을 찾아 며칠 동안 디버깅하는 대신 해당 파일의 매크로를 변경할 수 있습니다. 이것은 빌드 출력 경로에 소스 트리 복사본을 만들고 스크립트에서 직접 M4를 실행하기 때문에 스크립트와 같은 간단한 작업을 처리하기에 충분합니다.
문제
지금까지 유일한 단점은 나는 단지 컴파일 시간에 M4 매크로 확장/대체를 실행하려는 때문에이, C/C++ 프로젝트에 대한 엄청난 노력이 될 것처럼 보이는 것입니다. 즉, git에서 체크 아웃 한 소스 파일을 수정하지 않으려면 빌드 스크립트 (많은 Makefile)를 수정하여 원래 소스 파일 자체가 아닌 임시 코드 복사본을 만들어야합니다. 그렇지 않으면 버전 제어 소스에서 직접 M4을 실행하면 로컬 작업 복사본이 변경되고 개발자는이 M4 평가 코드 복사본을 버전 제어에 커밋하여 M4 노력을 깨뜨릴 수 있습니다.
질문
가 일부 외부 도구 또는 GCC 자체의 일부 기능을 통해 중, gcc이 컴파일시 m4 매크로/확장을 평가하도록 지시 할 수 있습니까? 그렇지 않다면, 내 빌드 스크립트는 M4 매크로를 지원하기 위해 대규모 점검이 필요할 것입니다.
C 및/또는 C++ 코드의'project-config.h' 헤더를 생성하려면'm4 '를 사용하십시오. 매크로 중 하나를 사용해야하는 모든 파일에서 해당 헤더를 사용하십시오. 프로그래머가 사용해야하는 것을 알고 있는지 확인하십시오. 체크인 전 또는 정기적으로 코드 검사를 시행 할 가능성이 있습니까? 해당 헤더가 변경되면 다시 컴파일하십시오. 불필요하게 변경하지 마십시오. –
@JonathanLeffler 한숨 쉬우면서 우아하고 단순합니다. 어떻게 내가 이것을 간과하는지 모르겠다. 이것을 당신이 대답으로 바꾸면 받아 들일 것입니다. – DevNull