Anleitung für Software „build/install from source“

Hey Leute,

mich interessiert, wie ich mit Software umgehe, die ich selbst baue/kompiliere/installiere (ich weiß nicht, ob sich die Begriffe in diesem Kontext unterscheiden), konkret geht es natürlich wieder um Neovim aber für meine Fragen sollte das nur von untergeordneter Bedeutung sein.

Man kann Neovim per Install from source installieren. Die Anleitung verstehe ich, mich interessiert ob ich ein GitHub-Repository mit Code, den ich selbst baue, in ein bestimmtes Verzeichnis klonen sollte oder nicht. Meine Recherche im Internet hat ergeben, dass für externe Programme /opt oder /usr/bin in Frage kommen aber mir sind die Unterschiede nicht klar und allgemein habe ich irgendwie nichts Konkretes (bspw. einen ausführlichen Blogeintrag oder Forumseintrag gefunden).
Ich kann mir auch vorstellen, dass es an sich egal ist, wohin man ein GitHub-Repo klont, dass [c]make den „Rest“ erledigt und ich nach Abschluss ganz normal nvim nutzen kann.

Mich interessiert im Zuge dessen auch, wie ich über neue Versionen informiert werde oder ob ich mich darum selbst kümmern muss. Auf GitHub kann man sich zwar über neue Release-Versionen benachrichtigen lassen aber im Falle von Neovim erhalte ich über diesen Kanal (alle ein bis zwei Tage) auch Informationen über neue Nightly-/Entwicklungsversionen, die mich weniger interessieren. Mich würde es deswegen freuen, wenn mir jemand verraten könnte, wie ich leicht an die Ankündigung einer neuen Vollversion gelange.

Zur Vollständigkeit: Gegenwärtig nutze ich Neovim per Install from package.

Bitte antwortet mir erst am Abend und genießt tagsüber das schöne Wetter – viele Frühlingstage gab’s dieses Jahr leider noch nicht! :smiley:

baue/kompiliere/installiere.

Die ersten Zwei sollten mehr oder weniger Synonyme sein, beim letzten würde ich sagen geht es darum Software auf einem ganzen System zugänglich zu machen.

Oft findet man in Anleitungen das Muster

$ make 
# make install 

Das erste baut die Software im aktuellem Verziechniss, und es sollte egal sein wo das ist (im home directory, /opt, /proj/ciptmp/$USER, etc.). Daher kann es auch als normaler Benuzer ausgeführt werden.

Bei dem zweiten Befehl werden dann die gebauten Programme und sonstigen Dateien aus dem lokalen Verzeichnis, irgendwo hin kopiert wo es alle Benutzer sehen können, ohne dass es im Konflikt steht mit anderer Software (/usr/local/). Alternativ kann man Software auch nur für ein Benutzer installieren (~/.local/). Ob das notwendig ist hängt von der Software ab (ich bau Emacs from source, und kann es direkt aus dem Git repo ausführen, welches in meinem PATH liegt, ggf. geht das auch für Neovim?).

Wie man das genau macht, hängt vom Build-System eines Projekts ab. Leider benutzen ja nicht alle Make ;^).

Im Neovim README, welches du verlinks, scheint alles zu stehen, was man wissen muss.

Mich interessiert im Zuge dessen auch, wie ich über neue Versionen informiert werde oder ob ich mich darum selbst kümmern muss. […] Mich würde es deswegen freuen, wenn mir jemand verraten könnte, wie ich leicht an die Ankündigung einer neuen Vollversion gelange.

Normalerweise hat man da eine andere Einstellung, wenn man Upstream direkt trackt. Dich interessieren die konkreten Versionen nicht mehr so sehr, sondern man hat eine rolling-release perspektive. IMO zumindest. Man kann aber auch immer nur git fetch ausfüren, schauen ob neue tags angekündigt werden und dann die auschecken.

Bitte antwortet mir erst am Abend und genießt tagsüber das schöne Wetter – viele Frühlingstage gab’s dieses Jahr leider noch nicht! :smiley:

Oops

Alles klar! Ergibt auch irgendwo Sinn, dass man die Pfade nicht selbst festlegen muss, möchte man Software selbst kompilieren, aber hinterher ist man immer schlauer.

Es klappt zu Mindest mit meiner jetzigen Installation als Paket, weil ich diesbezüglich auch PATH um das passende Neovim-Verzeichnis ergänzt habe.
Ich habe Neovim mal probeweise in einer VM kompiliert und installiert und dort kann ich es ohne zusätzliche Schritte direkt per nvim starten.
Edit: Hat nun alles auch außerhalb der VM reibungslos funktioniert :slight_smile:

Hast du in solchen Fällen einen cron-Job gesetzt, der regelmäßig pullt, kompiliert und dann installiert? Irgendwie möchte man ja ohne die Schritte jedes Mal manuell wiederholen zu müssen um an die neuen Versionen/Commits kommen und zu warten bis installiert (oder aktualisiert) wurde, weil das relativ lange dauern kann.
Ich verstehe die Einstellung (wenn man voraussetzt, dass bei Entwicklungsversionen wahrscheinlich nur die neuen Mechaniken Probleme verursachen können und die Alten weiterhin funktionieren), weil ich es mir ein bisschen umständlich vorstelle nur bestimmte Versionen zu filtern (meine git-Fertigkeiten sind dafür noch nicht ausreichend).

Also ich bau nicht unbedingt meine Desktopsoftware vom Source, aber ich hoste einige Open Source Projekte selber, und hab mir dafuer ein entsprechendes (zugegeben primitives) Script gebaut…

#!~/bin/bash

set -exu

test "$(cd source-code-ordner && git pull)" = "Already up to date." && exit 0

# Whatever you need to do to build the software here

# Whatever you need to do to install the software here

Auf einem Desktop muss man sich vielleicht was besseres ueberlegen, weil der ja nicht immer an ist, und cron auf einer Uhrzeit basiert… Und das script baut halt immer den aktuellen branch (z.B. master oder main), ich weiss nicht wie neovim das managed, aber manche Software hat einen extra Release Branch, den man fuer sowas missbrauchen koennte…

Man könnte auch anacron verwenedn und alles einmal pro Woche/Monat durchführen (wie man eben möchte). Dein Skript(vorschlag) entspricht meiner naiven Vorstellung, wie man das Problem angehen würde, dann war ich auf jeden Fall nicht auf dem Holzweg.

Neovim verwendet stable-Tags, um Vollversionen zu markieren. Prinzipiell bin ich vor allem an einer allgemeinen Herangehensweise interessiert, um auch andere Projekte selbst kompilieren und installieren zu können aber es ist immer gut ein Beispiel zur Hand zu haben. :smiley:

Wenns dir wirklich um was automagisches geht, ist das gar nicht so einfach… Jedes Programm macht das ja etwas anders, und es gibt keine wirkliche Allgemeine loesung…

Deswegen gibt es ja AUR und Gentoo Repositories…
Beides baut selber (meistens vom Sourcecode) und installiert das dann, aber trotzdem muss sich fuer jede Software mal jemand hinsetzen, und die Installationsscripte fuer die Distribution schreiben und eintragen.

So funktioniert das im Grunde auch bei anderen Distributionen, die dann halt nicht die Scripte und den Sourcecode verteilen, sondern das Binary, das da rausfaellt.

Wer sich wie ich die ganze Arbeit ersparen will, der nimmt einfach flatpak (scheint es bei neovim zu geben), das updatet automatisch, ist immer die neuste Version (auch auf Distros, die im Repo nur alte/gar keine Version führen oder irgendwelche libs/deps veraltet sind/fehlen und das Programm nicht läuft) und wird praktisch von jedem Programm unterstützt. Flatpaks sind im Prinzip kleine Container mit eigenen libs/deps, die unabhängig vom OS sind, womit auch weniger/keine Versionskonflikte entstehen.
Performanceunterschiede merke ich keine und Programme installieren geht viel schneller.

Hast du in solchen Fällen einen cron-Job gesetzt, der regelmäßig pullt, kompiliert und dann installiert? Irgendwie möchte man ja ohne die Schritte jedes Mal manuell wiederholen zu müssen um an die neuen Versionen/Commits kommen und zu warten bis installiert (oder aktualisiert) wurde, weil das relativ lange dauern kann.

Nein, ich will nicht dass diese Sachen einfach so passieren, sollte etwas kaputt gehen. Ansonsten hacke ich ja oft selbst an der Software die ich from source installiere, also will ich ja nicht probleme mit merge-konflikten provozieren. Für mich ist es aber ggf. auch etwas anderes, weil es für mich meist nicht darum geht die neuste Software zum Selbstzweck zu haben.

[quote=„MathematikBachelor, post:1, topic:28140, full:true“]Hast du in solchen Fällen einen cron-Job gesetzt, der regelmäßig pullt, kompiliert und dann installiert? Irgendwie möchte man ja ohne die Schritte jedes Mal manuell wiederholen zu müssen um an die neuen Versionen/Commits kommen und zu warten bis installiert (oder aktualisiert) wurde, weil das relativ lange dauern kann.
[/quote]Gibts für sowas nicht Arch oder Gentoo? Oder Flatpack, wenn dir dein Ubuntu zu abgehangen ist. Selber bauen lohnt sich eigentlich nur, wenn du in die Entwicklung einsteigen willst.

Ich installierte anfangs Neovim per apt install und die Version war relativ alt, deswegen sah ich mich auf der GitHub um, wählte dann das dortige Paket (wie oben erwähnt) und habe es nicht mehr in Betracht gezogen Neovim anderweitig als direkt aus dem GitHub-Repo zu installieren, weil ich nicht 2-4 Versionsnummer hinterher hinken wollte. Euren Antworten entnehme ich, dass es dieses Problem Mit Flatpack nicht gibt, bzw. man dadurch zeitnah Aktualisierungen erhält. Im Bezug auf Neovim ist das dann auf jeden Fall für mich die beste Lösung und wie ich im Allgemeinen mit Software umgehe, die ich selbst kompilieren muss, weiß ich jetzt auch etwas besser. :slight_smile:

Ich hab schon vermutet, dass es hauptsächlich um veraltete Software ging, weil ich das Problem selbst von Debian kenne.
Flatpaks werden in den meisten Fällen von den Entwicklern selbst gebaut, somit sollten sie praktisch immer auch auf dem neusten Stand sein, sobald eine neue Version erscheint.
Außerdem sind sie Distro-unabhängig und erlauben auch sehr einfach Software zu installieren, die nicht in den Repos der jeweiligen Distro sind, z.B. Spotify.