Brief: ten szczegółowy przewodnik wyjaśnia, w jaki sposób aby zainstalować program z kodu źródłowego w Linuksie i jak usunąć zainstalowane oprogramowanie z kodu źródłowego.

jedną z największych zalet twojej dystrybucji Linuksa jest menedżer pakietów i powiązane z nim repozytorium oprogramowania. Dzięki nim masz wszystkie niezbędne narzędzia i zasoby, aby pobrać i zainstalować nowe oprogramowanie na komputerze w całkowicie zautomatyzowany sposób.

ale pomimo wszystkich wysiłków, opiekunowie pakietów nie mogą obsłużyć każdego przypadku użycia. Nie mogą też spakować całego dostępnego tam oprogramowania. Tak więc nadal istnieją sytuacje, w których będziesz musiał samodzielnie skompilować i zainstalować nowe oprogramowanie. Jeśli chodzi o mnie, najczęstszym powodem, zdecydowanie, muszę skompilować niektóre oprogramowanie, jest to, gdy muszę uruchomić bardzo konkretną wersję lub zmodyfikować kod źródłowy za pomocą niektórych fantazyjnych opcji kompilacji.

Jeśli Twoje potrzeby należą do tej drugiej kategorii, prawdopodobnie już wiesz, co robić. Jednak dla zdecydowanej większości użytkowników Linuksa, kompilacja i instalacja oprogramowania z kodu źródłowego po raz pierwszy może wyglądać jak ceremonia inicjacji: nieco przerażająca, ale z obietnicą wejścia w nowy świat możliwości i prestiżowego miejsca w uprzywilejowanej społeczności.

A. instalacja oprogramowania z kodu źródłowego w Linuksie

i dokładnie to zrobimy tutaj. Na potrzeby tego artykułu, powiedzmy, że muszę zainstalować NodeJS 8.1.1 w moim systemie. Dokładnie ta wersja. Wersja, która nie jest dostępna z repozytorium Debiana:

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

teraz instalacja NodeJs na Ubuntu lub Debianie jest dość prosta, jeśli robisz to za pomocą menedżera pakietów. Ale zróbmy to za pomocą kodu źródłowego.

Krok 1: pobranie kodu źródłowego z GitHub

podobnie jak wiele projektów open-source, źródła NodeJS można znaleźć na GitHub:https://github.com/nodejs/node

więc przejdźmy tam bezpośrednio.

Jeśli nie jesteś zaznajomiony z GitHub, git lub innym systemem kontroli wersji warto wspomnieć, że repozytorium zawiera aktualne źródło dla oprogramowania, a także historię jego działania.wszystkie modyfikacje wprowadzone przez lata do tego oprogramowania. Ostatecznie aż do pierwszego wiersza napisanego dla tego projektu. Dla programistów zachowanie tej historii ma wiele zalet. Dla nas dzisiaj głównym jest to, że będziemy mogli uzyskać źródła dla projektu w takim stanie, w jakim były w danym momencie. Dokładniej, będę w stanie uzyskać źródła takie, jakie były, gdy wydana została wersja 8.1.1, którą chcę. Nawet jeśli było wiele modyfikacji od tego czasu.

na Githubie możesz użyć przycisku „branch”, aby nawigować między różnymi wersjami oprogramowania. „Branch” i „tags” są w pewnym stopniu pokrewnymi pojęciami w Gita. Zasadniczo programiści tworzą ” gałąź „i” tagi”, aby śledzić ważne wydarzenia w historii projektu, takie jak rozpoczęcie pracy nad nową funkcją lub opublikowanie wydania. Nie będę wchodzić w szczegóły tutaj, wszystko, co musisz wiedzieć, to Szukam wersji oznaczonej „v8.1.1”

Po wybraniu na „V8.1.1 ” tag, strona jest odświeżona, najbardziej oczywistą zmianą jest to, że tag pojawia się teraz jako część adresu URL. Ponadto zauważysz, że Data zmiany pliku jest inna. Drzewo źródłowe, które teraz widzisz, to drzewo, które istniało w czasie tworzenia tagu v8.1.1. W pewnym sensie możesz myśleć o narzędziu do kontroli wersji, takim jak git, jak o maszynie podróżującej w czasie, pozwalającej na przechodzenie w tę iz powrotem do historii projektu.

w tym momencie możemy pobrać źródła NodeJS 8.1.1. Nie możesz przegapić dużego niebieskiego przycisku sugerującego pobranie archiwum ZIP projektu. Jeśli chodzi o mnie, pobieram i rozpakowuję ZIP z wiersza poleceń dla wyjaśnienia. Ale jeśli wolisz używać narzędzia GUI, nie wahaj się tego zrobić:

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

pobieranie archiwum ZIP działa świetnie. Ale jeśli chcesz to zrobić „jak profesjonalista”, sugerowałbym użycie bezpośrednio narzędzia git, aby pobrać źródła. Nie jest to wcale skomplikowane-i będzie to miły pierwszy kontakt z narzędziem, które często napotkasz:

# 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/

przy okazji, jeśli masz problem, po prostu rozważ pierwszą część tego artykułu jako ogólne wprowadzenie. Później mam bardziej szczegółowe wyjaśnienia dotyczące dystrybucji opartych na Debianie i Redhacie, aby pomóc ci w rozwiązywaniu typowych problemów.

w każdym razie, gdy pobierasz Źródło za pomocą git lub jako archiwum ZIP, powinieneś teraz mieć dokładnie te same pliki źródłowe w bieżącym katalogu:

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

Krok 2: zrozumienie systemu kompilacji programu

zwykle mówimy o „kompilacji źródeł”, ale kompilacja jest tylko jedną z faz kompilacji.wymagane do wyprodukowania działającego oprogramowania z jego źródła. System kompilacji to zestaw narzędzi i praktyk używanych do automatyzacji i wyrażania tych różnych zadań w celu zbudowania całkowicie oprogramowania tylko przez wydawanie kilku poleceń.

jeśli koncepcja jest prosta, rzeczywistość jest nieco bardziej skomplikowana. Ponieważ różne projekty lub język programowania mogą mieć różne wymagania. Lub ze względu na gusta programisty. Lub obsługiwane platformy. Albo z przyczyn historycznych. Albo … albo.. istnieje prawie nieskończona lista powodów, dla których warto wybrać lub stworzyć inny system budowania. Wszystko to powiedzieć, że istnieje wiele różnych rozwiązań stosowanych tam.

NodeJS używa systemu budowania w stylu GNU, jest popularnym wyborem w społeczności open source i po raz kolejny dobrym sposobem na rozpoczęcie podróży.

pisanie i dostrajanie systemu budowania jest dość złożonym zadaniem, ale dla „użytkownika końcowego”, systemy budowania w stylu GNU ułatwiają zadanie za pomocą dwóch narzędzi:configure Imake.

plik configure jest specyficznym dla projektu skryptem, który sprawdzi konfigurację docelowego systemu i dostępną funkcję w celu zapewnienia, że projekt może zostać zbudowany, ostatecznie zajmując się specyfikacją obecnej platformy.

ważną częścią typowego zadaniaconfigure jest zbudowanieMakefile. Jest to plik zawierający instrukcje wymagane do skutecznego zbudowania projektu.

narzędziemake jest narzędziem POSIX dostępnym na każdym systemie Uniksopodobnym. Odczyta on specyficzny dla projektu Makefile I wykona wymagane operacje do zbudowania i zainstalowania programu.

ale, jak zawsze w świecie Linuksa, nadal masz trochę wyrozumiałości w dostosowywaniu kompilacji do swoich konkretnych potrzeb.

./configure --help

polecenieconfigure -help pokaże wszystkie dostępne opcje konfiguracji. Po raz kolejny, jest to bardzo specyficzne dla projektu. I szczerze mówiąc, czasami konieczne jest zagłębienie się w projekt przed pełnym zrozumieniem znaczenia każdej opcji konfiguracji.

ale jest przynajmniej jedna standardowa opcja GNU Autotools, którą musisz znać: --prefix opcja. Ma to związek z hierarchią systemu plików i miejscem instalacji oprogramowania.

Krok 3: FHS

hierarchia systemów plików Linuksa w typowej dystrybucji jest w większości zgodna ze standardem hierarchii systemów plików (FHS)

ten standard wyjaśnia przeznaczenie różnych katalogów systemu:/usr/tmp/var I tak dalej.

podczas korzystania z GNU Autotools— i większości innych systemów kompilacji— domyślną lokalizacją instalacji nowego oprogramowania będzie /usr/local. Co jest dobrym wyborem, ponieważ według FSH „hierarchia /usr/local jest używana przez administratora systemu podczas instalacji oprogramowania lokalnie? Musi być bezpieczny przed nadpisaniem po aktualizacji oprogramowania systemowego. Może być używany do programów i danych, które można udostępnić grupie hostów, ale nie można ich znaleźć w /usr.”

hierarchia/usr/local w jakiś sposób replikuje katalog główny i znajdziesz tam /usr/local/bin dla programów wykonywalnych, /usr/local/lib dla bibliotek, /usr/local/share dla plików niezależnych od architektury i tak dalej.

jedynym problemem podczas korzystania z drzewa /usr/local dla niestandardowej instalacji oprogramowania jest to, że pliki dla całego oprogramowania będą tam mieszane. Szczególnie, po zainstalowaniu kilku programów, trudno będzie śledzić, do którego dokładnie pliku /usr/local/bin I /usr/local/lib należy do którego oprogramowania. Nie spowoduje to jednak żadnego problemu z systemem. W końcu /usr/bin to prawie ten sam bałagan. Ale stanie się to problemem w dniu, w którym będziesz chciał usunąć ręcznie zainstalowane oprogramowanie.

aby rozwiązać ten problem, zwykle wolę zainstalować niestandardowe oprogramowanie w /opt sub-drzewie. Po raz kolejny cytując FHS:

_”/opt jest zarezerwowany do instalacji dodatkowych pakietów oprogramowania.

pakiet, który ma być zainstalowany w /opt, musi zlokalizować swoje pliki statyczne w oddzielnym /opt/<pakiet> lub /opt/<dostawca> drzewo katalogów, gdzie<pakiet> to nazwa, która opisuje pakiet oprogramowania, a<dostawca> to zarejestrowana nazwa dostawcy lanana.”_

stworzymy więc podkatalog /opt specjalnie dla naszej niestandardowej instalacji NodeJS. A jeśli kiedyś chcę usunąć to oprogramowanie, będę musiał po prostu usunąć ten katalog:

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.

wszystko poza „ok” po zakończeniu polecenia make oznaczałoby błąd podczas procesu kompilacji. Ponieważ uruchomiliśmy kompilację równoległą z powodu opcji-j, nie zawsze jest łatwo odzyskać komunikat o błędzie, biorąc pod uwagę dużą ilość danych wyjściowych generowanych przez system kompilacji.

w przypadku problemu po prostu uruchom ponownie make, ale tym razem bez opcji -j. Błąd powinien pojawić się na końcu wyjścia:

sh$ make

wreszcie, gdy kompilacja dobiegnie końca, możesz zainstalować oprogramowanie w jego lokalizacji, uruchamiając polecenie:

sh$ sudo make install

i przetestować:

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

B. Co zrobić, jeśli coś pójdzie nie tak podczas instalacji z kodu źródłowego?

to, co wyjaśniłem powyżej, to głównie to, co można zobaczyć na stronie „Instrukcja budowania” dobrze udokumentowanego projektu. Ale biorąc pod uwagę ten artykuł celem jest umożliwienie kompilacji pierwszego oprogramowania ze źródeł, warto poświęcić trochę czasu na zbadanie niektórych typowych problemów. Tak więc, zrobię całą procedurę ponownie, ale tym razem ze świeżych i minimalnych systemów Debian 9.0 i CentOS 7.0, abyś mógł zobaczyć błędy, które napotkałem i jak je rozwiązałem.

od Debiana 9.0 „Stretch”

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

ten problem jest dość łatwy do zdiagnozowania i rozwiązania. Wystarczy zainstalowaćgit pakiet:

:~$ 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

nie ma problemu.

:~/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.

oczywiście, aby skompilować projekt, potrzebujesz kompilatora. NodeJS jest napisany przy użyciu języka C++, potrzebujemy kompilatora C++. Tutaj zainstaluję` g++’, kompilator GNU C++ do tego celu:

:~/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

jeszcze jedno brakujące narzędzie. Te same objawy. To samo rozwiązanie:

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

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

sukces!

proszę zwrócić uwagę: Zainstalowałem różne narzędzia jeden po drugim, aby pokazać, jak diagnozować problemy z kompilacją i pokazać typowe rozwiązanie, aby rozwiązać te problemy. Ale jeśli poszukasz więcej informacji na ten temat lub przeczytasz inne samouczki, odkryjesz, że większość dystrybucji ma „meta-Pakiety” działające jako parasol do instalacji niektórych lub wszystkich typowych narzędzi używanych do kompilacji oprogramowania. W systemach opartych na Debianie prawdopodobnie napotkasz pakiet build-essentials w tym celu. A na dystrybucjach opartych na Red-hacie będzie to grupa „narzędzia programistyczne”.

od CentOS 7.0

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

polecenie nie zostało znalezione? Po prostu zainstaluj go za pomocą yum menedżer pakietów:

 ~]$ 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.

zgadujesz: NodeJS jest napisany w języku C++, ale w moim systemie brakuje odpowiedniego kompilatora. Mniam na ratunek. Ponieważ nie jestem zwykłym użytkownikiem CentOS, musiałem poszukać w Internecie dokładnej nazwy pakietu zawierającego kompilator g++. Prowadzi mnie do tej strony: 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

sukces. Jeszcze raz.

C. wprowadzanie zmian w oprogramowaniu zainstalowanym z kodu źródłowego

możesz zainstalować oprogramowanie ze źródła, ponieważ potrzebujesz bardzo specyficznej wersji niedostępnej w repozytorium dystrybucji lub chcesz zmodyfikować program, aby naprawić błąd lub dodać funkcję. W końcu open-source polega na wprowadzaniu modyfikacji. Skorzystam więc z tej okazji, aby dać wam przedsmak mocy, którą macie pod ręką teraz, gdy jesteście w stanie skompilować własne oprogramowanie.

tutaj dokonamy drobnej zmiany w źródłach NodeJS. I zobaczymy, czy nasza zmiana zostanie włączona do skompilowanej wersji oprogramowania:

Otwórz plik node/src/node.cc w swoim ulubionym edytorze tekstu (vim, nano, gedit, … ). I spróbuj zlokalizować ten fragment kodu:

 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); }

znajduje się wokół linii 3830 pliku. Następnie zmodyfikuj linię zawierającą printf, aby pasowała do tej linii:

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

następnie wróć do swojego terminala. Zanim przejdziesz dalej – i aby dać ci więcej wglądu w moc Gita – możesz sprawdzić, czy zmodyfikowałeś odpowiedni plik:

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();

powinieneś zobaczyć „-” (znak minus) przed wierszem, tak jak to było przed zmianą. I ” + ” (znak plus) przed linią po zmianach.

nadszedł czas, aby przekompilować i ponownie zainstalować oprogramowanie:

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

tym razem jedynym powodem, dla którego może się nie udać, jest to, że Zrobiłeś literówkę podczas zmiany kodu. W takim przypadku otwórz ponownie plik node/src/node.cc w edytorze tekstu i napraw błąd.

po skompilowaniu i zainstalowaniu nowej zmodyfikowanej wersji NodeJS będziesz mógł sprawdzić, czy Twoje modyfikacje zostały faktycznie włączone do oprogramowania:

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

Gratulacje! Dokonałeś pierwszej zmiany w programie open-source!

D. niech powłoka zlokalizuje nasze własne oprogramowanie do budowania

być może zauważyłeś, że zawsze uruchamiałem moje nowo skompilowane oprogramowanie NodeJS, określając bezwzględną ścieżkę do pliku binarnego.

/opt/node/bin/node

działa. Ale to jest co najmniej denerwujące. Istnieją dwa powszechne sposoby naprawienia tego problemu.

istnieją dwa powszechne sposoby naprawienia irytującego problemu z określeniem bezwzględnej ścieżki do plików binarnych,
ale aby je zrozumieć, musisz najpierw wiedzieć, że Twoja powłoka lokalizuje pliki wykonywalne, szukając ich tylko w katalogach określonych przez zmienną środowiskową PATH.

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

tutaj, na tym systemie Debian, jeśli nie podasz jawnie żadnego katalogu jako części nazwy polecenia, powłoka najpierw będzie szukać programów wykonywalnych w /usr/local/bin, następnie jeśli nie zostanie znaleziony w /usr/bin, wtedy jeśli nie zostanie znaleziony w /usr/local/bin/bin then if not found into/usr/local/games then if not found into/usr/games, then if not found … powłoka zgłosi błąd”command not found”.

biorąc pod uwagę, że mamy dwa sposoby, aby polecenie było dostępne dla powłoki: poprzez dodanie go do jednego z już skonfigurowanych katalogówPATH. Lub poprzez dodanie katalogu zawierającego nasz plik wykonywalny do PATH.

dodanie linku z /usr/local/bin

samo skopiowanie binarnego pliku wykonywalnego węzła z /opt/node/bin do /usr/local/bin byłoby złym pomysłem, ponieważ w ten sposób program wykonywalny nie byłby już w stanie zlokalizować innych wymaganych komponentów należących do /opt/node/ div > (jest to powszechna praktyka dla oprogramowania, aby zlokalizować swoje pliki zasobów w stosunku do własnej lokalizacji).

tak więc tradycyjnym sposobem jest użycie dowiązania symbolicznego:

:~/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)

jest to proste i skuteczne rozwiązanie, zwłaszcza jeśli pakiet oprogramowania składa się z zaledwie kilku znanych programów wykonywalnych— ponieważ trzeba utworzyć dowiązanie symboliczne dla każdego użytkownika-invokable polecenia. Na przykład, jeśli znasz NodeJS, znasznpm aplikacja towarzysząca, którą powinienem połączyć symbolicznie z/usr/local/bin. Ale pozwoliłem ci to jako ćwiczenie.

modyfikowanie ścieżki

Po pierwsze, jeśli próbowałeś poprzedniego rozwiązania, Usuń dowiązanie symboliczne węzła utworzone wcześniej, aby rozpocząć od stanu czystego:

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

a teraz, oto magiczne polecenie do zmianyPATH:

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

po prostu zastąpiłem zawartość zmiennej środowiskowej PATHjej poprzednią zawartością, ale poprzedzoną /opt/node/bin. Tak więc, jak możesz sobie teraz wyobrazić, powłoka będzie najpierw szukać w katalogu/opt/node/bin dla programów wykonywalnych. Możemy potwierdzić, że używając poleceniawhich:

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

podczas gdy rozwiązanie „link” jest trwałe, gdy tylko utworzysz dowiązanie symboliczne w /usr/local/binPATH Zmień działa tylko w bieżącej powłoce. Zostawię was, abyście zrobili kilka badań, jak wprowadzić zmiany wPATH. Jako podpowiedź, ma to związek z Twoim „profilem”. Jeśli znajdziesz rozwiązanie, nie wahaj się podzielić tym z innymi czytelnikami, korzystając z sekcji komentarzy poniżej!

E. Jak usunąć nowo zainstalowane oprogramowanie z kodu źródłowego

ponieważ nasze niestandardowe skompilowane oprogramowanie NodeJS znajduje się całkowicie w katalogu /opt/node-v8.1.1, usunięcie tego oprogramowania nie wymaga większego wysiłku niż użycie polecenia rm, aby usunąć ten katalog:

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

uważaj: sudo Irm -rf to niebezpieczny koktajl! Zawsze Sprawdź swoje polecenie dwa razy przed naciśnięciem klawisza „enter”. Jeśli usuniesz niewłaściwy katalog …

wtedy, jeśli zmodyfikowałeś swój PATH, będziesz musiał cofnąć te zmiany, co nie jest wcale skomplikowane.

a jeśli utworzyłeś linki z/usr/local/bin będziesz musiał je wszystkie usunąć:

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

czekać? Gdzie było piekło zależności?

jako ostatni komentarz, jeśli czytasz o kompilowaniu własnego oprogramowania, być może słyszałeś o piekle zależności. Jest to pseudonim dla tej irytującej sytuacji, w której zanim będziesz w stanie pomyślnie skompilować oprogramowanie, musisz najpierw skompilować wymaganą bibliotekę, która z kolei wymaga innej biblioteki, która z kolei może być niezgodna z innym oprogramowaniem, które już zainstalowałeś.

częścią pracy opiekunów pakietów twojej dystrybucji jest naprawienie tego piekła zależności i upewnienie się, że różne programy Twojego systemu używają kompatybilnych bibliotek i są zainstalowane we właściwej kolejności.

w tym artykule celowo zdecydowałem się zainstalować Nodejsa, ponieważ praktycznie nie ma zależności. Powiedziałem „wirtualnie”, ponieważ w rzeczywistości ma zależności. Ale kod źródłowy tych zależności jest obecny w repozytorium źródłowym projektu (w podkatalogunode/deps), więc nie musisz pobierać i instalować ich ręcznie przed ręką.