briefing: deze gedetailleerde gids legt uit hoe een programma van broncode te installeren code in Linux en hoe de geïnstalleerde software uit de broncode te verwijderen.

een van de grootste kracht van je Linux distributie is de pakketbeheerder en de bijbehorende software repository. Met hen, heb je alle benodigde tools en middelen om te downloaden en installeren van nieuwe software op uw computer op een volledig geautomatiseerde manier.

maar ondanks al hun inspanningen kunnen de pakketbeheerders niet elke use cases aan. Noch kunnen ze verpakken alle beschikbare software die er zijn. Er zijn dus nog steeds situaties waarin je zelf nieuwe software moet compileren en installeren. Wat mij betreft, de meest voorkomende reden, veruit, ik moet wat software compileren is wanneer ik nodig heb om een zeer specifieke versie te draaien, of de broncode te wijzigen door het gebruik van een aantal mooie compilatie-opties.

als uw behoeften tot de laatste categorie behoren, is de kans groot dat u al weet wat u moet doen. Maar, voor de overgrote meerderheid van Linux gebruikers, zou het compileren en installeren van software uit de broncode voor de eerste keer kunnen lijken op een initiatie ceremonie: enigszins beangstigend; maar met de belofte van het betreden van een nieuwe wereld van mogelijkheden en een plaats van prestige in een bevoorrechte gemeenschap.

A. software installeren vanaf broncode in Linux

en dat is precies wat we hier gaan doen. Voor het doel van dit artikel, laten we zeggen dat ik nodig heb om NodeJS installeren 8.1.1 op mijn systeem. Precies die versie. Een versie die niet beschikbaar is in de Debian repository:

sh$ apt-cache madison nodejs | grep amd64 nodejs | 6.11.1~dfsg-1 | http://deb.debian.org/debian experimental/main amd64 Packages nodejs | 4.8.2~dfsg-1 | http://ftp.fr.debian.org/debian stretch/main amd64 Packages nodejs | 4.8.2~dfsg-1~bpo8+1 | http://ftp.fr.debian.org/debian jessie-backports/main amd64 Packages nodejs | 0.10.29~dfsg-2 | http://ftp.fr.debian.org/debian jessie/main amd64 Packages nodejs | 0.10.29~dfsg-1~bpo70+1 | http://ftp.fr.debian.org/debian wheezy-backports/main amd64 Packages

nu is het installeren van NodeJs op Ubuntu of Debian vrij eenvoudig als je het doet met de pakketbeheerder. Maar laten we het doen via de broncode.

Stap 1: De broncode ophalen van GitHub

zoals veel open-source projecten, kunnen de bronnen van NodeJS gevonden worden op GitHub: https://github.com/nodejs/node

dus, laten we daar direct heen gaan.

als je niet bekend bent met GitHub, git of een ander versiebeheersysteem dat het vermelden waard is, bevat de repository de huidige bron voor de software, evenals een geschiedenis van alle wijzigingen die gemaakt zijn via de jaren naar die software. Uiteindelijk tot aan de allereerste regel geschreven voor dat project. Voor de ontwikkelaars, het houden van die geschiedenis heeft vele voordelen. Voor ons vandaag, de belangrijkste is dat we in staat zullen zijn om de bronnen van het project te krijgen zoals ze waren op een bepaald moment in de tijd. Meer precies, Ik zal in staat zijn om de bronnen te krijgen zoals ze waren toen de 8.1.1 versie die ik wil werd uitgebracht. Ook al waren er sindsdien veel wijzigingen.

op GitHub kunt u de” branch ” knop gebruiken om tussen verschillende versies van de software te navigeren. “Branch “en” tags ” zijn enigszins verwante concepten in Git. In principe maken de ontwikkelaars ” branch “en” tags ” om belangrijke gebeurtenissen in de projectgeschiedenis bij te houden, zoals wanneer ze beginnen te werken aan een nieuwe functie of wanneer ze een release publiceren. Ik zal hier niet in details treden, alles wat je moet weten is dat ik op zoek ben naar de versie met het label “v8.1.1”

na te hebben gekozen op de “v8.1.1 ” tag, de pagina is vernieuwd, de meest voor de hand liggende wijziging is de tag verschijnt nu als onderdeel van de URL. Bovendien zult u merken dat de datum van bestandswijziging ook anders is. De bron boom die je nu ziet is degene die bestond op het moment dat de v8.1.1 tag werd gemaakt. In zekere zin kun je een versiebeheertool als git zien als een tijdreismachine, waardoor je heen en weer kunt gaan in een projectgeschiedenis.

Op dit punt kunnen we de bronnen van NodeJS 8.1.1 downloaden. U kunt de grote blauwe knop niet missen die voorstelt om het ZIP-archief van het project te downloaden. Wat mij betreft, Ik zal downloaden en pak de ZIP van de opdrachtregel in het belang van de uitleg. Maar als je liever een GUI tool gebruikt, aarzel dan niet om dat te doen:

wget https://github.com/nodejs/node/archive/v8.1.1.zipunzip v8.1.1.zipcd node-8.1.1/

het downloaden van het ZIP-archief werkt geweldig. Maar als je het “als een pro” wilt doen, stel ik voor om direct de git tool te gebruiken om de bronnen te downloaden. Het is helemaal niet ingewikkeld— en het zal een mooi eerste contact zijn met een tool die je vaak tegenkomt:

# first ensure git is installed on your systemsh$ sudo apt-get install git# Make a shallow clone the NodeJS repository at v8.1.1sh$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/nodesh$ cd node/

trouwens, als je een probleem hebt, beschouw dan het eerste deel van dit artikel als een algemene inleiding. Later heb ik meer gedetailleerde uitleg Voor Debian – en RedHat-gebaseerde distributies om u te helpen bij het oplossen van veelvoorkomende problemen.

hoe dan ook, wanneer u de broncode hebt gedownload met git of als een ZIP-archief, moet u nu precies dezelfde bronbestanden in de huidige map hebben:

sh$ lsandroid-configure BUILDING.md common.gypi doc Makefile srcAUTHORS CHANGELOG.md configure GOVERNANCE.md node.gyp testbenchmark CODE_OF_CONDUCT.md CONTRIBUTING.md lib node.gypi toolsBSDmakefile COLLABORATOR_GUIDE.md deps LICENSE README.md vcbuild.bat

Stap 2: begrip van het bouwsysteem van het programma

we praten meestal over “het compileren van de bronnen”, maar de compilatie is slechts een van de fasen die nodig zijn om een werken software van de bron. Een build-systeem is een set van tool en praktijken die worden gebruikt om die verschillende taken te automatiseren en articuleren om de software volledig te bouwen door slechts enkele commando ‘ s uit te geven.

als het concept eenvoudig is, is de realiteit iets ingewikkelder. Omdat verschillende projecten of programmeertaal verschillende eisen kunnen hebben. Of vanwege de smaak van de programmeur. Of de ondersteunde platforms. Of om historische redenen. Of … of.. er is een bijna eindeloze lijst van redenen om te kiezen of een ander bouwsysteem te maken. Dat alles om te zeggen dat er veel verschillende oplossingen die er worden gebruikt.

NodeJS maakt gebruik van een GNU-stijl build systeem, het is een populaire keuze in de open source gemeenschap en nogmaals, een goede manier om uw reis te beginnen.

Het schrijven en afstemmen van een build-systeem is een vrij complexe taak, maar voor de “eindgebruiker” vergemakkelijken GNU-stijl build-systemen de taak met behulp van twee hulpmiddelen: configure en make.

het configure bestand is een project-specifiek script dat de configuratie van het doelsysteem en de beschikbare functie zal controleren om er zeker van te zijn dat het project kan worden gebouwd, waarbij uiteindelijk rekening wordt gehouden met de specifieke kenmerken van het huidige platform.

een belangrijk onderdeel van een typische configure taak is het bouwen van de Makefile. Dat is het bestand met de instructies die nodig zijn om het project effectief op te bouwen.

de make tool, aan de andere kant, is een POSIX tool beschikbaar op elk Unix-achtig systeem. Het zal de projectspecifieke Makefile lezen en de vereiste bewerkingen uitvoeren om uw programma te bouwen en te installeren.

maar, zoals altijd in de Linux wereld, heb je nog steeds enige clementie in het aanpassen van de build aan je specifieke behoeften.

./configure --help

het commando configure -help toont alle beschikbare configuratieopties. Nogmaals, dit is zeer projectspecifiek. En om eerlijk te zijn, is het soms nodig om in het project te graven voordat je de Betekenis van elke configuratieoptie volledig begrijpt.

maar er is tenminste één standaard GNU Autotools optie die u moet kennen: de --prefix optie. Dit heeft te maken met de bestandssysteem hiërarchie en de plaats waar uw software zal worden geïnstalleerd.

Stap 3: De FHS

De Linux bestandssysteem hiërarchie op een typische distributie meestal voldoen aan de Filesystem Hierarchy Standard (FHS)

die standaard verklaart het doel van de verschillende mappen van uw systeem: /usr/tmp/var enzovoort.

bij gebruik van de GNU Autotools— en de meeste andere bouwsystemen— zal de standaard installatie locatie voor uw nieuwe software /usr/localzijn. Wat is een goede keuze als volgens de FSH ” de/usr / local hiërarchie is voor gebruik door de systeembeheerder bij het installeren van software lokaal? Het moet veilig worden overschreven wanneer de systeemsoftware wordt bijgewerkt. Het kan gebruikt worden voor programma ‘ s en gegevens die deelbaar zijn tussen een groep hosts, maar niet gevonden worden in /usr.”

De/usr/local hierarchie repliceert op de een of andere manier de root directory, en u zult daar vinden/usr/local/bin voor de uitvoerbare programma ‘ s,/usr/local/lib voor de bibliotheken,/usr/local/share voor architectuur onafhankelijke bestanden en ga zo maar door.

het enige probleem bij het gebruik van de/usr/local boom voor aangepaste software installatie is de bestanden voor al uw software zal daar worden gemengd. Vooral na het installeren van een paar software, zal het moeilijk zijn om bij te houden naar welk bestand precies van /usr/local/bin en /usr/local/lib behoort tot welke software. Dat zal geen probleem veroorzaken aan het systeem al. Immers, /usr/bin is ongeveer dezelfde puinhoop. Maar dat zal een probleem worden op de dag dat u een handmatig geïnstalleerde software wilt verwijderen.

om dat probleem op te lossen, installeer ik meestal aangepaste software in de /opt sub-boom. Nogmaals, om de FHS te citeren:

_” / opt is gereserveerd voor de installatie van add-on application software pakketten.

Een pakket worden geïnstalleerd in /opt moeten vinden op de statische bestanden in een aparte /opt/<package> of /opt/<aanbieder> directory boom waar <package> is een naam die wordt beschreven in de software-pakket en <aanbieder> de provider LANANA geregistreerde naam.”_

dus we zullen een submap maken van /opt specifiek voor onze aangepaste NodeJS installatie. En als ik op een dag die software wil verwijderen, zal ik die directory gewoon moeten verwijderen:

sh$ sudo mkdir /opt/node-v8.1.1sh$ sudo ln -sT node-v8.1.1 /opt/node# What is the purpose of the symbolic link above?# Read the article till the end--then try to answer that# question in the comment section!sh$ ./configure --prefix=/opt/node-v8.1.1sh$ make -j9 && echo ok# -j9 means run up to 9 parallel tasks to build the software.# As a rule of thumb, use -j(N+1) where N is the number of cores# of your system. That will maximize the CPU usage (one task per# CPU thread/core + a provision of one extra task when a process# is blocked by an I/O operation.

alles behalve “ok” nadat het make commando is voltooid zou betekenen dat er een fout is opgetreden tijdens het bouwproces. Omdat we een parallelle build hebben uitgevoerd vanwege de optie -j, is het niet altijd gemakkelijk om de Foutmelding op te halen gezien het grote volume van de uitvoer die door het build-systeem wordt geproduceerd.

in het geval van een probleem, herstart make, maar zonder de optie -j deze keer. En de fout moet verschijnen aan het einde van de uitvoer:

sh$ make

tenslotte, als de compilatie is voltooid, kunt u uw software installeren op de locatie door het commando:

sh$ sudo make install

uit te voeren en het te testen:

sh$ /opt/node/bin/node --versionv8.1.1

B. Wat als er iets mis gaat tijdens het installeren van broncode?

wat ik hierboven heb uitgelegd is voornamelijk wat je kunt zien op de” build instruction ” pagina van een goed gedocumenteerd project. Maar gezien dit artikel doel is om u te laten compileren van uw eerste software van bronnen, is het misschien de moeite waard om de tijd te nemen om een aantal veel voorkomende problemen te onderzoeken. Dus, Ik zal de hele procedure opnieuw te doen, maar deze keer van een frisse en minimale Debian 9.0 en CentOS 7.0 systemen, zodat u de fouten die ik ondervonden en hoe ik ze opgelost kunt zien.

van Debian 9.0 “Stretch”

:~$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node-bash: git: command not found

Dit probleem is vrij eenvoudig te diagnosticeren en op te lossen. Installeer gewoon degit pakket:

:~$ sudo apt-get install git

:~$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node && echo okok

:~/node$ sudo mkdir /opt/node-v8.1.1:~/node$ sudo ln -sT node-v8.1.1 /opt/node

geen probleem hier.

:~/node$ ./configure --prefix=/opt/node-v8.1.1/WARNING: failed to autodetect C++ compiler version (CXX=g++)WARNING: failed to autodetect C compiler version (CC=gcc)Node.js configure error: No acceptable C compiler found! Please make sure you have a C compiler installed on your system and/or consider adjusting the CC environment variable if you installed it in a non-standard prefix.

uiteraard heeft u een compiler nodig om een project te compileren. NodeJS wordt geschreven met behulp van de C++ taal, we hebben een C++ compiler nodig. Hier installeer ik` g++’, de GNU C++ compiler voor dat doel:

:~/node$ sudo apt-get install g++:~/node$ ./configure --prefix=/opt/node-v8.1.1/ && echo okok

:~/node$ make -j9 && echo ok-bash: make: command not found

een andere ontbrekende tool. Dezelfde symptomen. Dezelfde oplossing:

:~/node$ sudo apt-get install make:~/node$ make -j9 && echo okok

:~/node$ sudo make install:~/node$ /opt/node/bin/node --versionv8.1.1

succes!

let op: Ik heb de verschillende tools een voor een geïnstalleerd om te laten zien hoe de diagnose van de compilatie problemen en om u de typische oplossing om deze problemen op te lossen. Maar als u zoekt naar meer informatie over het onderwerp of lees andere tutorials, zult u ontdekken dat de meeste distributies hebben “meta-pakketten” fungeren als een paraplu om een aantal of alle typische tools die worden gebruikt voor het samenstellen van een software te installeren. Op Debian-gebaseerde systemen, zult u waarschijnlijk tegenkomen de build-essentials pakket voor dat doel. En op Red-Hat-gebaseerde distributies, dat zal de” Development Tools ” groep.

van CentOS 7.0

 ~]$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node-bash: git: command not found

opdracht niet gevonden? Installeer het gewoon met de yum pakketbeheerder:

 ~]$ sudo yum install git

 ~]$ git clone --depth 1 \ --branch v8.1.1 \ https://github.com/nodejs/node && echo okok

 ~]$ sudo mkdir /opt/node-v8.1.1 ~]$ sudo ln -sT node-v8.1.1 /opt/node

 ~]$ cd node node]$ ./configure --prefix=/opt/node-v8.1.1/WARNING: failed to autodetect C++ compiler version (CXX=g++)WARNING: failed to autodetect C compiler version (CC=gcc)Node.js configure error: No acceptable C compiler found! Please make sure you have a C compiler installed on your system and/or consider adjusting the CC environment variable if you installed it in a non-standard prefix.

u raadt het al: NodeJS is geschreven met behulp van de C++ taal, maar mijn systeem mist de bijbehorende compiler. Yum om te redden. Omdat ik geen gewone CentOS-gebruiker ben, moest ik eigenlijk op het Internet zoeken naar de exacte naam van het pakket met de G++ – compiler. Die me naar die pagina leidt.: https://superuser.com/questions/590808/yum-install-gcc-g-doesnt-work-anymore-in-centos-6-4

 node]$ sudo yum install gcc-c++ node]$ ./configure --prefix=/opt/node-v8.1.1/ && echo okok

 node]$ make -j9 && echo okok

 node]$ sudo make install && echo okok

 node]$ /opt/node/bin/node --versionv8.1.1

succes. Nogmaals.

C. wijzigingen aanbrengen in de software geà nstalleerd vanaf broncode

u kunt software installeren vanaf de bron omdat u een zeer specifieke versie nodig hebt die niet beschikbaar is in uw distributie repository, of omdat u het programma wilt wijzigen om een bug te repareren of een functie toe te voegen. Immers, open-source is alles over het maken van wijzigingen. Dus, Ik zal deze gelegenheid te nemen om u een voorproefje van de kracht die je bij de hand hebt nu dat je in staat bent om uw eigen software te compileren.

Hier zullen we een kleine wijziging aanbrengen in de bronnen van NodeJS. En we zullen zien of onze wijziging zal worden opgenomen in de gecompileerde versie van de software:

Open het bestand node/src/node.cc in uw favoriete teksteditor (vim, nano, gedit, … ). En probeer dat fragment van de code te vinden:

 if (debug_options.ParseOption(argv, arg)) { // Done, consumed by DebugOptions::ParseOption(). } else if (strcmp(arg, "--version") == 0 || strcmp(arg, "-v") == 0) { printf("%s\n", NODE_VERSION); exit(0); } else if (strcmp(arg, "--help") == 0 || strcmp(arg, "-h") == 0) { PrintHelp(); exit(0); }

Het is rond regel 3830 van het bestand. Wijzig dan de regel die printf bevat om in plaats daarvan met die regel overeen te komen:

 printf("%s (compiled by myself)\n", NODE_VERSION);

ga dan terug naar uw terminal. Voordat je verder gaat-en om je wat meer inzicht te geven in de kracht achter git-kun je controleren of je het juiste bestand hebt gewijzigd:

diff --git a/src/node.cc b/src/node.ccindex bbce1022..a5618b57 100644--- a/src/node.cc+++ b/src/node.cc@@ -3828,7 +3828,7 @@ static void ParseArgs(int* argc, if (debug_options.ParseOption(argv, arg)) { // Done, consumed by DebugOptions::ParseOption(). } else if (strcmp(arg, "--version") == 0 || strcmp(arg, "-v") == 0) {- printf("%s\n", NODE_VERSION);+ printf("%s (compiled by myself)\n", NODE_VERSION); exit(0); } else if (strcmp(arg, "--help") == 0 || strcmp(arg, "-h") == 0) { PrintHelp();

je zou een ” – ” (minteken) voor de regel moeten zien zoals het was voordat je het veranderde. En een ” + ” (plusteken) voor de regel na uw wijzigingen.

Het is nu tijd om uw software opnieuw te compileren en opnieuw te installeren:

make -j9 && sudo make install && echo okok

Deze keer kan het mislukken omdat u een typefout hebt gemaakt tijdens het wijzigen van de code. Als dit het geval is, open dan het node/src/node.cc bestand in uw teksteditor en los de fout op.

zodra u erin geslaagd bent om die nieuwe gewijzigde versie van NodeJS te compileren en te installeren, kunt u controleren of uw wijzigingen daadwerkelijk in de software zijn opgenomen:

:~/node$ /opt/node/bin/node --versionv8.1.1 (compiled by myself)

Gefeliciteerd! Je hebt je eerste overstap gemaakt naar een open-source programma!

D. laat de shell onze aangepaste bouwsoftware vinden

Het is u misschien opgevallen dat ik altijd mijn nieuw gecompileerde NodeJS-software heb gestart door het absolute pad naar het binaire bestand op te geven.

/opt/node/bin/node

Het werkt. Maar dit is vervelend, op zijn zachtst gezegd. Er zijn eigenlijk twee gemeenschappelijke manieren om dat te herstellen.

er zijn eigenlijk twee veel voorkomende manieren om het vervelende probleem van het specificeren van het absolute pad naar de binaire bestanden op te lossen,
maar om ze te begrijpen moet u eerst weten dat uw shell de uitvoerbare bestanden lokaliseert door ze alleen te zoeken in de mappen die zijn opgegeven door de PATH omgevingsvariabele.

:~/node$ echo $PATH/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Hier, op dat Debian-systeem, als u niet expliciet een directory als onderdeel van de naam van een opdracht, de shell zal eerst zoeken naar het uitvoerbare programma ‘ s in /usr/local/bin, en als die niet gevonden worden in /usr/bin, dan, als niet gevonden in de /bin dan, als niet gevonden in de /usr/local/games dan, als niet gevonden in de /usr/games, en indien niet gevonden … de shell verslag een fout “command not found”.

gegeven dat we twee manieren hebben om een commando toegankelijk te maken voor de shell: door het toe te voegen aan een van de reeds geconfigureerde PATH mappen. Of door de map met ons uitvoerbare bestand toe te voegen aan de PATH.

het toevoegen van een link van /usr/local/bin

het kopiëren van het Binair uitvoerbare knooppunt van /opt/node/bin naar /usr/local/bin zou een slecht idee zijn, omdat het uitvoerbare programma hierdoor niet langer in staat zou zijn om de andere vereiste componenten te vinden die behoren tot /opt/node/ (Het is een gangbare praktijk voor software om zijn bronbestanden te lokaliseren ten opzichte van zijn eigen locatie).

de traditionele manier om dat te doen is door gebruik te maken van een symbolische link:

:~/node$ sudo ln -sT /opt/node/bin/node /usr/local/bin/node:~/node$ which -a node || echo not found/usr/local/bin/node:~/node$ node --versionv8.1.1 (compiled by myself)

Dit is een eenvoudige en effectieve oplossing, vooral als een softwarepakket is gemaakt van slechts enkele bekende uitvoerbare programma ‘ s— omdat je een symbolische link moet maken voor elke gebruiker-invokable Commando. Als u bijvoorbeeld bekend bent met NodeJS, kent u ook de npm companion applicatie I should symlink from /usr/local/bin. Maar ik liet dat aan jou toe als een oefening.

Wijzigen van de PAD

ten Eerste, als u hebt geprobeerd het vorige oplossing, het knooppunt verwijderen symbolische link gemaakt eerder te vertrekken vanuit een heldere staat:

:~/node$ sudo rm /usr/local/bin/node:~/node$ which -a node || echo not foundnot found

En nu, hier is het magische commando uit om het PATH:

:~/node$ export PATH="/opt/node/bin:${PATH}":~/node$ echo $PATH/opt/node/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Gewoon gezegd, ik was het vervangen van de inhoud van de PATH omgevingsvariabele door haar vorige inhoud, maar voorafgegaan door /opt/node/bin. Dus, zoals je je nu kunt voorstellen, zal de shell eerst in de /opt/node/bin map voor uitvoerbare programma ‘ s kijken. We kunnen bevestigen dat met behulp van de which Commando:

:~/node$ which -a node || echo not found/opt/node/bin/node:~/node$ node --versionv8.1.1 (compiled by myself)

terwijl de “link” oplossing permanent is zodra u de symbolische link naar /usr/local/bin hebt gemaakt, de PATH verandering alleen effectief is in de huidige shell. Ik laat u wat onderzoek doen naar het veranderen van dePATH permanents. Als een hint, het heeft te maken met uw “profiel”. Als u de oplossing vindt, aarzel dan niet om dat te delen met de andere lezers door gebruik te maken van de commentaarsectie hieronder!

E. Hoe te verwijderen die zojuist geïnstalleerde software van de source code

Sinds onze op maat samengesteld NodeJS software ligt volledig in de /opt/node-v8.1.1 map verwijderen die software vereist niet meer inspanning dan het gebruik van de rm commando verwijder deze map:

sudo rm -rf /opt/node-v8.1.1

LET op: sudo en rm -rf zijn een gevaarlijke cocktail! Controleer uw opdracht altijd twee keer voordat u op de “enter” – toets drukt. U hebt geen bevestigingsbericht en geen undelete als u de verkeerde map verwijdert…

dan, als u uw PATH hebt gewijzigd, moet u deze wijzigingen ongedaan maken, wat helemaal niet ingewikkeld is.

en als u links hebt aangemaakt vanuit /usr/local/bin moet u ze allemaal verwijderen:

:~/node$ sudo find /usr/local/bin \ -type l \ -ilname "/opt/node/*" \ -print -delete/usr/local/bin/node

wacht? Waar was de afhankelijkheid hel?

als laatste opmerking, als je leest over het compileren van je eigen aangepaste software, heb je misschien gehoord over de afhankelijkheid hel. Dit is een bijnaam voor die vervelende situatie waar voordat je een software succesvol kunt compileren, je eerst een vereiste bibliotheek moet compileren, die op zijn beurt een andere bibliotheek nodig heeft die op zijn beurt incompatibel kan zijn met een andere software die je al hebt geïnstalleerd.

een deel van de taak van de pakketbeheerders van uw distributie is om daadwerkelijk die afhankelijkheidshel op te lossen en ervoor te zorgen dat de verschillende software van uw systeem compatibele bibliotheken gebruikt en in de juiste volgorde geïnstalleerd is.

voor dit artikel heb ik er bewust voor gekozen om NodeJS te installeren omdat het vrijwel geen afhankelijkheden heeft. Ik zei “virtueel” omdat het in feite afhankelijkheden heeft. Maar de broncode van deze afhankelijkheden zijn aanwezig in de bron repository van het project (in de node/deps subdirectory), dus je hoeft ze niet handmatig te downloaden en te installeren.