Har du blitt bedt om å «klone repoen og bygge den,» og vet ikke hva du skal gjøre videre? Vi viser deg hvordan du får det programmet på GitHub til å kjøre på Linux, selv om du er nybegynner.
Instruksjonene som utgjør et dataprogram er skrevet, redigert og lagret i tekstfiler. Et program kalt en kompilator behandler deretter disse filene. Dette produserer den kjørbare versjonen av programmet. Tekstfilene med instruksjoner kalles kildekoden. Versjonen av programmet som faktisk kan kjøres på en datamaskin kalles binær eller kjørbar.
Det er en forenklet versjon av hendelser, men den maler et korrekt – hvis generalisert – bilde. I praksis finner du alle slags varianter av den modellen. Noen ganger genererer andre programmer tekstfilene. Andre ganger kjører kildekoden inne i en tolk og trenger ikke å bli kompilert, og så videre.
Imidlertid er den ene universelle sannheten på tvers av alle programvareprosjekter denne: kildekodefilene er det kronjuvelene, og de må ivaretas like nøye.
Innholdsfortegnelse
Versjonskontrollprogrammer
Alle kildekodefilene i et prosjekt kalles kodebasen. Store prosjekter har ofte mange utviklere som jobber med kodebasen. Hver kodeendring må spores og identifiseres. Om nødvendig må endringene være reversible. Hvis forskjellige utviklere gjør endringer i den samme kildekodefilen, må redigeringene deres slås sammen.
Det er derfor ikke overraskende at det finnes programmer kalt versjonskontrollsystemer for å gjøre administrasjonen av endringer i kodebasen enklere. Versjonskontrollsystemer holder alle tidligere versjoner av hver fil i kodebasen, og hver endring blir registrert, kommentert og sporet.
En liten ting som heter Git
Linus Torvalds, skaperen av Linux-kjernenutviklet et versjonskontrollprogram kalt Git for å administrere Linux-kjernens kodebase. Det er nå verdens mest brukte versjonskontrollprogramvare. Det er millioner av mennesker som bruker det – bokstavelig talt.
Med Git lagres et prosjekts kodebase i repositories. I tillegg til de lokale depotene som sitter på utviklerens datamaskiner og kanskje på en sentral server på nettverket, er det en god praksis å ha et eksternt eller eksternt depot.
Og det er her GitHub kommer inn.
GitHub
GitHub ble opprettet som et resultat av gits suksess. Grunnleggerne så det nye behovet for sikkert vertsbaserte eksterne git-lagre. De startet en bedrift tilby en skyplattform for å tillate utviklingsteam å være vert for eksterne depoter. Fra april 2019 er GitHub vert for over 100 millioner depoter.
Hvis en applikasjon er et åpen kildekode-prosjekt, er sjansen stor for at den blir vert på GitHub. Det er andre depotplattformer tilgjengelig, som f.eks BitBucket og GitLabmen GitHub har brorparten av åpen kildekodelagre.
Anatomien til et depot
Et GitHub-depot består av mapper som inneholder filer som de aller viktigste kildekodefilene. Vanligvis er det mange andre typer filer i depotet. Det kan være dokumentasjonsfiler, man-sider, programvarelisensfiler, byggeinstruksjoner og shell-skriptfiler. Det er ingen regler for hva et depot skal eller må inneholde, men det er konvensjoner.
Hvis du kjenner veien rundt ett kjøkken, kan du navigere på hvilket som helst kjøkken. Det er det samme med repositories. Når du forstår konvensjonene, vet du hvor du skal gå for å finne det du trenger.
Så, hvordan får du en kopi av depotet på datamaskinen din, og hvordan bygger du programmet inn i en binær kjørbar?
Readme-filen
Det er tradisjonelt å inkludere en readme-fil i et depot. Det kan kalles readme, Readme eller README. Den kan ha en utvidelse av «.md» eller ingen utvidelse i det hele tatt.
La oss ta en titt på GitHub repository for Atom-redaktøren. Du ser en lang liste over mapper og filer. Rull ned, og du ser innholdet i README.md-filen.
GitHub legger automatisk innholdet i readme-filen på forsiden av depotet. Hvis readme-filen har filtypen «.md», vil den inneholde Markdown-oppmerking Språk. Dette lar utviklerne bruke stilelementer, for eksempel fonter, kulepunkter og bilder.
Vanligvis har en readme-fil seksjoner som forteller deg hva prosjektet handler om, hva typelisensen er, hvem som vedlikeholder prosjektet, hvordan du involverer deg og hvordan du bygger og kjører applikasjonen.
Hvis den ikke viser de faktiske byggeinstruksjonene, vil den fortelle deg hvor du finner denne informasjonen. Annen informasjon som er nyttig for å bygge applikasjonen, for eksempel byggeverktøyene som kreves og andre avhengigheter, kan være oppført her, eller en lenke kan ta deg til den informasjonen.
Boksene Repository
Vårt oppdrag er å klone boks-depotetog bygg deretter boks-applikasjonen.
Depotet følger samme layout som Atom en gjorde. Det er en liste over mapper og filer, og nedenfor er innholdet i readme-filen. Det følger standardoppsettet for et depot, men det er et mindre prosjekt, så det er færre mapper og filer.
Readme-filen er også kortere. Den har en seksjon kalt «Utvikling.» I den delen er en lenke med tittelen «bygge fra kilden.» Hvis vi følger den lenken, vi bør finne informasjonen vi trenger.
Det er vanligvis noe lett leting som er nødvendig for å navigere i depotet og finne informasjonen du vil ha, men det er ikke vanskelig. Les alt på repository-siden nøye. Noen ganger er informasjonen der, men den vises kanskje ikke tydelig.
Avhengighetene
«Bygge fra kilde»-siden har en seksjon kalt «Bygge på Linux», og det er akkurat det vi trenger. Det står at vi må ha en C kompilator, Bison, og Flex installert.
Byggeinstruksjonene sier at man skal utstede make-kommandoen, så vi trenger også make.
Verktøyene som kreves for å bygge denne applikasjonen er en C-kompilator, Bison, Flex, make og Git (for å klone depotet til datamaskinen din).
Denne artikkelen ble undersøkt på datamaskiner som kjører Linux-distribusjonene Ubuntu, Fedora og Manjaro. Ingen av distribusjonene hadde alle disse verktøyene installert – noe måtte installeres på hver av dem.
Installere verktøysettet
Ubuntu måtte ha Git, Flex, Bison og make installert. Her er kommandoene:
sudo apt-get install git
sudo apt-get install flex
sudo apt-get install bison
sudo apt-get install make
Fedora måtte ha Flex, Bison og make installert. Her er kommandoene:
sudo dnf install flex
sudo dnf install bison
sudo dnf install make
Manjaro måtte ha GCC-kompilatoren, Flex og Bison installert. Her er kommandoene:
sudo pacman -Syu gcc
sudo pacman -Syu flex
sudo pacman -Syu bison
Kloning av depotet
Hvert GitHub-depot har en spesifikk nettadresse som brukes med Git for å klone depotet til datamaskinen din. På hovedsiden til bokslageret er det en grønn knapp merket «Klon eller last ned.»
Klikk på knappen for å se nettadressen. Dette er adressen vi må sende til git-kommandoen når vi kloner depotet.
Bytt til katalogen som vi vil ha depotet klonet inn i, og bruk deretter denne kommandoen. Hvis terminalvinduet ditt støtter det, kan du kopiere og lime inn nettadressen i kommandoen. Trykk Ctrl+Shift+V for å lime inn i et GNOME-terminalvindu.
Git kloner det eksterne depotet og lager et lokalt på datamaskinen din. Den forteller oss at den klones inn i en katalog som heter «bokser».
Boks-katalogen er opprettet i katalogen du ga git-kommandoen fra. Hvis vi bytter til bokskatalogen og ser på innholdet, ser vi den samme listen over filer og mapper som vi så på GitHub-siden.
Flott! Vi har klonet kildekoden og andre filer til datamaskinen vår. Nå må vi bygge applikasjonen.
Bygge applikasjonen
For å bygge applikasjonen må vi følge instruksjonene på GitHub-depotet. Noen ganger kjører vi en bestemt shell-fil, og andre kjører vi make. Byggeinstruksjonene vi følger fortalte oss å kjøre make.
Make-verktøyet leser og utfører et sett med instruksjoner fra en makefil. Disse instruksjonene forteller hvordan du kompilerer programmet og kobler det sammen. make sender instruksjonene til kompilatoren og andre byggeverktøy.
Kommandoen vi blir bedt om å bruke vil kalle make to ganger. Den første anropet bygger applikasjonen, og den andre kjører en serie med tester.
Kommandoen byggeinstruksjonene fortalte oss å bruke er:
make && make test
Mange utdatalinjer ruller raskt forbi i terminalvinduet. Om et minutt eller så vil du bli returnert til ledeteksten.
Distribuere boksene Application
Applikasjonen er bygget, og vi har en kjørbar binær. Vi må nå kopiere binærfilen til /usr/bin/-katalogen. Dette gjør at skallet kan finne det når vi prøver å bruke det.
For noen applikasjoner kan dette være alt du trenger å gjøre. I andre tilfeller må du kanskje kopiere flere filer, som man-sider og konfigurasjonsfiler, til steder i filsystemet. Det siste er det vi må gjøre med vår nye applikasjon fordi det var i byggeinstruksjonene.
Bruk sudo for å kjøre disse kommandoene. Den første kommandoen kopierer en man-side til man1-katalogen:
sudo cp doc/boxes.1 /usr/share/man/man1
Deretter kopierer du den globale konfigurasjonsfilen til en katalog i /usr/share/:
sudo cp boxes-config /usr/share/boxes
Til slutt kopierer du binærfilen til /usr/bin:
sudo cp src/boxes /usr/bin
Testing av boksene Søknad
La oss se om alt fungerer! Prøv å åpne man-siden for boxes-kommandoen.
man boxes
Det er oppmuntrende! Du ser en man-side som forteller deg hvordan du bruker boxes-kommandoen.
Trykk «Q» for å forlate mann-systemet og prøv å bruke boxes-kommandoen.
echo How-To Geek | boxes
Og vi får svaret:
Dette kan virke litt overveldende med tanke på all innsatsen du har gjort, men poenget med denne øvelsen var å lede deg gjennom å trekke tilbake et depot fra GitHub og bygge applikasjonen.
Boks-kommandoen lar deg pakke tekst som er overført til den i en rekke rammer. Noen av dem kan brukes som kommentarer i kildekodefiler. Formatet ovenfor vil fungere som en kommentar i en C-kildekodefil, for eksempel. Andre er rent dekorative. Alternativet -d (design) lar deg velge stilen på rammen.
echo How-To Geek | boxes -d whirly
echo How-To Geek | boxes -d c-cmt2
Det er en lang liste med design du kan velge fra. For å se dem alle, bruk denne kommandoen:
boxes -l | less
Bygg komplett
Trinnene for å bygge fra kilden er vanligvis enkle:
Se gjennom byggeinstruksjonene på depotet.
Sjekk at du har de nødvendige verktøyene installert og installer de som mangler.
Klon depotet til datamaskinen din.
Følg byggeinstruksjonene, som ofte er like enkle som å skrive.
Kopier filen(e) til de nødvendige stedene.
Hvis det er trinn i byggeinstruksjonene som er uklare, se om prosjektet har et forum eller fellesskap du kan sende et spørsmål til. Hvis applikasjonen har et nettsted, kan de ha en «Kontakt oss»-side. Utvikleren som vedlikeholder boksprosjektet har sin e-post på «Om»-siden til boksens nettside. Det er en sjenerøs gest fra hans side, og typisk for det bredere åpen kildekodesamfunnet.