내 (주로 C ++) 개발에서 오랫동안 소스 외부 빌드를 사용했습니다. 즉, 내 소스는 보통에 앉아 /project/src디렉토리와는 라이브 구축 /project/build/bin/release, /project/build/bin/debug디렉토리. 소스 파일을 중간 파일에서 깨끗하게 유지하고 모든 바이너리에 대해 하나의 위치가 있으며 패키징이 쉽고 청소가 쉽고 버전 관리가 더 쉬워서이 작업을 수행했습니다. (아무것도 놓쳤습니까?)
소스 내 빌드를 사용하는 (대형) 프로젝트를 상속하고 있습니다. 이 유형의 구조에 대한 동기는 무엇이며 장점은 무엇입니까? (엔지니어링 수준의 이유와 개인적인 선호 유형의 이유에 가장 관심이 있습니다.)
나는 Lakos의 "Large-Scale C ++ 소프트웨어 디자인"이 그에 무게를두기를 바라고 있었지만, 그렇지 않다면 놓쳤다.
2
사과. “원본 빌드에서 'x'를 개선하십시오 '또는'y '를 보장하는 데 도움이됩니다'또는 '자동 테스트가'z '가 될 수 있습니다'를 찾고 있습니다. 비난하지 않습니다. 나는 여기서 의견의 전쟁에 참여하고 싶지 않습니다!
—
DiB
인소 스 빌드는 전임자의 게으름으로 인한 저주입니다. 그것들은 모든 것 (소스 제어, 교차 작성, 텍스트 찾기 등)에 대해 끔찍하지만 베어 메이크 파일을 사용하여 만들기가 매우 쉽습니다. 죄송합니다. 그러나 객관적인 것.
"소스 내"빌드 란 정확히 무엇을 의미합니까? 같은
—
Doc Brown
/project/src/bin/release또는 실제로 모든 중간 및 출력 파일 /project/src? 후자는 소스 파일이 12 개 이상인 경우 실제로 혼란 스러울 수 있습니다.
@Tibo, makefile을 사용하면 매우 쉬울뿐만 아니라 대부분의 IDE에서도 기본값으로 보입니다 (최소 몇 년 전에 확인했을 때).
—
Bart van Ingen Schenau
트윗 담아 가기 이 경우 어디에 어떤 IDE를 사용하고 있습니까? Qt는이 작업을 수행하지 않습니다. 실제로 소스에서 가능한 멀리 빌드를 멀리하는 것처럼 보이지만 Eclipse는이 작업을 수행하지 않습니다.
—
whn
main.cpp 처음에는 프로젝트의 최상위 레벨에 있지만 해당 최상위 레벨의 소스와 별도로 별도의 cmake 빌드 디렉토리를 작성합니다. MSVS도 이와 관련하여 Clion과 유사하다고 생각합니다.