Czy istnieje narzędzie do kompilacji oparte na mechanizmie inotify?

W stosunkowo dużych projektach, które używają zwykłego starego make, nawet budowanie projektu, gdy nic się nie zmieniło, zajmuje kilka dziesiątek sekund. Zwłaszcza z wieloma wykonaniami make -C, które mają nowy narzut procesu.Czy istnieje narzędzie do kompilacji oparte na mechanizmie inotify?

Oczywistym rozwiązaniem tego problemu jest narzędzie do budowania oparte na funkcji podobnej do systemu operacyjnego w wersji inotify. Wyszuka, kiedy dany plik zostanie zmieniony i na podstawie tej listy skompiluje ten plik sam.

Czy istnieje taka maszyna? Punkty premiowe za projekty open source.

Źródło

2011-02-24 Elazar Leibovich

To znaczy, jak Tup:

Od strony głównej:

„Tup jest system budowania oparty na plikach - to wprowadza listę zmian w plikach i skierowany graf acykliczny (DAG), następnie przetwarza DAG, aby wykonać odpowiednie polecenia wymagane do aktualizacji plików zależnych DAG jest przechowywany w bazie danych SQLite Domyślnie lista zmian plików jest generowana przez skanowanie systemu plików.Alternatywnie, lista może być dostarczona z góry, uruchamiając dołączone demon monitora plików. "

Źródło

2011-03-02 11:26:10 Happi

Właściwie to słyszałem o tym, ale nie wyszło mi to na myśl. –

Zastanawiam się, co się dzieje, gdy edytujesz plik i zapisujesz jego niekompletne wersje. Musi być tak, że każde zapisanie wyzwala "Tup", aby go skompilować, prawda? –

Tup kompiluje się tylko, gdy pytasz, ale zawsze obserwuje system plików w poszukiwaniu zmian. –

Opisana zależność od zmiany jest już częścią Make, ale Make jest na tyle elastyczna, że można jej używać w sposób nieefektywny. Jeśli powolne spowolnienie jest spowodowane poleceniami rekursji (make -C) - co prawdopodobnie jest - powinieneś zmniejszyć rekursję. (Można spróbować umieścić w swojej własnej logiki warunkowej, aby zdecydować, czy wykonać make -C, ale byłoby to bardzo nieeleganckie rozwiązanie).

Z grubsza rzecz biorąc, jeśli makefile wygląda to

# main makefile 

foo: 
    make -C bar baz

i tym

# makefile in bar/ 

baz: quartz 
    do something

można zmienić je w ten sposób:

# main makefile 

foo: bar/quartz 
    cd bar && do something

Istnieje wiele szczegółowych informacji, ale teraz, jeśli bar/quartz nie została zmieniona, reguła foo nie zostanie uruchomiona.

Źródło

2011-02-25 07:49:28 Beta

To jest kompromis. Idąc z podejściem daje mi ogromny nadęty plik Makefile, który jest szybszy. Chcę zjeść moje ciasto i je też. I jest to możliwe dzięki magii inotify. Nigdy nie dotykaj żadnego pliku, który nie został zmodyfikowany, nawet w dniu modyfikacji. –

Zainstaluj inotify-tools i napisz kilka linii bash, aby wywołać make, gdy niektóre katalogi są aktualizowane.

Na marginesie, rekurencyjne powodują poważne błędy i są podatne na błędy. Preferuj non-recursive make.

Źródło

2011-02-25 12:10:47

Huh? Wywołanie powoduje dotknięcie każdego pliku w projekcie. Nie chcę tego robić! Cała sprawa, aby nigdy nie dotykać wszystkich plików, nawet w celu uzyskania czasu modyfikacji. –

@Elazar Leibovich: make nie dotyka żadnych plików. To pliki źródłowe stat, aby sprawdzić, czy cel musi zostać odbudowany. –

Maxim, nie wiem co z tobą, ale uważam, że 'stat'ing pliku, dotykając go. A jeśli potrzebujesz statystyki 100 000 plików za każdym razem, gdy robisz jedną markę, może to trochę potrwać (99,9% z tych plików nie jest dla ciebie interesujących, już skompilowałeś je do libsomething.so, i to wszystko czego potrzebujesz). –

Zastanawiam się tylko, czy jest to stat() ing plików, które trwa tak długo. Aby to sprawdzić tutaj jest mały systemtap skrypt pisałem zmierzyć czas potrzebny do stat() plików:

# 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 
}

a następnie używać go tak:

$ 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

Projekt Pobiegłem go na ma 4593 pliki źródłowe i trwa ~ 27msec (26952500nsec powyżej), aby dokonać statowania wszystkich plików wraz z odpowiednimi plikami .d. Korzystam jednak z nierekurencyjnej marki.

Źródło

2011-03-02 12:05:04

Możecie być poprawne, a to może być przedwczesna optymalizacja . BTW był gorący cache? Interesujące jest spojrzenie na projekt z 100 000 i sprawdzenie, czy czasy statystyki są większe. Zwróć uwagę, że tworzenie nierekursywne nie jest często opcją dla naprawdę dużych projektów. +1 za poświęcenie czasu na profil. –

Pamięć podręczna systemu plików była gorąca (stacja robocza, którą skompilowałem ma 12 GB pamięci RAM). I to na lokalnym systemie plików ext3. Przy budowaniu na NFS trwa to o kilka rzędów wielkości w przypadku plików 'stat()'. –

autor 'tup', mierzy kilka sekund na zrobienie niezmienionego projektu z plikami 100k http://gittup.org/tup/make_vs_tup.html –

Jeśli używasz OSX, można użyć fswatch

https://github.com/alandipert/fswatch

Oto jak korzystać fswatch do zmian do pliku, a następnie uruchomić zrobić, jeśli wykryje żadnego

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

Możesz uruchomić fswatch z pliku Makefile tak:

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

(Oczywiście, $ (FILE) jest zdefiniowana wewnątrz makefile.) make mogą teraz obserwować zmiany w pliku jak ten:

> make watch

można oglądać inny plik tak:

> make watch anotherFile

Źródło

2014-06-23 23:44:37 d13

Czy istnieje narzędzie do kompilacji oparte na mechanizmie inotify?

Odpowiedz

Powiązane problemy