inotify와 같은 메커니즘을 기반으로 빌드 도구가 있습니까

비교적 오래된 프로젝트의 경우 보통 make을 사용하고 있으며 변경된 사항이없는 경우에도 프로젝트를 빌드하는 데 수십 초가 소요됩니다. 특히 make -C의 많은 실행으로 새로운 프로세스 오버 헤드가 발생합니다.inotify와 같은 메커니즘을 기반으로 빌드 도구가 있습니까

이 문제에 대한 분명한 해결책은 inotify과 같은 OS 기능과 같은 빌드 도구입니다. 그것은 특정 파일이 변경되었을 때를 보게 될 것이고, 그리스트에 기초하여이 파일 만 컴파일 할 것입니다.

거기에 그런 기계가 있습니까? 오픈 소스 프로젝트의 보너스 포인트.

출처

2011-02-24 Elazar Leibovich

당신은 Tup 같은 의미 :

홈 페이지에서

"대가리는 파일 기반 빌드 시스템 - 그것은 파일의 변화와 방향성 비순환 그래프 (DAG), 다음 프로세스의 목록을 입력 DAG는 종속 파일을 업데이트하는 데 필요한 적절한 명령을 실행합니다 .DAG는 SQLite 데이터베이스에 저장됩니다. 기본적으로 파일 변경 목록은 파일 시스템을 검색하여 생성됩니다. 또는 포함 된 파일을 실행하여 목록을 제공 할 수 있습니다 파일 모니터 데몬. "

출처

2011-03-02 11:26:10 Happi

사실 나는 그것을 들었다. 그러나 그것은 내 마음에 나타 났지 않았다. –

파일을 편집하고 불완전한 버전을 저장하면 어떻게 될지 궁금합니다. 모든 저장이'Tup'을 컴파일하도록 유도해야합니다. 맞습니까? –

Tup은 요청할 때만 컴파일하지만 항상 파일 시스템에서 변경 사항을 감시합니다. –

설명하는 변경 의존성은 이미 Make의 일부이지만 Make는 비효율적 인 방식으로 사용할 수있을만큼 충분히 융통성이 있습니다. 느려짐이 정말로 재귀 (make -C 명령)에 의해 발생 된 경우 - 아마도 그렇습니다 - 재귀를 줄여야합니다. (당신은 make -C 실행 여부를 결정하기 위해 자신의 조건부 논리에 넣어 시도 할 수 있지만, 매우 우아 솔루션이 될 것입니다.)

은 대략 말하기, 당신의 메이크 파일이

# main makefile 

foo: 
    make -C bar baz

이

처럼 보이는 경우

# makefile in bar/ 

baz: quartz 
    do something

이로 변경할 수 있습니다

# main makefile 

foo: bar/quartz 
    cd bar && do something

많은 세부 사항이 있지만 지금은 bar/quartz이 변경되지 않은 경우 foo 규칙이 실행되지 않습니다.

출처

2011-02-25 07:49:28 Beta

:이 같은 다른 파일을 볼 수 있습니다

> make watch

이것은 타협입니다. 당신의 접근 방식을 따라 가면 나는 더 빠르게 부풀어 오른 메이크 파일을 얻을 수있다. 나는 내 케이크를 가지고 그것을 먹고 싶다. 그리고 이것은 inotify 마법으로 가능합니다. 변경 날짜가 아닌 파일은 절대 수정하지 마십시오. –

inotify-tools을 설치하고 bash의 몇 줄을 작성하여 특정 디렉토리가 업데이트 될 때 make을 호출하십시오.

부수적 인 문제로 재귀 적으로 크기를 조정하면 오류가 발생하기 쉽습니다. non-recursive make을 선호하십시오.

출처

2011-02-25 12:10:47

어? make를 호출하면 프로젝트의 모든 파일에 접근합니다. 나는 그것을하고 싶지 않다! 요점은 수정 시간을 얻기 위해 모든 파일을 절대 만지지 못하게하는 것입니다. –

@Elazar Leibovich : make는 파일을 건드리지 않습니다. stat의 소스 파일은 대상을 다시 빌드해야하는지 확인합니다. –

Maxim, 나는 당신에 관해 무엇인지 모르지만, 나는 그것을 만지는 파일을'stat'라고 생각합니다. 그리고 매번 100,000 개의 파일을 하나씩 만들 필요가있는 경우 시간이 오래 걸릴 수 있습니다 (99.9 %의 파일이 흥미 롭지 않습니다. 이미 libsomething.so에 파일을 컴파일 했으므로 필요한 모든 것입니다).). –

오랫동안 걸리는 파일이 stat()인지 궁금합니다. 이 같은

# call-counts.stp 

global calls, times 

probe kernel.function(@1) { 
    times[probefunc()] = gettimeofday_ns() 
} 

probe kernel.function(@1).return { 
    now = gettimeofday_ns() 
    delta = now - times[probefunc()] 
    calls[probefunc()] <<< delta 
}

그리고 그것을 사용 :

$ stap -c "make -rC ~/src/prj -j8 -k" ~/tmp/count-calls.stp sys_newstat 
make: Entering directory `/home/user/src/prj' 
make: Nothing to be done for `all'. 
make: Leaving directory `/home/user/src/prj' 
calls["sys_newstat"] @count=8318 @min=684 @max=910667 @sum=26952500 @avg=3240

4593을 가지고에 내가 그것을 실행 프로젝트 여기를 확인하려면 내가 stat() 파일에 걸리는 시간을 측정하기 위해 쓴 작은 systemtap 스크립트입니다 소스 파일이며 해당 .d 파일과 함께 모든 파일을 stat하기 위해 make에 ~ 27msec (26952500nsec 이상)가 걸립니다. 나는 비 재귀 적 make를 사용하고있다.당신은 OSX를 사용하는 경우

출처

2011-03-02 12:05:04

당신이 맞을 수도 있고 조기 최적화 일 수도 있습니다 . BTW는 캐시가 덥습니까? 100,000의 프로젝트를보고 통계 시간이 비례하는지 보는 것은 흥미로운 일입니다. 비 재귀 적 make는 정말 큰 프로젝트를위한 옵션이 아닌 경우가 많습니다. +1 프로필 작성 시간을내어. –

파일 시스템 캐시가 뜨겁습니다 (내가 컴파일 한 워크 스테이션에 12Gb RAM이 있음). 그리고 그것은 로컬 ext3 파일 시스템에 있습니다. NFS를 사용하여 빌드 할 때'stat()'파일보다 오랜 시간이 걸립니다. –

'tup '의 저자는 100k 파일을 가진 변경되지 않은 프로젝트를 만들기 위해 몇 초를 측정합니다. http://gittup.org/tup/make_vs_tup.html –

, 당신은 사용할 수 있습니다 fswatch

https://github.com/alandipert/fswatch

은 어떤

fswatch -o anyFile | xargs -n1 -I{} make

을 감지하면 make를 실행 한 후 파일의 변경 사항에 fswatch를 사용하는 방법 다음과 같이 makefile 내부에서 fswatch를 실행할 수 있습니다.

watch: $(FILE) 
    fswatch -o $^ | xargs -n1 -I{} make

은 (물론, $ (FILE)는 메이크 내부에 정의되어 있습니다.) 메이크업이 지금과 같이 파일의 변화를 볼 수 있습니다 :

> make watch anotherFile

출처

2014-06-23 23:44:37 d13

inotify와 같은 메커니즘을 기반으로 빌드 도구가 있습니까

답변

관련 문제