2013-12-11 2 views
0

나는 많은 .h 및 .cpp 파일이있는 대규모 프로젝트 인 SpiderMonkey 프로젝트에서 작업 중입니다. 비록 내가 파일 또는 두 개의 파일 만 변경했음을 알고 있지만, 프로젝트를 변경할 때마다 make 명령을 실행하고 전체 프로젝트를 다시 컴파일하여 실행 파일 ./js을 얻습니다.컴파일 오버 헤드 피하기

그래서 내 질문에 모든 파일을 컴파일하지 않고 특정 파일 만 컴파일하여 새로운 실행 파일 ./js을 얻는 해결책이 있습니까?

+0

구체적인 예를 제공 할 수 있습니까? 하나도 없으면 "다른 파일이 많이 의존하는 파일을 수정하고있는 것일 수 있습니다."와 같은 모호한 대답 만 제공 할 수 있습니다. – cdleary

답변

1

make 유틸리티 대상의존성의 의미를 갖는다. 대상종속성이 변경된 경우에만 다시 작성됩니다. 그렇지 않으면 최신 것으로 간주됩니다 (간단한 설명). 어떤 오브젝트 파일이 변경되면 다음 메이크 대상 만 다시 작성하게되며, 오브젝트 파일은 소스/헤더가 변경되는 경우에만 다시됩니다

all: target target: obj1.o obj2.o $(CC) -o [email protected] $^ obj1.o: obj1.c obj1.h $(CC) -o [email protected] -c $< obj2.o: obj2.c obj2.h $(CC) -o [email protected] -c $< 

당신은 아마 프로젝트의 메이크 체크를 검토해야했다 가졌 의존성이 적절하게 정의 된 경우. 복잡한 빌드 시스템 (예 : autotools/automake)은 $ (CC) -M 또는 -MM을 사용하여 소스에 대한 종속성 목록을 작성합니다.

P. 원본/헤더 파일의 날짜가 정확하고 미래가 아닌지 확인하십시오. make은 대개 종속성 변경 사항을 올바르게 결정할 수 없으므로 대개 경고를 발행합니다. 이는 한 컴퓨터에서 편집되고 다른 컴퓨터에서 편집되는 NFS 파일에 특히 중요합니다.

0

cpp 파일은 프로젝트에 한 번만 포함되므로 h가 아닌 cpp 파일 만 변경할 수 있습니다. #pragma once 지시문을 사용할 수도 있지만 일부 컴파일러에는 컴파일 가속이 있습니다. 그리고 회사에서 IncrediBuild 도구를 사용할 수 있습니다. 그것은 IncrediBuild가있는 모든 컴퓨터에 컴파일을 배포합니다.

+3

'#pragma once '는 실제로 90 년대 이후 진실이 아니었던 도시 신화입니다. – DevSolar

3

make의 전체 아이디어는 파일 수정 날짜 및 make 사용할 수있는 종속성 정보에 의해 판단 재건이 필요 프로젝트의 부분 만 구축 다시하는 것입니다.

  1. make 사용할 수있는 종속성 정보, 즉 make 때문에 재 컴파일하지 않아도 파일을 다시 컴파일, 최적되지 않습니다 : 프로젝트가 다시 컴파일 오래 걸리면

    , 비난 할 수 있습니다 세 가지가있다 거기에 의존성이 있다고 생각합니다. 문제의 Makefile의 결함, 즉 열악한 Makefile 디자인입니다.

  2. 많은 의존성이 있습니다. 많은 헤더, 서로 포함하는 헤더 등을 포함한 구현 파일 - 헤더 파일을 편집 할 때 많은 번역 단위를 재 컴파일해야하는 작은 수정이 필요합니다. 이는 문제가되는 프로젝트의 아키텍처 적 결함 일 수 있으며 주요 리팩터링으로 만 수정할 수 있습니다.

  3. 프로젝트는 미리 컴파일 된 헤더의 사용을 전제로합니다. 이것은 대개 하나의 매우 큰 헤더 파일 (또는 많은 헤더를 포함하는 헤더)을 만들어서 미리 처리 된 형식으로 저장합니다.이 을 사전 처리 한 헤더를 포함하면 매우 저렴합니다. 그러나 설정이 실제로 이 아니면과 같은 이런 종류의 전처리 (그러나 모 놀리 식 헤더를 그대로 포함)를 수행하면 컴파일 시간이 급격히 빨라질 수 있습니다. 이것은 당신의 설정의 결함 일 것입니다; 사용 가능한 문서와 설정을 확인하십시오. 어느

당신의 특정 문제에 대한 책임? 나는 정말로 말할 수 없다. (나는 Spidermonkey에 대해 처음 알지 못합니다.)

2

SpiderMonkey는 이미 잘 짜여있는 프로젝트가 있다고 가정합니다. makefile은 기본적으로 소리가 나며 가짜 종속 관계가 거의 없습니다. 그게 사실이 아니라면 SpiderMonkey 커뮤니티에 특정 파일 수정 사항을 수정하여 다른 파일을 다시 빌드하는 이유를 묻거나 코드 수준에서 작업하여 종속 파일의 용도를 확인하십시오 (아마도 #include을 선택적으로 제거하여 무슨 일이 일어나는지 보려고).

그러나 많은 다른 번역 단위에서 (직접 또는 간접적으로) 포함 된 헤더 파일과 같이 많은 파일이 수정 될 수도 있습니다. 그렇다면 코드를 재구성하지 않고도 할 수있는 일은 상대적으로 적습니다. 라인 밖 함수 정의, forward-declaration 헤더 (ala the Standard 's <iosfwd>), pImpl 관용구, 가상 인터페이스 사용, 완전히 템플릿이 만족스럽지 않은 기술 (클라이언트 코드에 정의가 포함되어야하므로 작업).