나는 각각 자체적인 autotools 구조를 가진 많은 하위 모듈을 포함하는 프로젝트에 대한 "마스터" makefile을 유지 관리합니다. 프로젝트는 여러 구성(예: 다양한 버전의 백엔드에 대해 구축)으로 테스트되었으며 NFS 또는 크로스 컴파일러의 동일한 홈 디렉터리를 사용하여 다양한 플랫폼/아키텍처에서 구축될 수 있습니다. 이 모든 작업은 현재 소스 체크아웃(git repo clone) 작업공간을 가져오고, 소스를 현재 빌드 설정과 별도의 디렉터리에 "복제(*)"하고, 해당 소스 클론을 configure전송/ autogen실행함으로써 수행됩니다(그래서 원래 체크아웃을 오염시키지 않음). 처리된 후 자동화된 도구의 지원을 받아 최종적으로 트리에서 구축됩니다.
"(*)clone" 부분은 다양한 방법으로 구현됩니다. 예를 들어 원본 작업 공간을 "소스 복제본"에 복사 cp하거나 tar복제본에 디렉터리 구조를 만들고 기본 작업 공간의 원본 파일에 대한 상대 심볼릭 링크를 채워 넣습니다. . 여기에 용이 있어요 :)
자연 파일로 채워진 소스 클론은 자급자족하며 자동 작성 작업, 특히 dist( 및 distcheck) 작업에 잘 전달됩니다. 상대 심볼릭 링크를 "있는 그대로" 패키징하는 "symlink 클론"과 달리 make dist압축을 푼 후에는 의미가 있는 모든 곳을 가리킵니다.
심볼릭 링크의 이점은 개발자가 작업 공간에서 파일을 편집하고 git 등에 커밋할 필요 없이 한 번에 모두 다시 빌드할 수 있다는 것입니다. 즉, 개발 반복 주기를 가속화합니다(적어도 새 파일이 추가되지 않는 한 - 다시 만들기만 하면 됩니다). "make"는 이미 기존 콘텐츠를 편집했습니다). 또한 동일한 파일을 여러 번 복사하는 것보다 저장 공간과 시간 오버헤드가 훨씬 적습니다.
그래서 질문은: 원본 소스에 대한 상대 심볼릭 링크로 채워진 디렉토리를 "make dist"하는 것이 가능합니까? 어쩌면 "dist Hook"이나 타르볼 생성 방법을 무시하는 다른 방법이 있을까요? ( dist프로세스가 소스 디렉터리 심볼릭 링크를 역참조하여 개인 하위 디렉터리에 실제 파일을 생성하는 경우 허용됩니다.)
아니면 이것이 단순히 실현 가능하지 않아서 우리도 케이크를 먹을 수 없는 걸까요? :)
(참고로 문제의 "기본" Makefile은 다음 위치에 있습니다.https://github.com/42ity/FTY/)