Jakie są zalety skryptów kompilacji?

Automatyzacja.

Podczas programowania tylko w najprostszych projektach domyślny przycisk „buduj” zrobi wszystko, czego potrzebujesz; może być konieczne utworzenie WS z interfejsów API, generowanie dokumentów, łączenie z zasobami zewnętrznymi, wdrażanie zmian na serwerze itp. Niektóre środowiska IDE umożliwiają dostosowanie procesu kompilacji poprzez dodanie dodatkowych kroków lub konstruktorów, ale oznacza to tylko, że jesteś generowanie skryptu kompilacji za pomocą towarów IDE.

Ale tworzenie systemu to nie tylko pisanie kodu. W grę wchodzi wiele etapów. Niezależny skrypt IDE może być wykonywany automatycznie, co oznacza, że:

• Po zatwierdzeniu zmiany w kontroli wersji nowa kompilacja może zostać automatycznie uruchomiona przez serwer. Zapewni to, że nie zapomnisz zatwierdzić niczego potrzebnego do kompilacji.

• Podobnie, po zakończeniu kompilacji, testy mogą zostać automatycznie uruchomione, aby sprawdzić, czy coś nie zepsuło się.

• Teraz reszta organizacji (QA, sysadmins) ma wbudowany produkt, który

  a) jest doskonale odtwarzalny tylko z wersji kontrolnej.

  b) jest wspólny dla nich wszystkich.

Nawet kiedy pracowałem jako jednoosobowy zespół, używałem w tym celu skryptów; kiedy opracowałem poprawkę, zobowiązałem się do SVN, wyeksportowałem SVN z powrotem do innego katalogu i użyłem skryptu kompilacji do wygenerowania rozwiązania, które następnie trafiłoby do systemów przedprodukcyjnych, a później do produkcji. Gdyby kilka tygodni później (z już zmienioną lokalną bazą kodów) ktoś narzekał na błąd, wiedziałbym dokładnie, którą wersję SVN będę musiał sprawdzić, aby poprawnie debugować system.

Komentarze

• To najlepsza odpowiedź IMHO. Każdy ma rację co do swojego pomysłu, ale ten naprawdę pokazuje, dlaczego chcesz tworzyć skrypty. Ponieważ obsługują automatyzację, która będzie postępować wraz z rozwojem projektu, pozwoli Ci zaoszczędzić mnóstwo czasu.
• @Alexus Nie tylko czas, ale także głupie błędy. 😉 ” Powtarzanie prowadzi do nudy. Nuda prowadzi do przerażających błędów. Przerażające błędy prowadzą do '. Chciałbym się nudzić.' ” (Możesz też zmierzyć głupie błędy w czasie, ale jest to ' s ważne jest, aby zdać sobie sprawę, że ' oszczędza czas z kilku powodów.)
• Nawet w przypadku projektów jednoosobowych, uruchomienie lokalnego serwera Jenkins w celu zautomatyzowania ” kompilacja w oddzielnym katalogu ” może pomóc. ' Pracuję nad czymś w systemie Windows, co muszę potwierdzić również kompilacje krzyżowe, więc skompilowanie i uruchomienie testów przez Jenkinsa, a następnie zbudowanie wersji skompilowanej krzyżowo sprawia, że jestem bardziej pewny siebie ( i wydajne, oczywiście!), kiedy muszę wydać poprawki błędów.
• Nie ' nie zgadzam się z argumentem powtarzalnych kompilacji. W dzisiejszych systemach kompilacji jest tak wiele niekontrolowanych zmiennych, że uzyskanie powtarzalnych kompilacji jest dość trudne. Twój argument wygląda na to, że otrzymasz go od razu po wyjęciu z pudełka, co jest całkowicie nieprawdą.
• @JonasGr ö ger Automatyzacja usuwa jedną z największe zmienne: ludzie.

Podobnie jak kod, skrypt kompilacji jest wykonywany przez komputer. Komputery wyjątkowo dobrze wykonują zestaw instrukcji. W rzeczywistości (poza samomodyfikującym się kodem) komputery będą wykonywać tę samą sekwencję instrukcji dokładnie w ten sam sposób, mając te same dane wejściowe. Zapewnia to poziom spójności, który, cóż, tylko komputer może dorównać.

Natomiast my, wypełnione wodą worki z mięsem, jesteśmy po prostu nikczemni, jeśli chodzi o kolejne kroki. Ten nieznośny analityczny mózg ma tendencję do kwestionowania wszystkiego, co napotka. „Och… nie potrzebuję tego” lub „Czy naprawdę mam używać tej flagi? Ech … Po prostu to zignoruję. Ponadto mamy tendencję do popadania w samozadowolenie. Kiedy już zrobiliśmy coś kilka razy, zaczynamy wierzyć, że znamy instrukcje i nie musimy zaglądać do instrukcji.

Z „Pragmatycznego programisty”:

Dodatkowo chcemy zapewnić spójność i powtarzalność projektu. Ręczne procedury pozostawiają konsekwencję na zmianę; powtarzalność nie jest gwarantowana, zwłaszcza jeśli aspekty procedury są otwarte na interpretację przez różne osoby.

Ponadto, jesteśmy POZIOMNIE powolni w wykonywaniu instrukcji ( w porównaniu z komputerem). W przypadku dużego projektu, z setkami plików i konfiguracji, ręczne wykonanie wszystkich kroków w procesie kompilacji zajęłoby lata.

Podam przykład z prawdziwego świata. Pracowałem nad oprogramowaniem wbudowanym, w którym większość kodu była udostępniana na kilku różnych platformach sprzętowych. Każda platforma miała inny sprzęt, ale większość oprogramowania była taka sama. Ale były małe elementy, które były specyficzne dla każdego sprzętu. Idealnie byłoby, gdyby wspólne elementy zostały umieszczone w bibliotece i połączone z każdą wersją. Jednak wspólnych elementów nie można było skompilować do wspólnej biblioteki. Musiało być skompilowane z każdą inną konfiguracją.

Na początku ręcznie skompilowałem każdą konfigurację. Przełączanie się między nimi zajęło tylko kilka sekund konfiguracje i nie było to aż tak bolesne. Pod koniec projektu wykryto krytyczną usterkę we wspólnej części kodu, w której urządzenie zasadniczo przejmowało magistralę komunikacyjną. To było ZŁE! Naprawdę źle. Znalazłem błąd w kodzie, naprawiłem go i ponownie skompilowałem każdą wersję. Z wyjątkiem jednego. Podczas procesu kompilacji rozproszyłem się i zapomniałem o jednym. Zostały wydane pliki binarne, maszyna została zbudowana, a dzień później otrzymałem telefon z informacją, że maszyna przestała odpowiadać. Sprawdziłem to i odkryłem, że urządzenie zablokowało autobus. „Ale naprawiłem ten błąd!”.

Mogłem go naprawić, ale nigdy nie znalazł się na tej jednej tablicy. Dlaczego? Ponieważ nie miałem zautomatyzowanego procesu kompilacji, który budowałby każdą wersję jednym kliknięciem.

Komentarze

• I możesz iść na kawę, gdy skrypt kompilacji jest uruchomiony!

Jeśli wszystko, co kiedykolwiek chcesz zrobić, to <compiler> **/*.<extension>, skrypty budowania nie służą żadnemu celowi (chociaż można argumentować, że jeśli zobaczysz Makefile w projekcie, wiesz, że możesz go zbudować za pomocą make). Rzecz w tym, że nietrywialne projekty zwykle wymagają czegoś więcej – przynajmniej” będziesz zwykle musiał dodać biblioteki i (w miarę dojrzewania projektu) skonfigurować parametry kompilacji.

IDE są zwykle przynajmniej w takim stopniu konfigurowalne – ale teraz proces budowania opiera się na opcjach specyficznych dla IDE.Jeśli używasz Eclipse , Alicja woli NetBeans , a Bob chce użyć IntelliJ IDEA , nie możesz współdzielić konfiguracji, a gdy któryś z was wprowadzi zmianę do kontroli źródła, musi albo ręcznie edytować utworzone przez IDE pliki konfiguracyjne innych programistów lub powiadom innych programistów, aby zrobili to sami (co oznacza, że w przypadku nieprawidłowej konfiguracji IDE dla niektórych IDE zostaną wprowadzone zmiany …).

Musisz także dowiedzieć się, jak wprowadzić tę zmianę w każdym z IDE używanych przez zespół i jeśli jedno z nich nie obsługuje tego konkretnego ustawienia …

Ten problem jest zależny od kultury – Twoi programiści mogą uznać za akceptowalne, że nie mają wyboru IDE. Jednak programiści, którzy mają doświadczenie z IDE, są zwykle szczęśliwsi i wydajniejsi, gdy z niego korzystają, a użytkownicy edytorów tekstów mają skłonność do religijnego zapału w kwestii swojego ulubionego ols, więc jest to jedno z miejsc, w których chcesz dać wolność programistom – a budowanie systemów właśnie na to pozwala. Niektórzy ludzie mogą mieć preferencje dotyczące systemu kompilacji, ale nie jest to tak fanatyczne jak preferencje IDE / edytora …

Nawet jeśli wszyscy programiści używają tego samego IDE – powodzenia w przekonaniu kompilacji serwer, aby go użyć …

To właśnie dotyczy prostych dostosowań procesu budowania, dla których IDE mają tendencję do dostarczania fajnego GUI. Jeśli potrzebujesz bardziej złożonych rzeczy – takich jak wstępne przetwarzanie / automatyczne generowanie plików źródłowych przed kompilacją – zwykle będziesz musiał napisać pre-build skrypt w jakimś podstawowym obszarze tekstowym wewnątrz konfiguracji IDE. Które systemy kompilacji nadal musiałbyś zakodować tę część, ale możesz to zrobić w rzeczywistym edytorze, w którym piszesz kod, a co ważniejsze: sama struktura systemu kompilacji zwykle zapewnia pewne wsparcie w organizowaniu tych skryptów.

Wreszcie – systemy budowania są dobre nie tylko do budowania projektu – możesz zaprogramować je do wykonywania innych zadań, które każdy w zespole może potrzebować wykonać. W Ruby on Na przykład Rails zawiera zadania budowania systemu służące do przeprowadzania migracji baz danych, czyszczenia plików tymczasowych itp. Umieszczenie tych zadań w systemie kompilacji zapewnia, że każdy członek zespołu może je wykonywać konsekwentnie. h3> Komentarze

• To ' to nie tylko kwestia różnych IDE. Niektórzy programiści nienawidzą i nienawidzą IDE wszystkich typów.
• @DavidHammen I ' jeden z tych programistów (chociaż ' skonfigurowałem mojego Vima tak trudno jest ' możliwe, że przekształciłem go w IDE …), a podczas pisania tego akapitu automatycznie pisałem ” edytory ” i musiałem to naprawić w IDE, ponieważ myślę, że ustawienie w IDE jest ważną częścią mojej odpowiedzi. Pytający najwyraźniej pochodzi ze świata IDE, a pytanie mówi o rozwoju bez IDE jako o czymś, do czego jesteś zmuszony, gdy nie ma dostępnego odpowiedniego IDE. Celem tej odpowiedzi jest pokazanie, jak systemy kompilacji są korzystne nawet dla zespołów składających się wyłącznie z użytkowników IDE.
• Ja też jestem jednym z tych programistów. Nie ' nie chcę, aby moje palce musiały opuszczać klawiaturę. Takie postępowanie przerywa moje procesy myślowe.
• Nie zgadzam się. Wolę IDE. Pozwalają mi nie przejmować się nazwami, łatwym wyszukiwaniem, refaktoryzacją, ładnym interfejsem użytkownika. Chodzi mi o to, że jeśli IDE może zrobić dla mnie coś, co w innym przypadku zrobiłbym z sedackiem itp., Używam tego.
• Chodzi o to, że w przypadku skryptów kompilacji każdy programista w zespole może używać tego, co chce, podczas gdy dzięki funkcji budowania IDE ' zmuszasz wszystkich nie tylko do używania IDE, ale także do korzystania z bardzo konkretnego IDE, dla którego jest skonfigurowany projekt (chyba że masz je skonfigurowane na wiele IDE i powodzenia w synchronizowaniu tego …)

Wiele IDE po prostu pakuje używane polecenia aby coś zbudować, a następnie wygeneruj skrypt i wywołaj go!

Na przykład w programie Visual Studio można zobaczyć parametry wiersza polecenia dla kompilacji C ++ w polu „wiersz poleceń”. Jeśli przyjrzysz się uważnie wynikom kompilacji, „zobaczysz plik tymczasowy zawierający skrypt kompilacji, który został użyty do uruchomienia kompilacji.

W dzisiejszych czasach wszystko to jest MSBuild , ale nadal jest uruchamiany bezpośrednio przez IDE.

Więc powodem używania wiersza poleceń jest to, że przechodzisz prosto do źródła i pomijasz środkowego człowieka, pośrednik, który mógł zostać zaktualizowany lub wymagać stosu zależności, których po prostu nie potrzebujesz lub których nie potrzebujesz na bezgłowym serwerze, który działa jako ciągła integracja (CI)

Ponadto, Twoje skrypty robią więcej niż zwykłe kroki zorientowane na programistę, do których zostały zaprojektowane.Na przykład po kompilacji możesz chcieć, aby pliki binarne zostały spakowane i skopiowane do specjalnej lokalizacji, utworzony pakiet instalatora lub uruchomione na nich narzędzie dokumentacji. Wiele różnych zadań jest wykonywanych przez serwer CI, które są bezcelowe na komputerze deweloperskim, więc chociaż można by stworzyć projekt IDE, który wykonywałby wszystkie te kroki, musiałby wtedy utrzymywać dwa z nich – projekt dla programistów i drugi dla kompilacji. Niektóre zadania budowania (na przykład analiza statyczna) mogą zająć dużo czasu, czego nie chciałbyś w projektach deweloperskich.

Krótko mówiąc, jest to po prostu łatwiejsze – stwórz skrypt, który zrobi wszystko, co chcesz i można to szybko i łatwo rozpocząć w wierszu poleceń lub konfiguracji serwera kompilacji.

make 

jest dużo łatwiejsze do zapamiętania i wpisania niż

gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h 

A projekty mogą mieć bardzo złożone polecenia kompilacji. Skrypt kompilacji może również rekompilować tylko te elementy, które uległy zmianie. Jeśli chcesz zrobić czystą kompilację,

make clean 

jest łatwiejsze i bardziej niezawodne po prawidłowej konfiguracji niż próba zapamiętania każdego miejsca, w którym może znajdować się plik pośredni

Oczywiście, jeśli używasz IDE, kliknięcie przycisku kompilacji lub czyszczenia również jest łatwe. Jednak znacznie trudniej jest zautomatyzować przesuwanie kursora w określone miejsce na ekranie, zwłaszcza gdy to miejsce może się przesuwać, gdy okno się porusza, niż zautomatyzować proste polecenie tekstowe.

Jak inaczej byś to zrobił? Jedynym innym sposobem jest podanie jednego długiego polecenia wiersza poleceń.

Innym powodem jest to, że Pliki makefile pozwalają na kompilację przyrostową, co znacznie przyspiesza czas kompilacji.

Pliki Makefiles mogą również tworzyć wieloplatformowy proces kompilacji. CMake generuje różne skrypty budowania w oparciu o platformę.

Edytuj:

Dzięki IDE jesteś przywiązany do określonego sposobu robienia rzeczy. Wiele osób używa vim lub emacs, mimo że nie mają wielu funkcji podobnych do IDE. Robią to, ponieważ chcą mieć moc redaktorzy zapewniają. Skrypty budowania są niezbędne dla tych, którzy nie używają IDE.

Nawet dla tych, którzy używają IDE, możesz chcieć naprawdę wiedzieć, co się dzieje, więc skrypt kompilacji zawiera szczegółowe informacje implementacji, której nie ma podejście oparte na graficznym interfejsie użytkownika.

Same IDE często używają również wewnętrznych skryptów do budowania; przycisk uruchamiania to po prostu kolejny sposób na uruchomienie polecenia make.

Powyższe odpowiedzi dotyczą wielu ważnych kwestii, ale jeden przykład z prawdziwego świata, który chciałbym dodać (którego nie mogę dodać jako komentarza z powodu braku karmy), pochodzi z programowania na Androida.

Jestem profesjonalnym Androidem / iOS / Windows Programista telefonów i ja używam interfejsów API usług Google (głównie Map Google) a lot .

W Androidzie , te usługi wymagają dodania magazynu kluczy , lub typ pliku z identyfikatorem programisty, który informuje Google, że jestem tym, za kogo się podaje, w konsoli programisty. Jeśli moja aplikacja jest skompilowana z innym magazynem kluczy, sekcja aplikacji Mapy Google nie będzie działać.

Zamiast dodawać i zarządzać kilkunastoma magazynami kluczy w konsoli programisty, z których tylko jeden może być faktycznie użyty do aktualizacji aplikacji, dołączam ten magazyn kluczy do naszego bezpiecznego repozytorium i użyj Gradle, aby powiedzieć Android Studio, jakiego magazynu kluczy użyć podczas budowania dla „debugowania” lub „wydania”. Teraz muszę tylko dodać dwa magazyny kluczy do mojej konsoli programisty Google, jeden do „debugowania” i jeden do „wydania”, a wszyscy członkowie mojego zespołu mogą sklonować repozytorium i od razu przystąpić do programowania bez konieczności wchodzenia do programisty konsolę i dodaj skrót SHA ich konkretnego magazynu kluczy lub, co gorsza, , dzięki czemu będę nimi zarządzać . Dodatkową korzyścią jest to, że każdy członek zespołu otrzymuje kopię magazynu kluczy do podpisywania, co oznacza, że jeśli jestem poza biurem, a aktualizacja jest zaplanowana, członek zespołu musi tylko wykonać bardzo krótką listę instrukcji, aby wysłać aktualizacja.

Automatyzacja kompilacji, taka jak ta, zapewnia spójność kompilacji i zmniejsza dług techniczny, skracając czas konfiguracji, gdy otrzymujemy nowego programistę, nową maszynę lub gdy musimy zmienić obraz maszyna.

Zalety tworzenia skryptu:

• zmiany wyglądają jak kod (dla na przykład w poleceniu git diff), inaczej niż w przypadku różnych zaznaczonych opcji w oknie dialogowym

• tworząc więcej wyników niż prosta kompilacja

W niektórych moich poprzednich projektach używałem skryptów kompilacji do:

• generowania dokumentacji projektu (w oparciu o doxygen)
• budowania
• uruchom testy jednostkowe
• wygeneruj raporty dotyczące pokrycia testów jednostkowych
• spakuj pliki binarne do archiwum wydania
• wygeneruj wewnętrzne informacje o wersji (na podstawie komunikatów „git log” )
• testy automatyczne

Często można wywołać przycisk „buduj” w sposób zautomatyzowany (na przykład Visual Studio akceptuje argumenty wiersza poleceń). Ludzie piszą skrypty kompilacji, gdy tylko będą potrzebować czegoś, czego przycisk kompilacji nie może zapewnić.

Na przykład większość IDE pozwala tylko na tworzenie jedna platforma na raz lub tylko jedna język naraz. Następnie jest to, co robisz z wbudowanymi wyjściami: czy twoje IDE może umieścić je wszystkie w pakiecie instalacyjnym?