Come installare il software dal codice sorgente ... e rimuoverlo in seguito

Breve: Questa guida dettagliata spiega come installare un programma dal codice sorgente in Linux e come rimuovere il software installato dal codice sorgente.

Uno dei maggiori punti di forza della tua distribuzione Linux è il suo gestore di pacchetti e il repository software associato. Con loro, hai tutti gli strumenti e le risorse necessarie per scaricare e installare un nuovo software sul tuo computer in modo completamente automatico.

Ma nonostante tutti i loro sforzi, i manutentori dei pacchetti non possono gestire ogni caso d'uso. Né possono confezionare tutto il software disponibile là fuori. Quindi ci sono ancora situazioni in cui dovrai compilare e installare un nuovo software da solo. Da parte mia, il motivo più comune, di gran lunga, devo compilare un po 'di software è quando ho bisogno di eseguire una versione molto specifica. O perché voglio modificare il codice sorgente o utilizzare alcune opzioni di compilazione fantasiose.

Se i tuoi bisogni appartengono a quest'ultima categoria, ci sono possibilità che tu sappia già quello che fai. Ma per la stragrande maggioranza degli utenti Linux, la compilazione e l'installazione di un software dalle fonti per la prima volta potrebbe sembrare una cerimonia di iniziazione: alquanto spaventosa; ma con la promessa di entrare in un nuovo mondo di possibilità e di far parte di una comunità privilegiata se la superi.

A. Installazione del software dal codice sorgente in Linux

E questo è esattamente quello che faremo qui. Per gli scopi di questo articolo, supponiamo di dover installare NodeJS 8.1.1 sul mio sistema. Quella versione esattamente. Una versione che non è disponibile dal repository Debian:

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

Ora, installare NodeJs su Ubuntu o Debian è piuttosto semplice se lo fai con il gestore dei pacchetti. Ma facciamolo tramite il codice sorgente.

Passaggio 1: Ottenere il codice sorgente da GitHub

Come molti progetti open source, le fonti di NodeJS possono essere trovate su GitHub: //github.com/nodejs/node

Quindi, andiamo direttamente lì.

Se non si ha familiarità con GitHub, git o qualsiasi altro sistema di controllo della versione degno di menzione del repository contiene la fonte corrente per il software, nonché una cronologia di tutte le modifiche apportate nel corso degli anni a quel software. Alla fine fino alla prima riga scritta per quel progetto. Per gli sviluppatori, mantenere quella storia ha molti vantaggi. Per noi oggi, il principale è che saremo in grado di ottenere le fonti per il progetto come lo erano in un dato momento. Più precisamente, sarò in grado di ottenere le fonti com'erano quando fu rilasciata la versione 8.1.1. Anche se ci sono state molte modifiche da allora.

Su GitHub, puoi usare il pulsante "succursale" per navigare tra diverse versioni del software. "Branch" e "tags" sono concetti in qualche modo correlati in Git. Fondamentalmente, gli sviluppatori creano "branch" e "tag" per tenere traccia degli eventi importanti nella cronologia del progetto, come quando iniziano a lavorare su una nuova funzione o quando pubblicano una versione. Non entrerò nei dettagli qui, tutto quello che devi sapere è che sto cercando la versione taggata "v8.1.1"

Dopo aver scelto il tag "v8.1.1", la pagina viene aggiornata, la modifica più evidente è che il tag viene ora visualizzato come parte dell'URL. Inoltre, noterai che la data di modifica del file è diversa. L'albero dei sorgenti che stai vedendo è quello esistente al momento della creazione del tag v8.1.1. In un certo senso, puoi pensare a uno strumento di controllo della versione come git come una macchina per il viaggio nel tempo, che ti consente di andare avanti e indietro nella cronologia di un progetto.

A questo punto, possiamo scaricare i sorgenti di NodeJS 8.1.1. Non puoi perdere il grande bottone blu che suggerisce di scaricare l'archivio ZIP del progetto. A partire da me, scaricherò ed estrarrò lo ZIP dalla riga di comando per motivi di spiegazione. Ma se preferisci usare uno strumento GUI, non esitare a farlo:

 wget //github.com/nodejs/node/archive/v8.1.1.zip unzip v8.1.1.zip cd node-8.1.1/ 

Il download dell'archivio ZIP funziona alla grande. Ma se vuoi farlo "come un professionista", ti suggerirei di usare direttamente lo strumento git per scaricare i sorgenti. Non è affatto complicato e sarà un bel primo contatto con uno strumento che incontrerai spesso:

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

A proposito, se hai qualche problema, considera questa prima parte di questo articolo come un'introduzione generale. Più avanti ho spiegazioni più dettagliate sulle distribuzioni basate su Debian e RedHat per aiutarti a risolvere i problemi più comuni.

Ad ogni modo, ogni volta che hai scaricato il sorgente usando git o come archivio ZIP, ora dovresti avere esattamente gli stessi file sorgente nella directory corrente:

 sh$ ls android-configure BUILDING.md common.gypi doc Makefile src AUTHORS CHANGELOG.md configure GOVERNANCE.md node.gyp test benchmark CODE_OF_CONDUCT.md CONTRIBUTING.md lib node.gypi tools BSDmakefile COLLABORATOR_GUIDE.md deps LICENSE README.md vcbuild.bat 

Passo 2: Capire il sistema di costruzione del programma

Di solito parliamo di "compilazione delle fonti", ma la compilazione è solo una delle fasi necessarie per produrre un software funzionante dalla sua origine. Un sistema di compilazione è un insieme di strumenti e pratiche utilizzati per automatizzare e articolare queste diverse attività al fine di costruire interamente il software semplicemente emettendo pochi comandi.

Se il concetto è semplice, la realtà è un po 'più complicata. Perché diversi progetti o linguaggio di programmazione possono avere requisiti diversi. O per i gusti del programmatore. O le piattaforme supportate. O per ragioni storiche. Oppure ... o ... c'è una lista quasi infinita di ragioni per scegliere o creare un altro sistema di costruzione. Tutto ciò per dire che ci sono molte soluzioni diverse utilizzate là fuori.

NodeJS utilizza un sistema di generazione in stile GNU. Questa è una scelta popolare nella comunità open source. E ancora una volta, un buon modo per iniziare il tuo viaggio.

Scrivere e mettere a punto un sistema di costruzione è un compito piuttosto complesso. Ma per gli "utenti finali", i sistemi di generazione in stile GNU riprendono a utilizzare due strumenti: configure e make .

Il file di configure è uno script specifico del progetto che verificherà la configurazione del sistema di destinazione e la funzionalità disponibile al fine di garantire che il progetto possa essere costruito, eventualmente affrontando le specificità della piattaforma corrente.

Una parte importante di un tipico lavoro di configure è la creazione del Makefile . Questo è il file contenente le istruzioni necessarie per costruire efficacemente il progetto.

Lo strumento make ), d'altra parte, è uno strumento POSIX disponibile su qualsiasi sistema simile a Unix. Legge il Makefile specifico del progetto ed esegue le operazioni necessarie per creare e installare il programma.

Ma, come sempre nel mondo Linux, hai ancora del tempo per personalizzare la build in base alle tue esigenze specifiche.

 ./configure --help 

Il comando configure -help ti mostrerà tutte le opzioni di configurazione disponibili. Ancora una volta, questo è molto specifico per il progetto. E per essere onesti, a volte è necessario scavare nel progetto prima di comprendere appieno il significato di ciascuna opzione di configurazione.

Ma esiste almeno un'opzione di Autotools GNU standard che è necessario conoscere: l'opzione --prefix . Questo ha a che fare con la gerarchia del file system e il luogo in cui verrà installato il software.

Step 3: L'FHS

La gerarchia del file system Linux su una distribuzione tipica è in gran parte conforme al Filesystem Hierarchy Standard (FHS)

Questo standard spiega lo scopo delle varie directory del tuo sistema: /usr, /tmp, /var e così via.

Quando si utilizza GNU Autotools- e la maggior parte degli altri sistemi di build, il percorso di installazione predefinito per il nuovo software sarà /usr/local . Quale è una buona scelta come da FSH "La gerarchia / usr / local è utilizzata dall'amministratore di sistema quando installa il software localmente? Deve essere sicuro di essere sovrascritto quando il software di sistema viene aggiornato. Può essere utilizzato per programmi e dati condivisibili tra un gruppo di host, ma non in / usr. "

La gerarchia /usr/local qualche modo replica la directory root, e troverai /usr/local/bin per i programmi eseguibili, /usr/local/lib per le librerie, /usr/local/share per i file indipendenti dall'architettura e così sopra.

L'unico problema quando si utilizza l'albero /usr/local per l'installazione del software personalizzato è che i file per tutto il software verranno mixati lì. Soprattutto, dopo aver installato un paio di software, sarà difficile rintracciare quale file esattamente di /usr/local/bin e /usr/local/lib appartiene a quale software. Tuttavia, ciò non causerà alcun problema al sistema. Dopo tutto, /usr/bin è quasi lo stesso casino. Ma questo diventerà un problema il giorno in cui vorrai rimuovere un software installato manualmente.

Per risolvere questo problema, di solito preferisco installare software personalizzato nella sub-albero /opt . Ancora una volta, per citare l'FHS:

_ "/ Opt è riservato per l'installazione di pacchetti software applicativi aggiuntivi.

Un pacchetto da installare in / opt deve individuare i suoi file statici in un albero di directory / opt / o / opt / separato, dove è un nome che descrive il pacchetto software ed è il nome registrato LANANA del provider. "_

Quindi creeremo una sottodirectory di /opt specificamente per la nostra installazione NodeJS personalizzata. E se un giorno volessi rimuovere quel software, dovrò semplicemente rimuovere quella directory:

 sh$ sudo mkdir /opt/node-v8.1.1 sh$ 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.1 sh$ 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. 

Tutto tranne "ok" dopo che il comando make è stato completato significherebbe che c'è stato un errore durante il processo di compilazione. Mentre eseguivamo una build parallela a causa dell'opzione -j, non è sempre facile recuperare il messaggio di errore dato il grande volume di output prodotto dal sistema di build.

In caso di problemi, riavvia make, ma senza l'opzione -j questa volta. E l'errore dovrebbe apparire vicino alla fine dell'output:

 sh$ make 

Infine, una volta terminata la compilazione, è possibile installare il software nella sua posizione eseguendo il comando:

 sh$ sudo make install 

E provalo:

 sh$ /opt/node/bin/node --version v8.1.1 

B. Cosa succede se le cose vanno male durante l'installazione dal codice sorgente?

Quello che ho spiegato sopra è principalmente ciò che si può vedere nella pagina "build instruction" di un progetto ben documentato. Ma dato l'obiettivo di questo articolo è quello di farti compilare il tuo primo software da fonti, potrebbe valere la pena dedicare del tempo ad indagare su alcuni problemi comuni. Quindi, farò di nuovo l'intera procedura, ma questa volta da un nuovo e minimo sistema Debian 9.0 e CentOS 7.0. Quindi puoi vedere l'errore che ho riscontrato e come li ho risolti.

Da Debian 9.0 "Stretch"

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

Questo problema è abbastanza facile da diagnosticare e risolvere. Basta installare il pacchetto git :

 [email protected]:~$ sudo apt-get install git 
 [email protected]:~$ git clone --depth 1 \ --branch v8.1.1 \ //github.com/nodejs/node && echo ok [...] ok 
 [email protected]:~/node$ sudo mkdir /opt/node-v8.1.1 [email protected]:~/node$ sudo ln -sT node-v8.1.1 /opt/node 

Nessun problema qui.

 [email protected]:~/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. 

Ovviamente, per compilare un progetto, hai bisogno di un compilatore. NodeJS viene scritto usando il linguaggio C ++, abbiamo bisogno di un compilatore C ++. Qui installerò `g ++`, il compilatore GNU C ++ per questo scopo:

 [email protected]:~/node$ sudo apt-get install g++ [email protected]:~/node$ ./configure --prefix=/opt/node-v8.1.1/ && echo ok [...] ok 
 [email protected]:~/node$ make -j9 && echo ok -bash: make: command not found 

Un altro strumento mancante. Stessi sintomi Stessa soluzione:

 [email protected]:~/node$ sudo apt-get install make [email protected]:~/node$ make -j9 && echo ok [...] ok 
 [email protected]:~/node$ sudo make install [...] [email protected]:~/node$ /opt/node/bin/node --version v8.1.1 

Successo!

Nota: ho installato i vari strumenti uno per uno per mostrare come diagnosticare i problemi di compilazione e per mostrarti la soluzione tipica per risolvere questi problemi. Ma se cerchi di più su quell'argomento o leggi altri tutorial, scoprirai che la maggior parte delle distribuzioni ha "meta-pacchetti" che fungono da ombrello per installare alcuni o tutti gli strumenti tipici usati per compilare un software. Sui sistemi basati su Debian, probabilmente incontrerai il pacchetto build-essentials a tale scopo. E sulle distribuzioni basate su Red Hat, questo sarà il gruppo "Strumenti di sviluppo" .

Da CentOS 7.0

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

Comando non trovato? Basta installarlo usando il gestore pacchetti yum :

 [[email protected] ~]$ sudo yum install git 
 [[email protected] ~]$ git clone --depth 1 \ --branch v8.1.1 \ //github.com/nodejs/node && echo ok [...] ok 
 [[email protected] ~]$ sudo mkdir /opt/node-v8.1.1 [[email protected] ~]$ sudo ln -sT node-v8.1.1 /opt/node 
 [[email protected] ~]$ cd node [[email protected] 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. 

Lo indovini: NodeJS è scritto usando il linguaggio C ++, ma il mio sistema manca del compilatore corrispondente. Yum in soccorso. Dato che non sono un normale utente CentOS, in realtà ho dovuto cercare su Internet il nome esatto del pacchetto contenente il compilatore g ++. Guidandomi verso quella pagina: //superuser.com/questions/590808/yum-install-gcc-g-doesnt-work-anymore-in-centos-6-4

 [[email protected] node]$ sudo yum install gcc-c++ [[email protected] node]$ ./configure --prefix=/opt/node-v8.1.1/ && echo ok [...] ok 
 [[email protected] node]$ make -j9 && echo ok [...] ok 
 [[email protected] node]$ sudo make install && echo ok [...] ok 
 [[email protected] node]$ /opt/node/bin/node --version v8.1.1 

Successo. Ancora.

C. Apportare modifiche al software installato dal codice sorgente

È possibile installare un software dall'origine perché è necessaria una versione molto specifica non disponibile nel repository di distribuzione. O perché vuoi modificare quel programma. O per correggere un bug o aggiungere una funzionalità. Dopotutto, l'open-source è tutto questo. Quindi colgo l'occasione per darti un assaggio del potere che hai a portata di mano ora sei in grado di compilare il tuo software.

Qui, faremo una piccola modifica alle fonti di NodeJS. E vedremo se il nostro cambiamento verrà incorporato nella versione compilata del software:

Apri il file node/src/node.cc nel tuo editor di testo preferito (vim, nano, gedit, ...). E prova a localizzare quel frammento di codice:

  if (debug_options.ParseOption(argv[0], 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); } 

È intorno alla riga 3830 del file. Quindi modifica la riga contenente printf per abbinarla a quella:

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

Quindi torna al tuo terminale. Prima di andare oltre, e per darti un'idea più approfondita del potere dietro git, puoi controllare se hai modificato il file giusto:

 diff --git a/src/node.cc b/src/node.cc index 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[0], 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(); 

Dovresti vedere un "-" (segno meno) prima della linea così come lo era prima di cambiarlo. E un "+" (segno più) prima della linea dopo le modifiche.

È giunto il momento di ricompilare e reinstallare il software:

 make -j9 && sudo make install && echo ok [...] ok 

Questa volta, l'unica ragione per cui potrebbe fallire è che hai fatto un refuso durante la modifica del codice. In tal caso, riaprire il file node/src/node.cc nell'editor di testo e correggere l'errore.

Una volta che sei riuscito a compilare e installare la nuova versione di NodeJS modificata, sarai in grado di verificare se le tue modifiche sono state effettivamente incorporate nel software:

 [email protected]:~/node$ /opt/node/bin/node --version v8.1.1 (compiled by myself) 

Congratulazioni! Hai fatto la tua prima modifica ad un programma open-source!

D. Lascia che la shell localizzi il nostro software di build personalizzato

Potresti aver notato fino ad ora, ho sempre lanciato il mio software NodeJS appena compilato specificando il percorso assoluto del file binario.

 /opt/node/bin/node 

Funziona. Ma questo è fastidioso, per non dire altro. Ci sono in realtà due modi comuni per risolverlo. Ma per capirli, devi prima sapere che la tua shell individua i file eseguibili cercandoli solo nelle directory specificate dalla variabile d'ambiente PATH .

 [email protected]:~/node$ echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games 

Qui, su quel sistema Debian, se non si specifica esplicitamente alcuna directory come parte di un nome comando, la shell cercherà prima quei programmi eseguibili in /usr/local/bin, quindi se non si trova in /usr/bin, allora se non si trova in /bin allora se non si trova in /usr/local/games se non si trova in /usr/games, se non trovato ... la shell riporta un errore "comando non trovato" .

Detto questo, abbiamo due modi per rendere un comando accessibile alla shell: aggiungendolo a una delle directory PATH già configurate. O aggiungendo la directory contenente il nostro file eseguibile al PATH .

Aggiunta di un collegamento da / usr / local / bin

Copiare semplicemente il file binario eseguibile da /opt/node/bin a /usr/local/bin sarebbe una cattiva idea dato che così facendo, il programma eseguibile non sarebbe più in grado di localizzare gli altri componenti richiesti appartenenti a /opt/node/ (È prassi comune per un software individuare i suoi file di risorse in relazione alla propria posizione).

Quindi, il modo tradizionale di farlo è usando un link simbolico:

 [email protected]:~/node$ sudo ln -sT /opt/node/bin/node /usr/local/bin/node [email protected]:~/node$ which -a node || echo not found /usr/local/bin/node [email protected]:~/node$ node --version v8.1.1 (compiled by myself) 

Questa è una soluzione semplice ed efficace, specialmente se un pacchetto software è costituito da pochi programmi eseguibili ben noti, poiché è necessario creare un collegamento simbolico per ogni singolo comando invocato dall'utente. Ad esempio, se si ha familiarità con NodeJS, si conosce l'applicazione companion npm Dovrei fare il symlink da /usr/local/bin . Ma ti ho lasciato questo come esercizio.

Modifica del PERCORSO

Innanzitutto, se hai provato la soluzione precedente, rimuovi il collegamento simbolico del nodo creato in precedenza per iniziare da uno stato chiaro:

 [email protected]:~/node$ sudo rm /usr/local/bin/node [email protected]:~/node$ which -a node || echo not found not found 

E ora, ecco il comando magico per cambiare il PATH :

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

Detto semplicemente, ho sostituito il contenuto della variabile d'ambiente PATH con il suo contenuto precedente, ma prefisso da /opt/node/bin . Quindi, come potete immaginare ora, la shell guarderà prima nella directory /opt/node/bin per i programmi eseguibili. Possiamo confermare che usando il comando which :

 [email protected]:~/node$ which -a node || echo not found /opt/node/bin/node [email protected]:~/node$ node --version v8.1.1 (compiled by myself) 

Mentre la soluzione "link" è permanente non appena hai creato il link simbolico in /usr/local/bin, la modifica PATH è efficace solo nella shell corrente. Ti lascio fare alcune ricerche da solo per sapere come apportare modifiche ai permanenti del PATH . Come suggerimento, ha a che fare con il tuo "profilo". Se trovi la soluzione, non esitare a condividerlo con gli altri lettori usando la sezione commenti qui sotto!

E. Come rimuovere il software appena installato dal codice sorgente

Poiché il nostro software NodeJS compilato su misura si trova completamente nella directory /opt/node-v8.1.1, rimuovere quel software non è più un lavoro che usare il comando rm per rimuovere quella directory:

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

ATTENZIONE: sudo e rm -rf sono un cocktail pericoloso! Controlla sempre il tuo comando due volte prima di premere il tasto "Invio". Non avrai alcun messaggio di conferma e non sarai eliminato se rimuovi la directory sbagliata ...

Quindi, se hai modificato il PATH, dovrai annullare tali modifiche. Il che non è affatto complicato.

E se hai creato collegamenti da /usr/local/bin dovrai rimuoverli tutti:

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

Aspettare? Dov'era l'inferno Dipendenza?

Come commento finale, se leggi di compilare il tuo software personalizzato, potresti aver sentito parlare dell'inferno della dipendenza. Questo è un soprannome per quella noiosa situazione in cui prima di poter compilare con successo un software, è necessario prima compilare una libreria pre-requisito, che a sua volta richiede un'altra libreria che a sua volta potrebbe essere incompatibile con qualche altro software che hai già installato.

Parte del lavoro dei manutentori di pacchetti della tua distribuzione è di risolvere effettivamente questo problema di dipendenza e di assicurare che i vari software del tuo sistema utilizzino le librerie compatibili e siano installati nell'ordine corretto.

In quell'articolo, ho scelto apposta di installare NodeJS perché praticamente non ha dipendenze. Ho detto "virtualmente" perché, in effetti, ha delle dipendenze. Ma il codice sorgente di queste dipendenze è presente nel repository di origine del progetto (nella sottodirectory node/deps ), quindi non è necessario scaricarlo e installarlo manualmente prima della mano.

Ma se sei interessato a capire di più su questo problema e imparare come gestirlo, fammi sapere che usando la sezione commenti qui sotto: questo sarebbe un grande argomento per un articolo più avanzato!

Raccomandato

4 migliori strumenti gratuiti e open source per l'elaborazione di immagini RAW in Linux
2019
NVIDIA termina il supporto per i sistemi operativi a 32 bit
2019
I migliori editor di testo per Linux Command Line
2019