Prosty sposób na pozbycie się * wszystkiego * wygenerowanego przez SBT?

81

Czy istnieje łatwy sposób na pozbycie się wszystkiego, co jest generowane w wyniku wykonania kompilacji SBT? Okazuje się, że tworzy docelowe katalogi w każdym miejscu. Działający

sbt clean clean-cache clean-lib clean-plugins

... nie pozbywa się wszystkiego.

scala sbt

— Wilfred Springer
źródło

Też chciałbym to zobaczyć i przesłałem zgłoszenie: code.google.com/p/simple-build-tool/issues/detail?id=166

— Landon Kuhn

Ten tracker problemów nie jest już używany, więc przesłałem

— Robin Green

69

W moim systemie (Ubuntu Linux) z SBT 0.13.5 i niektórymi projektami z kursu Coursera Functional Programming znalazłem wszystkie foldery o łącznej wielkości 2,1 GB dla 12 projektów ze względu na wszystkie pliki pamięci podręcznej i zduplikowane pliki do pobrania Scala.

Aktualne polecenia SBT, które działają i usuwają prawie wszystko, to:

sbt clean clean-files

Spowoduje to usunięcie folderów „target” i „lib_managed” najwyższego poziomu (w tym przypadku od 23 MB do 3,2 MB), ale pozostawi niektóre foldery docelowe w projekcie:

./project/project/project/target
./project/project/target
./project/target

W tym miejscu bardzo pomocne jest polecenie znajdowania systemu Linux (również opublikowane przez @ jack-oconnor):

find . -name target -type d -exec rm -rf {} \;

To sprowadza nas z powrotem do zaledwie 444 KB dla jednego z moich własnych projektów, a 2,1 GB spadło do 5,0 MB!

W systemie Windows nie będziesz mieć tylu przydatnych opcji wiersza poleceń, np. Brak symboli wieloznacznych w nazwach ścieżek, ale zawsze możesz spróbować wymusić to za pomocą:

rmdir /s /q target project/target project/project/target

Najlepsze, co mogę zrobić, aby automatycznie znaleźć, to polecenie DIR:

dir /ad /s /b | find "target"

— RudeDude
źródło

Czy konieczne jest posiadanie -fflagi podczas używania polecenia find? Wydaje się niepotrzebne i potencjalnie niebezpieczne.

— unjankify

To działało dobrze dla mnie:find . -name target -type d -exec rm -r {} \;

— unjankify

Część „-f” polecenia „rm” nie powinna być potrzebna, ale w niektórych systemach może być lepsza niż długa lista potwierdzeń usunięcia.

— RudeDude

3

@AlbertBikeev: może sbt clean cleanFilesdziała dla Ciebie

— serv-inc

2

sbt clean cleanFiles

— frostcs

6

Oczywiście jest to bardzo ważne w przypadku odtwarzalnych kompilacji na serwerze integracyjnym, takim jak Jenkins!

Upewnij się, że wszystkie pliki, w tym pamięć podręczna bluszczu , są przechowywane w obszarze roboczym serwera integracyjnego, dostarczając argumenty wiersza poleceń, takie jak ten, do sbt:

-Dsbt.global.base=project/.sbtboot -Dsbt.boot.directory=project/.boot -Dsbt.ivy.home=project/.ivy

a następnie kliknij przycisk Wipe Out Workspace w Jenkins lub jego odpowiednik na innych serwerach integracyjnych. To zdecydowanie powinno wystarczyć!

Lub, jeśli używasz najnowszej wersji skryptu uruchamiania SBT, możesz po prostu dodać -no-sharezamiast tego.

— Robin Green
źródło

Jeśli już używasz Jenkinsa, to wtyczka do czyszczenia jest świetną alternatywą dla upewnienia się, że obszar roboczy jest wyczyszczony

— ecoe

5

W systemie Linux lub podobnym jest to lepsze niż find -name, ponieważ nie spowoduje przypadkowego usunięcia katalogu o nazwie, targetktóry może istnieć w kodzie źródłowym:

find . -regextype posix-awk -regex \.(/project)*/target -exec rm -r {} +

Jeśli uruchamiasz to polecenie w powłoce, musisz zacytować wyrażenie regularne, na przykład dla bash:

find . -regextype posix-awk -regex '\.(/project)*/target' -exec rm -r {} +

W przypadku wyszukiwania BSD (np. W systemie Mac OS X) polecenie będzie wyglądać następująco:

find -E . -regex \.(/project)*/target -exec rm -r {} +

— Adrian Hempel
źródło

2

Zgadzam się z bardzo dobrymi sugerowanymi rozwiązaniami, osobiście dołączam niewielką zmianę jako zadanie tworzenia gnu.

zawartość Makefile:

clean:
    find . -name target | xargs rm -fr

a następnie uruchom:

make clean

Lubię używać Makefiles jako kodu jako dokumentacji.

— Jose Miguel
źródło