![Code op een laptopscherm](https://www.howtogeek.com/wp-content/uploads/2019/07/img_5d2f749842f38.png)
Is u verteld om “de opslagplaats te klonen en te bouwen”, en weet u niet wat u vervolgens moet doen? We laten je zien hoe je dat programma op GitHub op Linux kunt laten draaien, zelfs als je een beginner bent.
De instructies waaruit een computerprogramma bestaat, worden geschreven, bewerkt en opgeslagen in tekstbestanden. Een programma dat een compiler wordt genoemd, verwerkt deze bestanden vervolgens. Dit produceert de uitvoerbare versie van het programma. De tekstbestanden met instructies worden de broncode genoemd. De versie van het programma die daadwerkelijk op een computer kan worden uitgevoerd, wordt het binaire of het uitvoerbare bestand genoemd.
Dat is een vereenvoudigde versie van gebeurtenissen, maar het schetst een correct – zij het algemeen – beeld. In de praktijk vind je allerlei variaties op dat model. Soms genereren andere programma’s de tekstbestanden. Andere keren draait de broncode in een interpreter en hoeft deze niet te worden gecompileerd, enzovoort.
De enige universele waarheid voor alle softwareprojecten is echter deze: de broncodebestanden zijn de kroonjuwelen en ze moeten net zo zorgvuldig worden onderhouden.
Versiebeheerprogramma’s
Alle broncodebestanden binnen een project worden de codebase genoemd. Bij grote projecten werken vaak veel ontwikkelaars aan de codebase. Elke codewijziging moet worden gevolgd en identificeerbaar. Indien nodig moeten de wijzigingen omkeerbaar zijn. Als verschillende ontwikkelaars wijzigingen aanbrengen in hetzelfde broncodebestand, moeten hun bewerkingen worden samengevoegd.
Het is dan ook niet verwonderlijk dat softwareprogramma’s, versiecontrolesystemen genaamd, bestaan om het beheer van wijzigingen in de codebase gemakkelijker te maken. Versiecontrolesystemen houden alle vorige versies van elk bestand in de codebase en elke wijziging wordt geregistreerd, becommentarieerd en bijgehouden.
Een klein ding genaamd Git
Linus Torvalds, de maker van de Linux-kernel, ontwikkelde een versiebeheerprogramma genaamd Git om de Linux-kernelcodebase te beheren. Het is nu ‘s werelds meest gebruikte versiebeheersoftware. Er zijn miljoenen mensen die het gebruiken – letterlijk.
Met Git wordt de codebase van een project opgeslagen in repositories. Naast de lokale repositories die op de computers van de ontwikkelaar staan en misschien op een centrale server in het netwerk, is het een goede gewoonte om een off-site of externe repository te hebben.
En dat is waar GitHub binnenkomt.
GitHub
GitHub is gemaakt als resultaat van git
‘s succes. De oprichters zagen de opkomende behoefte aan veilig gehoste afstandsbediening git
repositories. Ze lanceerden een bedrijf dat een cloudplatform bood waarmee ontwikkelteams externe opslagplaatsen kunnen hosten. Vanaf april 2019 host GitHub meer dan 100 miljoen repositories.
Als een applicatie een open-sourceproject is, is de kans erg groot dat deze op GitHub wordt gehost. Er zijn andere repository-platforms beschikbaar, zoals BitBucket en GitLab, maar GitHub heeft het leeuwendeel van open source-repositories.
Anatomie van een repository
Een GitHub-repository bestaat uit mappen met bestanden zoals de allerbelangrijkste broncodebestanden. Gewoonlijk zijn er veel andere soorten bestanden in de repository. Er kunnen documentatiebestanden, man-pagina’s, softwarelicentiebestanden, build-instructies en shell-scriptbestanden zijn. Er zijn geen regels over wat een repository moet of moet bevatten, maar er zijn wel conventies.
Als je de weg kent in een keuken, kun je door elke keuken navigeren. Het is hetzelfde met repositories. Als je eenmaal de conventies begrijpt, weet je waar je heen moet om te vinden wat je nodig hebt.
Dus, hoe krijg je een kopie van de repository op je computer en hoe bouw je het programma in een binair uitvoerbaar bestand?
Het readme-bestand
Het is gebruikelijk om een leesmij-bestand op te nemen in een repository. Het kan readme, Readme of README worden genoemd. Het kan de extensie “.md” hebben of helemaal geen extensie.
Laten we eens kijken naar de GitHub-repository voor de Atom-editor. Je ziet een lange lijst met mappen en bestanden. Scroll naar beneden en je ziet de inhoud van het README.md-bestand.
GitHub plaatst automatisch de inhoud van het leesmij-bestand op de voorpagina van de repository. Als het leesmij-bestand de extensie “.md” heeft, bevat het Markdown-opmaaktaal. Hierdoor kunnen de ontwikkelaars stijlelementen gebruiken, zoals lettertypen, opsommingstekens en afbeeldingen.
Meestal heeft een leesmij-bestand secties die u vertellen waar het project over gaat, wat de typelicentie is, wie het project onderhoudt, hoe u erbij betrokken kunt raken en hoe u de applicatie moet bouwen en uitvoeren.
Als het niet de daadwerkelijke bouwinstructies vermeldt, zal het u vertellen waar u deze informatie kunt vinden. Andere informatie die nuttig is voor het bouwen van de applicatie, zoals de benodigde build-tools en andere afhankelijkheden, kan hier worden vermeld of een link kan u naar die informatie leiden.
The boxes Repository
Onze missie is om de opslagplaats voor boxen te klonen en vervolgens het boxes
toepassing.
De repository volgt dezelfde lay-out als de Atom-versie. Er is een lijst met mappen en bestanden en daaronder staat de inhoud van het leesmij-bestand. Het volgt de standaardlay-out voor een repository, maar het is een kleiner project, dus er zijn minder mappen en bestanden.
Het readme-bestand is ook korter. Het heeft een sectie met de naam ‘Ontwikkeling’. In dat gedeelte staat een link met de titel ‘bouwen vanuit de bron’. Als we die link volgen, moeten we de informatie vinden die we nodig hebben.
Er is meestal wat lichtgewicht speurwerk nodig om door de repository te navigeren en de gewenste informatie te vinden, maar het is niet moeilijk. Lees alles op de repository-pagina zorgvuldig door. Soms is de informatie aanwezig, maar wordt deze mogelijk niet prominent weergegeven.
De afhankelijkheden
De “Building from Source” -pagina heeft een sectie genaamd “Building on Linux”, en dat is precies wat we nodig hebben. Er staat dat we een C-compiler, Bison en Flex moeten hebben geïnstalleerd.
De build-instructies zeggen om het make
commando, dus we hebben ook nodig make
.
De tools die nodig zijn om deze applicatie te bouwen zijn een C-compiler, Bison, Flex, make
, en Git (om de repository naar je computer te klonen).
Dit artikel is onderzocht op computers met de Linux-distributies Ubuntu, Fedora en Manjaro. Geen van de distributie had al deze tools geïnstalleerd – er moest iets op elk ervan worden geïnstalleerd.
De gereedschapsset installeren
Ubuntu moest Git, Flex, Bison en make
geïnstalleerd. Hier zijn de commando’s:
sudo apt-get install git
sudo apt-get install flex
sudo apt-get install bison
sudo apt-get install make
Fedora moest Flex, Bison en make
geïnstalleerd. Hier zijn de commando’s:
sudo dnf install flex
sudo dnf install bison
sudo dnf install make
Manjaro moest de GCC-compiler, Flex en Bison hebben geïnstalleerd. Hier zijn de commando’s:
sudo pacman -Syu gcc
sudo pacman -Syu flex
sudo pacman -Syu bison
De repository klonen
Elke GitHub-repository heeft een specifiek webadres dat wordt gebruikt met Git om de repository naar uw computer te klonen. Op de hoofdpagina van de Box-repository staat een groene knop met het label ‘Klonen of downloaden’.
Klik op de knop om het webadres te zien. Dit is het adres dat we moeten doorgeven aan het git
commando wanneer we de repository klonen.
Ga naar de directory waarin we de repository willen laten klonen, en gebruik dan deze opdracht. Als uw terminalvenster dit ondersteunt, kunt u het webadres kopiëren en in de opdracht plakken. Druk op Ctrl + Shift + V om in een GNOME-terminalvenster te plakken.
Git kloont de remote repository en maakt een lokale op je computer. Het vertelt ons dat het wordt gekloond naar een map met de naam “boxen”.
De map Boxen wordt gemaakt in de map waaruit u het git
opdracht. Als we overschakelen naar de map Boxen en de inhoud bekijken, zien we dezelfde lijst met bestanden en mappen die we op de GitHub-pagina hebben gezien.
Super goed! We hebben de broncode en andere bestanden met succes naar onze computer gekloond. Nu moeten we de applicatie bouwen.
De applicatie bouwen
Om de applicatie te bouwen, moeten we de instructies in de GitHub-repository volgen. Soms zullen we een bepaald shell-bestand uitvoeren en andere zullen we uitvoeren make
. De build-instructies die we volgen, vertelden ons om uit te voeren make
.
De make
hulpprogramma leest en voert een reeks instructies uit vanuit een makefile. Deze instructies vertellen make
hoe je het programma compileert en aan elkaar koppelt. make
geeft de instructies door aan de compiler en andere buildtools.
Het commando dat we moeten gebruiken, zal bellen make
tweemaal. De eerste oproep aan make
bouwt de applicatie en de tweede voert een reeks tests uit.
Het commando dat de bouwinstructies ons vertelden te gebruiken, is:
make && make test
Veel regels met uitvoer scrollen snel in het terminalvenster. Binnen een minuut keert u terug naar de opdrachtprompt.
Inzet van de dozen Applicatie
De applicatie is gebouwd en we hebben een uitvoerbaar binair bestand. We moeten nu het binaire bestand naar de / usr / bin / directory kopiëren. Hierdoor kan de shell het vinden wanneer we het proberen te gebruiken.
Voor sommige toepassingen is dit misschien alles wat u hoeft te doen. In andere gevallen moet u wellicht extra bestanden, zoals man-pagina’s en configuratiebestanden, naar locaties in het bestandssysteem kopiëren. Dit laatste is wat we moeten doen met onze nieuwe applicatie omdat deze in de build-instructies stond.
Gebruik sudo
om deze opdrachten uit te voeren. Het eerste commando kopieert een man-pagina naar de man1-directory:
sudo cp doc/boxes.1 /usr/share/man/man1
Kopieer vervolgens het globale configuratiebestand naar een map in / usr / share /:
sudo cp boxes-config /usr/share/boxes
Kopieer tenslotte het binaire bestand naar / usr / bin:
sudo cp src/boxes /usr/bin
Testen van de dozen Toepassing
Eens kijken of het allemaal werkt! Probeer de man-pagina voor de boxes
opdracht.
man boxes
Dat is bemoedigend! U ziet een man-pagina die u vertelt hoe u de boxes
opdracht.
Druk op “Q” om het man-systeem te verlaten en probeer de boxes
opdracht.
echo How-To Geek | boxes
En we krijgen het antwoord:
Dit lijkt misschien enigszins teleurstellend gezien alle moeite die je hebt gedaan, maar het doel van deze oefening was om je te helpen bij het terughalen van een repository uit GitHub en het bouwen van de applicatie.
De boxes
commando stelt u in staat om tekst die er in een grote verscheidenheid aan frames naartoe wordt geleid, om te laten lopen. Sommigen van hen kunnen worden gebruikt als commentaar in broncodebestanden. Het bovenstaande formaat zou bijvoorbeeld werken als commentaar in een C-broncodebestand. Anderen zijn puur decoratief. De -d
Met de optie (ontwerp) kunt u de stijl van het frame kiezen.
echo How-To Geek | boxes -d whirly
echo How-To Geek | boxes -d c-cmt2
Er is een lange lijst met ontwerpen waaruit u kunt kiezen. Gebruik deze opdracht om ze allemaal te zien:
boxes -l | less
Bouw voltooid
De stappen om vanaf de bron te bouwen zijn meestal eenvoudig:
- Bekijk de build-instructies op de repository.
- Controleer of u de vereiste tools hebt geïnstalleerd en installeer alle ontbrekende tools.
- Kloon de repository naar uw computer.
- Volg de bouwinstructies, die vaak net zo eenvoudig zijn als typen
make
. - Kopieer het bestand (en) naar de gewenste locaties.
Als er stappen in de bouwinstructies zijn die onduidelijk zijn, kijk dan of het project een forum of community heeft waar je een vraag naar kunt sturen. Als de applicatie een website heeft, heeft deze mogelijk een “Contact” -pagina. De ontwikkelaar die het dozen-project onderhoudt, heeft zijn e-mail op de “Over” -pagina van de dozen-website. Dat is een genereus gebaar van zijn kant, en typerend voor de bredere open source-gemeenschap.