Modern Software Packaging for Developers
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 26 | |
| Author | ||
| License | CC Attribution - ShareAlike 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/38397 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
3
4
6
7
8
9
10
11
12
13
14
19
20
22
23
25
00:00
Addressing modeInstallation artModemSoftware developerSoftwareComputer fontOpen sourceError messageCodeBinary fileExpected valueCompilerLINUXSystems <München>Software bugSoftwareDistribution <Informatik>Wissenschaftlich-technische SoftwareMoment (mathematics)Link (knot theory)Version <Informatik>Ubuntu <Programm>Spring (hydrology)Scripting languageInternetFORTRANC++Open sourceSlide ruleComputer fontComputer programScrum (software development)Ruby on RailsRun-time systemPatch (Unix)JSONComputer animation
08:43
Software developerRule of inferenceConfiguration spaceInstallation artPatch (Unix)Open sourceBuildingSystem programmingComputer configurationElectronic data interchangeSoftwareSystems <München>MassPoint cloudMobile appState of matterMoment (mathematics)Eigenvalues and eigenvectorsCross-multiplicationSocial classGrand Unified TheoryForceMaschinelle LesbarkeitWordParallelenEnergieKompressionConfiguration spaceOpen sourceDesire pathComputer programmingStatement (computer science)Source codeCompilerTARGETS <Programm>Scripting languageSpacetimemakeCompilerVariable (mathematics)Disk read-and-write headSIMPL <Programmiersprache>Computer animation
17:15
Installation artComputer configurationSystem programmingBuildingRevision controlLink (knot theory)Physical systemExpressionZahlInformationScripting languageMoment (mathematics)ForestSystems <München>Data storage deviceControl engineeringWINDOWS <Programm>ForceVersion <Informatik>Physical quantityUNIXSmart cardDesire pathComputer programmingSoftwareCodeCMakeCompilerDebian GNU/LINUXGNU <Software>Run-time systemPNGSlide ruleLINUXUbuntu <Programm>Variable (mathematics)String (computer science)Computer animation
25:46
ExpressionRevision controlInstallation artExclusive orParallel portMultiplicationCodeConfiguration spaceDistribution (mathematics)Web browserComputerSoftwareCompilerParsingSlide ruleFirefox <Programm>Windows <Zweiunddreißig Bit>VAX/VMSGrand Unified TheoryRun-time systemCompilerLink (knot theory)Direction (geometry)Source codeMoment (mathematics)PowerPCUpdateComputer fileSystems <München>Physical quantityDistribution <Informatik>JavaScriptQuantum stateEigenvalues and eigenvectorsTypParallelenDEBUG <Programm>Polymorphism (materials science)POWER <Computerarchitektur>Scientific modellingTable (information)Haar measureKöcher <Mathematik>Patch (Unix)Mountain passVersion <Informatik>SystementwicklungDevice driverSystem identificationNumberScripting languageInstallation artComputer animationLecture/Conference
34:18
Distribution (mathematics)Open sourceCompilerStandard deviationBinary fileLink (knot theory)Kepler conjectureRegular graphCompilerUpdateSpring (hydrology)Distribution <Informatik>Moment (mathematics)OperatorFunction (mathematics)ImplementationOpen sourceWindows <Zweiunddreißig Bit>Scripting languageDesire pathCompilerSystems <München>Version <Informatik>CMakeGNU <Software>Ubuntu <Programm>Series (mathematics)SoftwareFunktionalitätStandard deviationEckeNumberWeightGoogleDistanceSource codeUSB-StickContext awarenessState of matterPetersen graphComputer animationLecture/Conference
42:50
Kepler conjectureInstallation artSoftwareSoftwareConfiguration spaceVersion <Informatik>Moment (mathematics)Statement (computer science)Desire pathDefault (computer science)Set (mathematics)HierarchyComputer animationLecture/Conference
44:07
Patch (Unix)Phase transitionLevel (video gaming)BuildingInstallation artSoftwareTablet computerCompilerDefault (computer science)Physical systemSoftware developerOpen sourceMoment (mathematics)Version <Informatik>Uniform resource locatorCMakeDistribution <Informatik>DEBUG <Programm>Video game consoleSoftwareTurbo-CodeHash functionComputer programmingCompilerDefault (computer science)Mathematical optimizationSeries (mathematics)SummationScripting languageWeb pageMilitary baseSpeciesComputer animationLecture/Conference
50:03
SoftwareCMakeOpen sourceComputer animation
50:43
FreewareRandom numberComputer animationLecture/Conference
Transcript: German(auto-generated)
00:12
schön, dass ihr da seid. Software Packaging. Warum rede ich da drüber? Das ist ein Thema, wo ich mich in den letzten Jahren sehr intensiv mit beschäftigt habe, speziell für selbstgeschriebene
00:23
Open-Source-Software. Und das Problem, das mir immer wieder aufgefallen ist, ist, dass es sehr viele schöne Open-Source-Software gibt, die man aber leider nicht installiert bekommt. Speziell, wenn man jetzt irgendwas von GitHub klont. Und mir sind da so ein paar konzeptionelle Sachen aufgefallen, die man beachten kann, um das Problem geringer zu bekommen. Und die
00:41
ich euch einfach mal vorstellen. Software Packaging, habe ich so ein Echo drauf hier? Geht das für euch? Das ist ein bisschen metallisch. Software Packaging ist wie Distributionsauswahl natürlich ein sehr geschmacksabhängiges Thema. Demzufolge werde ich euch nicht irgendwie einzelne Sachen auseinandernehmen, die ich jetzt sage, das ist das OnePlus Ultra. Ich
01:01
gebe bloß Kriterien, nachdem ihr die bewerten könnt und stelle euch speziell einen Package Manager vor, den ich denke, der sehr gut Overarching die Sachen beschreibt. Warum wir darüber reden werden, also ich komme von einem dunklen, dunklen Ort. Also ich komme von einem Ort, in dem es noch alles richtig dunkel ist. Es wird nicht in Skripten geschrieben,
01:22
die interpretiert werden, sondern es wird alles noch ordentlich runter compiled. Dann gibt es Binary's am Ende oder Binary Libraries und die haben Inkompatibilitäten. Und nachdem man die gebaut hat oder beziehungsweise bauen selber oder compilen ist nicht alles, da gibt noch den ganzen Bildprozess rundherum. Und der wiederum ist eigentlich auch nur eingebettet in den Paketierungsprozess. Und wenn man das irgendwie alles im Griff hat, dann kann man
01:41
daran denken, irgendwie überhaupt sein Projekt irgendwie an einen Nutzer zu liefern, das heißt Shipping, wenn man bezeichnet wird. Da gebe ich euch ein klein bisschen Überblick. Dann reden wir ein bisschen drüber, wie Bildsystem überhaupt zu funktionieren, wie dieser 5-4-Punkte-Satz hier abläuft. Und wenn wir das gemacht haben, rede ich
02:02
ein bisschen über Quellen von Inkompatibilitäten, die man meistens trifft und die Hauptprobleme verursachen, insbesondere bei komplizierten Sprachen. Und wie man die eventuell umgehen kann. Wie man die eventuell umgehen kann, sind z.B. manuelle Workflows, die man bisher machen konnte und wie man die automatisieren kann. Speziell, wenn man sich auf einer speziellen Distribution befindet, aber gerne mal seine Software mit einem anderen
02:22
Compiler testen möchte, mit dem die gesamte Software der Distribution nicht gebaut ist. Und dann zeige ich als letztes den Speck Package Manager, der ist wie alles in dem Talk Open Source natürlich und auf GitHub. Und was die Konzepte dahinter sind, die ganz interessant sind und auf bekannten Konzepten von alten Paketmanagern aufbauen
02:42
und die verbessern. Also erstmal, bevor wir anfangen, Internet ist heute irgendwie schon mal zusammengebrochen. Falls jemand mir im zweiten Teil folgen möchte, ich habe einen Docker angelegt, einfach docker-pull-axel-slash-spec. Damit kann man sozusagen mit den Paketmanagern herumspielen und hat einigermaßen zumindest virtualisierte Maschine. Alternativ, meine Overlays funktionieren hervorragend, steht alles,
03:07
was ich habe, im zweiten Teil auch auf spec.io. Das ist sozusagen einfach nur ein Dreisatz, das ist ein Getrepot, das klumpt mal runter, aktiviert die Umgebung, da hat man ja Echkomplition und so weiter. Und mit Bootstrap kann man sich noch fehlende Software nachinstallieren, weil der Package Manager kann sich selbstverständlich auch seine
03:23
fehlende Packages nachinstallieren. Und dann kann man eigentlich mitmachen, im zweiten Teil. Genau, also einfach axel-slash-spec-3. Kurze Disclaimer, ich mache das hier privat und mache die Slides meistens nachts. Deswegen ist das meine Privatveranstaltung hier. Nichtsdestotrotz habe ich die Möglichkeit, während meiner
03:44
Hauptarbeitszeit in einem geringen Prozentsatz, auch speziell zu einem spec. Package Manager, beizutragen und habe das auch gemacht. Ich arbeite im Forschungszentrum hier und ich nutze das zur Zeit als eine der Möglichkeiten, unsere Software zu shippen und an Leute zu bringen. Also so viel zu meinem Hintergrund bloß.
04:00
Okay, also wo komme ich her? In meiner Welt gibt es Binaries und die Sprachen, die sehr populär dort noch sind leider, sind C zum Beispiel. Ansonsten programmiere ich relativ viel in C++, wissenschaftliche Software. Und ich möchte in die Liste
04:22
auch mal aufnehmen. Was wir auch relativ viel benutzen, ist Python. Okay, Python soll ja eigentlich absolut keine Probleme haben, das ist eine interpretierte Sprache. Tatsächlich ist aber die richtig coolen Python Libraries, die sind alles bloß Rapper für C Libraries. Also in Wirklichkeit liegt dahinter ein .so-File. Und deswegen haben Python Libraries heute genau die gleichen Probleme wie ein richtiges C++ Library beim installieren. Nämlich, dass wenn man versucht, dann
04:43
zwei verschiedene zusammenzufügen, dass die am Ende irgendwann nicht mehr richtig funktionieren. Es gibt noch eine extra layer Abstraktion obendrauf, aber man bekommt sehr schnell die gleichen Probleme. Und deswegen gibt es für Python ganz genauso. Und tatsächlich auch Fortran hat genau die gleichen Probleme und Fortran ist alive and rocking. Zumindest in Wissenschaft. Ob man will oder nicht.
05:02
Genau, und die Auffälle, die man so sieht, dann sind solche Sprachen so wie, okay, ein undefiniertes Symbol gefunden jetzt am Ende beim Kompilieren oder verlinken oder eine fehlende Funktion. Und das sind so die Sachen, wie man sich voran schlägt und sich durchschlägt den ganzen Tag und man fragt sich, warum treten die auf und kann ich die nicht von vornherein umgehen,
05:22
indem ich Kontrolle über meine Softwareumgebung habe. Genau, als kleines Beispiel, jetzt eher ein sehr cooles C++ Projekt, aber es ist trotzdem eins. Das PNG-Writer, das ist im Grunde genommen ein Anfang 2000er geschrieben von einem Freund von mir. Einfach nur
05:41
C++-Wrapper auf libpng, damit man leicht PNGs schreiben kann. Und da denkt man, okay, alles klar, das heißt das Projekt braucht libpng, aber das ist eine C-Library. Und dann sollte es eigentlich funktionieren. Aber die Realität sieht meistens dann nicht so aus, sondern, dass natürlich libpng selber auch Abhängigkeiten hat. Selbst die kleine
06:02
libpng-Standardimplementierung hängt zum Beispiel schon mal von Zlib ab. Und Zlib ist meistens auf Distributionen in einer Version vorhanden, aber tatsächlich ist das Projekt auch noch am Leben und entwickelt sich auch weiter. Also gibt es davon auch Versionen zum Beispiel. Und wenn man in PNGs Texte schreiben will, dann hängt man eigentlich auch noch von FreeType ab. Man braucht dann eben entsprechend auch noch mal irgendwas, was Fonts interpretieren kann. Und das ist aber auch noch nicht ganz
06:24
alles davon, weil eigentlich in all die Teile schon compilert und deswegen hängen all die schon mal von einem Compiler ab, inklusive von meinem Endprojekt. Und die ersten Probleme kommen dann schon an, wenn man einen anderen Compiler für verschiedene Teilschritte nimmt. Weil theoretisch sollen die meisten Sachen ABI-kompatibel sein, also die Binary's, die rauskommen, die Interfaces, sollten kompatibel sein, sind sie aber
06:41
nicht. Und wenn man dann noch Programmierfehler macht, wie in dem Projekt, dann hängt PNG weiter noch mal von Zlib ab, obwohl es das gar nicht direkt benutzt. Zum Beispiel, wenn man so sehend nicht den Zlib-Header inkludiert hat. Und das ist natürlich dann ein großer Spaß. Für mein Projekt hängt NOS von LibPng ab. Gibt auch noch größere Grafiken an Projekten, die wir arbeiten und
07:01
das ist aber schon mal genug. Genau, dann die Nutzer-Erwartung eigentlich. Also was ich, wenn ich einen Dorfwerb benutzen will, eigentlich erwarte, ist, dass ich einen der vielen Package-Manager nehmen kann, irgendwie abget, ntwm, jam, was auch immer es gibt, install Projektname. So, dann gibt es noch verschiedenste Varianten. Wir gehen nachher noch mal nach Kriterien durch, wie man die
07:22
installiert sein. So, aber danach kriege ich erst mal installiert, kriege ich irgendeine Version. Und das ist für einen Nutzer ausreichend, in der Regel. Gibt ihm die neueste Version, er ist wahrscheinlich happy. Aber für einen Entwickler überhaupt gar nicht. Als Entwickler will ich, nehm ich, entwickelt ich also prinzipiell erst mal auf irgendeinem System. Und ich will aber dafür so getragen, dass meine Software auch auf
07:43
anderen Systemen läuft. Und da will ich zum Beispiel gegen einen anderen Compiler nochmal bauen, um zu gucken, okay, würde das jetzt auch auf einen Arch Linux bauen, wo es schon eine GCC 7 gibt und ich auf meinem Ubuntu gerade mit meinem GCC 5 oder 6, je nachdem, was ich gerade hab, unterwegs bin. Und deswegen will ich eigentlich viel mehr Kontrolle da drüber haben. So, wie sieht dann also die
08:02
Realität für den Entwickler aus? Also ganz, ganz, ganz tief drin am Ende. Ich hab jetzt mal nicht unterschieden zwischen Compiler und Linken. Gibt's einen Aufruf an einem Compiler, GCC, äh, gibt's einen Clue hier an der Stelle, also G plus plus. Und ganz oben ist also der Compiler-Aufruf, ganz hinten ist Source-Code-Aufruf. Ich wollte eigentlich mal in Zeit stoppen. Und so weit so gut,
08:23
wenn man jetzt Abhängigkeiten hat, muss man die noch irgendwie ranbekommen. In dem Fall wäre das jetzt einfach übersprungen. Also für den linker Schritt mit ran hab ich es angegeben. Okay, ich brauche jetzt hier mindestens noch eine Library ranlegen, libpng oder minislz minus lm für Mathe und was noch alles reinkommen könnte. Und dann funktioniert das. Das funktioniert jetzt schon in dem Moment sehr gut,
08:42
solange alle Abhängigkeiten in einem System-Fad installiert sind. Also in einem Fad, wo der Compiler eh immer reinguckt und dann zum Beispiel die Header-Files, die dazu noch mal gehört, dazu liegen. Dann klappt das schon. Wenn man jetzt aber noch mal die echte Realität anguckt, dann hat man zum Beispiel sich schon selber eine PNG-Library
09:01
noch mal dazu gebaut und die irgendwo in sein Home gelegt. Und in dem Moment fängt man dann schon an, noch mal noch weitere Hins zu geben an den Compilers. Zum Beispiel, okay, mein Include ist in meinem Home mit PNG und da ist ein Include-Ordner drinne. Und damit ich jetzt das minus lpng auch das Richtige nehme, muss ich auch angeben, okay, minus groß l der Pfad dorthin. Kann man auch gleich in einer Zeile machen, aber genau, also es fängt, man
09:20
fängt da an mit Hins rumzuarbeiten. Man kann das auch über Umgebungsvariablen machen. Das kann man dann vor allem am Paketmanager, womit dann dazukommen später. Aber alles in einem wird das beliebig langen. Ich habe jetzt mal plus den PNG angegeben. Das müsste ich jetzt für ZLib, für Mathe im Zweifelsfall auch und für alles andere Friedtreib oder so weiter genauso mit angeben. Und das ist entsprechend, ja, kompliziert. Was machen wir also als
09:42
Entwickler? Wir sind schlau und machen Slide Transitions, genau, Umgebungsvariablen, wie erwähnt. Wir schreiben uns also Make Files. Und Make Files sind maschienlesbar, auch menschenlesbar. Das sind einfach nur Text Files und statt einem Bash Script
10:01
kann man hier ein kleines bisschen mehr Logik unterbringen. Also auf der linken Seite ist jetzt mal so ein ganz, ganz simples Make File. Das funktioniert schon, das würde schon funktionieren fast. Was man also machen kann, man kann Variable anlegen, zum Beispiel eine ganz typische Variable, die auch relativ standardisiert ist, ist CXX und die kann man dann auch beim Aufruf des Make Files ändern. Wenn ich jetzt also in einem Ordner dieses Make File liegen habe
10:21
und gebe den kleinen Befehl ein klein Make, dann wird er standardmäßig das File Make File aufrufen und das von oben nach unten ausführen. Also wir eine Variable anlegen, G++, das könnte ich jetzt als Nutzer auch einfach ändern. Und dann gibt es hier eine Beschreibung, was nacheinander gemacht werden muss. Und das geht, ich würde mal ganz kurz die Syntax erklären. Main.O ist das Target, was man erzeugen möchte und
10:41
nach dem Doppelpunkt sind Abhängigkeiten. Also das hängt zum Beispiel ab von hier in dem Fall zwei Soos Files, einmal ein richtiges Soos File, das CPP File und dann auch ein Header File. Das sorgt dafür, dass der Makescript, der dann drüber läuft, man kennt, ok, wenn sich eins der Soos Files ändert, werde ich das Object neu compilen müssen. Ganz cool und praktisch. Und in der nächsten Seite benutzt man das
11:01
dann einfach und zum Beispiel hier nehme ich dann die Variable für CXX, werfe noch ein paar Flex ran, die man natürlich dann auch wieder über Zusatzvariablen, die einigermaßen standardisiert sind, benutzen kann. Und dann gibt man sein Soos File rein. Und entsprechend alle Flex, die man auf der Folie vorgesehen haben. Das kann man beliebig weit treiben.
11:22
Man kann jetzt also diese Syntax noch abkürzen. Da gibt es ganz tolle Placeholders, die man benutzen kann. Also nenne mir das Object File immer genauso wie das Soos File und enter plus die Änderung oder ähnliches. Das ist ganz cool. Aber was man jetzt hier an der Stelle schon sehen ist, einfach mal als Überblick, ist natürlich jetzt auf jedes System, was sich draufkomme, müsste ich jetzt hier
11:40
anpassen. Also wenn ich jetzt zum Beispiel ein GCC installiert habe, der auf meinem System nicht GCC heißt, sondern GCC minus 3.5, dann muss ich in das File rein gehen und das editieren. So in dem Moment habe ich eigentlich Nutzer schon komplett abgehangen. Und wenn das Ding jetzt länger wird und komplexer, dann ist es auch für Developer nicht mehr ganz trivial, das anzupassen, was dann der nächste Punkt ist. Ansonsten ist
12:01
es Makefiles, die ansonsten nett, die sind zum Beispiel TAP-sensitiv. Also TAPs und Spaces darf man da drin nicht verwechseln. Und eigentlich sollte man die nicht als ein Mensch noch schreiben. Nichtsdestotrotz, Makefiles haben etwas ganz Cooles, die sind parallelisierbar. Wenn ich also mehrere solche Targets angebe, wie main.o und dann meinetwegen utility.o oder irgendwas anderes,
12:20
dann erkennt der, wenn da keine Abhängigkeiten angegeben sind, kann ich das parallel bauen, kann das in Sweats rauspacken. Das ist ziemlich cool und das geht mit make-j dann. Nichtdestotrotz solche Makefiles, die gibt es in der klassischen GNU Make Setup. Neuerdings gibt es auch andere, zum Beispiel Ninja, die ein bisschen performanter sind, sollte man eigentlich nicht mehr von Hand schreiben, weil es ziemlich kompliziert ist.
12:41
Die Regel, um Software zu bauen, ist, das kennen wir so als Dreisatz. Das heißt, wenn ich ein Projekt mir runterlade, als Source Code, muss ich das zuerst konfigurieren. In dem Moment gebe ich ein, wo möchte ich es hin installieren, einen Präfix. Was möchte ich für eine Variante davon bauen? Na, vielleicht kann das mit oder ohne Kompressionen Bilder bauen. Möchte ich, ja,
13:03
was möchte ich für eine Compiler Flex ranwerfen zum Beispiel? Möchte ich das optimiert haben oder möchte ich das debuggen? Ein Haufen solcher Optionen, die setzt man alles in Configure. Und Configure, also diese Konfigurationsstage am Anfang, der ist auch dafür verantwortlich, Abhängigkeiten zu finden auf dem System. Und die kann man dann noch ein bisschen beeinflussen, wieder mit HINs, ähnlich wie man das
13:21
am Compiler einstellen konnte. Aber der Vorteil ist, dass es schon ein bisschen abstrahiert. Das sind jetzt auch keine Befehle an der Stelle, sondern das sind bloß die Schritte. Also Configure, was es da für Tools gibt, gucken wir uns gleich an. Und der nächste Schritt ist dann das tatsächlich bauen und linken. Da muss man normalerweise nicht mit interagieren, solange man nicht die Software selber als ein Bug hat und dann einen
13:40
Compilerfehler wirft zum Beispiel. Dann möchten wir damit interagieren. Aber normalerweise ist das dann optionsfrei, außer man macht so viele Ressourcen beim bauen. Und der letzte Schritt ist installieren. Das ist der typische Dreisatz, den man kennt, aber das ist eigentlich nicht die Realität. Die Realität geht nämlich dann weiter. Und zwar im nächsten
14:02
Schritt ist dann eigentlich die Frage, wie finde ich das installiert dann eigentlich wieder? Und weil ich brauche das eventuell wieder, wenn ich das dann wieder mit einem anderen Projekt benutze und wieder konfigure. Und das ist eigentlich noch ein Viertel Schritt, der dazukommt. Gehen wir nachher nochmal drauf ein. Und eigentlich gibt es davor auch noch Schritte, weil eventuell muss ich irgendwie die Source Code erstmal irgendwo herbekommen.
14:20
Das kann man schon automatisieren und eventuell muss ich den auch noch patchen. Also gute Praxis in Open Source doch wäre eh, wenn man Patches oder Fehler findet in Software, dann die wieder sogenannten Upstream, also zu dem Hauptentwickler, zuzuspielen, damit die eingebaut werden kann über kurz oder lang. Aber mittelfristig oder bei manchen Projekten macht es einfach Sinn dauerhaft Patches einzuspielen. Und das ist also ein ganz essenzieller Schritt in der
14:41
Softwareentwicklung mittlerweile. Genau und deswegen reden wir jetzt erstmal über Bildsysteme. Die sind also noch einen Schritt vor Package-Managern. Bildsysteme machen Makefiles. Also die erzeugen Makefiles ohne, dass wir sie selber schreiben müssen. Und wie machen die das? Tja, also die haben
15:02
folgende Aufgaben. Zum einen Bildsysteme sind in dem ersten Schritt drin, wo dieser konfigure Schritt drin war. Die haben erst die Aufgabe, Optionen und Varianten zu setzen. Das kann man damit schön standardisieren. Und dann kann man aus dem Bildsystem einfach zum Beispiel mehrere Compiler ansprechen, aber über die gleiche Option. Ich möchte halt immer die Bug-Option nehmen, aber der
15:21
eine Compiler nimmt minus G und der andere nimmt minus die Bug zum Beispiel. Dann haben Bildsysteme den großen Vorteil, dass die in dem Configure-Schritt, bevor überhaupt irgendwas gebaut wird, herausfinden können, falls es Konflikte in der Software gibt, können die sagen, bevor der Compiler sagt, oh jetzt habe ich aber eine Abhängigkeit nicht gefunden, die du gerade versuchst zu linken. Oder ich habe gerade den Include fein nicht gefunden. Also das ist ganz praktisch. Die
15:41
können also in dem Moment, bevor man überhaupt anfängt, Software zu übersetzen, das schon mal warnen. Dann ein großer Vorteil, den Bildsysteme schaffen ist, wenn ich jetzt wie bei meinem Beispiel vorne von libpng abhänge, können die auch transitive Abhängigkeiten finden. Also gute Bildsysteme schaffen es zum Beispiel zu sagen, ich brauche libpng und libpng sagt in dem
16:00
Moment, wo es gefunden wird, ja, aber ich brauche zusätzlich noch minus LZ für Kompremierung. Genau, das machen die. Und dann eben am Ende, wenn es dann ans Eingemachte geht, setzen die die entsprechenden Compiler und Linker Flex zum Beispiel um mitzuteilen, wo kommt die Software her? Das große minus I, das große minus L, was wir vor uns hatten. Oder
16:20
Übersetzung von eigenen Optionen und Varianten, die sehr individuell sein können für die Software und die man nicht standardisieren kann, weil die sind einfach domain spezifisch dann. Genau, dann erzeugen die am Ende Makefiles und die Makefiles selber werden dann, wie davor auch in das Video geschrieben hat, einfach ausgeführt. Was aber auch eine ganz, ganz wichtige Punkt ist, ist der letzte Punkt, der zwar installieren.
16:41
Das machen auch Bildsysteme noch. Und man kann es auch vergessen zu machen, dann machen sie es nicht, aber grundsätzlich machen die das. Und das ist dann, das ist mehr als nur die Software, die jetzt gebaut wurde, irgendwo in den Pfad zu schieben. Also, zum einen machen die das natürlich, setzen eventuell noch ein paar Pfade um, wie zum Beispiel Hintz in den Elfs.
17:02
Aber zusätzlich kann man nach dem Moment noch die Konfiguration, die man beim Bauen hatte, rausschreiben. Also, das, was ganz oben hier steht. Zum Beispiel, okay, ich habe gebaut mit der Möglichkeit zu komprimieren. Und die kann man dann ablegen. Und dafür gibt es standardisiert in der Unix-Linux-Welt zur
17:20
Zeit, ich würde sagen, zwei große Sachen. Package Config. Das sind Punkt-PC-Files. Die gucken wir uns gleich mal an. Die drücken zumindest aus, wie man heißt, welche Version man ist und wovon man abhängt. Und in der CMake-Welt, da reden wir auch darüber, gibt es Config.CMake-Files. Die sind deutlich abstrahierter. Aber machen genau das Gleiche. Genau. Also,
17:41
Bildsystem. Der letzte Schritt ist installieren. Und danach möchte man eventuell ausdrücken, was ich hier installiert habe, hat ein paar Eigenschaften. Und das ist eigentlich der de facto Standard zur Zeit. Und da sind auch die größten Probleme. Also, das sind jetzt mal die Sachen, die man minimal angeben muss in so einem Package Config-File. Und da gibt es einfach Package Config und dann Leerzeichen Name. Dann geht man die Information zurück als Tool. Das kann man wieder in einem
18:01
Bildsystem benutzen, zum Beispiel. Und da haben wir hier zum Beispiel die Software. Die ist HDF5. Die macht File.io. Die hat eine kurze Beschreibung, damit man weiß, um was es geht. Hat eine Version. Das ist natürlich wichtig. Und ja, ich hatte jetzt mal die von meinem System genommen. Requires ist hier an der Stelle leer, was ganz interessant ist, weil die hängt eigentlich auch wieder mindestens von Zlib ab. Aber das ist ja nicht so schlimm. Das wird schon gehen. Und
18:23
genau. Und dann gibt es Cflex und Lips. Das ist genau das Minusgroß i und Minusgroß l, was wir vor uns hatten. Und das wird dann genauso als String genommen und durchgeschoben. Also, eine Make-File wird das dann package-config aufrufen und dann schiebt das durch. Und da sieht man schon die ersten Variationen. Das ist auf einmal nicht mal ein UserLib installiert, das MPI,
18:40
was ich benutzt habe dazu, sondern das ist irgendwie nochmal ein Grundordner. Aber das drückt mir wenigstens aus, was das ist. Okay. Gut. Was ich jetzt aber nicht ausdrücken kann ist, und da kommen wir jetzt mehrmals zurück in den Vortrag drauf, ist Variationen in der Software selber. Also, das ist standardisiert. Aber wenn ich jetzt irgendeine andere Variable hier reinschreibe, dann habe ich die mir selber in dem Moment ausgedacht. Und
19:01
da gibt es relativ wenig Ausdrucksstärke dazu. Okay. Was haben wir an Bildsystemen überhaupt so zur Verfügung? Also, typische Bildsysteme, die es gibt, sind zum Beispiel AutoTools. AutoTools steuert z.B. standardmäßig dann diese package-config- Files am Ende. AutoTools ist eigentlich nicht, also auch meistens so und das ist nicht ein Tool, sondern das ist eigentlich eine ganze
19:20
Sammlung. Auf Debian oder Ubuntu sind zum Beispiel fünf Pakete von AutoTools, LibTools bis verschiedenster anderes Kram. Die kennen wir meistens über die M4 Files, die man dann herabschreiben muss. Das hat eine relativ lange Geschichte, hat sich oft verändert in der API, aber es war sehr nützlich. CMake ist eigentlich der moderne, aktuelle Standard, wie man Software beschreibt
19:40
und ich zeige euch im nächsten Slide mal, wie einfach dann Make-File mit erzeugt wird. Und hat den Vorteil, es hat Multilanguage Support, also man kann damit eigentlich C, C++, Vortrag, CUDA, eigentlich größtens Sachen beschreiben und ist eigentlich auch erweiterbar und wie alle anderen auch oben so ist. QMake wird in der Qt-Welt lang benutzt. Ich glaube, es ist mittlerweile
20:00
auch replaced worden von CMake. Bjam ist auch so ein typisches Bildsystem. Das wird benutzt vor allem in der Boost Library. Nach großen Schmerzen und Abspringen viele Entwickler stellen die jetzt auch auf CMake um. Und ja, es gibt auch die Möglichkeit, einfach pure Piesen oder Perl oder R- Skripte einfach direkt mit
20:21
den Skripten, die sie selber haben, zu installieren. Es gibt auch einfach nur die Möglichkeit, pure Make-Files zu schreiben. Das geht natürlich auch, wenn man keine Abhängigkeiten hat. In dem Moment, selbst dann ist die Frage, selbst wenn ich schon anfange eine Variante von meinem Paket anzubieten, also du kannst es mit oder ohne
20:41
der Funktion machen, in dem Moment ist es schon ganz schön viel Logik, die man da unterbringen muss. Also das sind eigentlich keine Bildsysteme, kann man relativ weit treiben, aber gerade das Finden und Verwalten und dann Schreiben, sich selbst ausdrücken, ist schon ganz schon ein Krampf da drin. Also das sollten eigentlich nicht die Zwischenschritte sein, die erzeugt werden, aber die soll man nicht selber machen. Ich sage mal kurz das
21:01
Beispiel in CMake, wie das abläuft. Also das ist hoffentlich die modernste Syntax. CMake ist auch, wie alle nützlichen, meiner Meinung nach, Paketsysteme textbasiert. Man schreibt also einen Skript und er wird erfolgen Text enthalten. In dem Fall hänge ich ab von libpng.
21:20
Da mache ich eingeben find-package-png und was das macht, ist es sucht in einer Installation von entweder in meinem System Directory, in meiner Installation von CMake, wenn es eine populäre Library ist, oder in Umgebungswache jablen, da kann man einfach nur in den Export setzen, sucht er nach einem Helverskript und der wird einfach suchen, okay,
21:41
in dem steht dann drin, finde mir den Pfad, in dem eine libpng.so oder libpng.a oder das Ganze mit irgendwelchen suffixen oder auf Windows mit irgendwelchen DLS installiert ist. Das macht der Skript. Und was der uns dann macht, ist, der stellt uns, früher hat er einfach Strings aus Zeug, die wir dann benutzen konnten, als Variablen, als Umgebung
22:00
sind es. Was der uns jetzt aber erzeugt, erzeugt sogenannte Targets, und das sieht man ganz unten rechts, der erzeugt ein Target png, doppelpunkt, doppelpunkt, png. Und in dem, das kann man sich als Objekt vorstellen, wie in der objektorientierten Programmierung, und in dem Sinn encode z.B. okay, was brauche ich für einen Include, was muss ich beim linkeren hinzufügen. Also man muss das nicht mehr alles unterscheiden,
22:20
man das einfach sagt, okay, diese Abhängigkeit drückt sich aus, durch, ich habe die Flex gesetzt, ich habe diese Pfade, und ich brauche folgende Anhänger. Dann kann man da gleich sofort mit abarbeiten, was man für Minimalversionen braucht. Lustigerweise keine Maximalversion, was ich mindestens genauso wichtig halte, aber Minimalversionen kann man ausdrücken und exakte Versionen kann man ausdrücken, und ob die
22:42
Abhängigkeit wirklich gebraucht wird, ja, und dann soll der Skript fehlschlagen und sagen, sorry, ich kann das am Ende auch nicht bauen, weil ich hab's nicht gefunden, oder eben nicht. Und die anderen zwei Zeilen, die dann einfach dafür sorgen, dass das An- und Abhängigkeit alles dann an einen Compiler gegeben wird, also da schreibt das einen Makefile, und der gibt's dann an den Compiler, ist, zuerst legt man dann wieder ein sogenanntes Target an, das heißt in dem Fall hier
23:01
MyTool, und das wird ein Executable sein, gibt's noch einen anderen Befehl natürlich um Libraries zu bauen, und man geht einfach nur an, von welchen Source-Dateien der abhängt. Und was CMake dann macht, ist, der guckt in die Source-Dateien rein zum Beispiel, und geht durch und sagt, okay, die included die und die und die Files, und kann das einfach mit der include oder von der Syntax, die in den Files drinsteht, schon ableiten, was sozusagen die
23:21
relevanten Source-Files sind, und wenn sie sich ändern. Das ist eigentlich nicht soweit sinnvoll, weil, wenn ich das von Hand machen würde, zum Beispiel in dem Makefile, müsste ich jedes Mal, wenn ich meinen Source-File anpasse, oder irgendwas in meinem Code ändere, auch meinen Makefile anpassen, nur weil ich den include geändert habe. Und das kann natürlich mehrere Sachen beeinflussen, also zum einen kann einfach was fehlen, gut, dann übersehe ich was, und dann wird's eventuell nicht geupdatet.
23:40
Es kann aber auch Einflüsse haben, zum Beispiel, ob ich noch was parallel überhaupt compilen kann oder nicht, also ob sich das mal eine Abhängigkeit sich geändert hat. Genau, und das kann man alles automatisieren, indem man einfach Syntaxe wieder durchgeht, und das macht das Tool. Und am Ende Target Link Libraries, in dem Moment sagt man dann bloß noch, okay, dieses Target My Tool, diese Exekutive, die hat übrigens Abhängigkeiten zu,
24:01
und in dem Fall habe ich nur PNG angegeben, man kann aber einfach die Zeile mehrfach duplizieren zu all den Abhängigkeiten, die man hat. Genau, also ich würde sagen, für C&C Pluspass Projekte ist eigentlich CMake der aktuellen absolute Standard in Projekten. Das ist aber nicht schlimm, wenn man es nicht benutzt. Also die Sache ist, hauptsächlich
24:21
man nutzt irgendein Bildsystem als gar keins. Das hat nämlich den großen Vorteil, dass man im Bildsystem gezwungen ist, seine Dependencies mal richtig auszudrücken. Man muss die halt mal alle zusammen schreiben, und dann wird der Skript durchgehen und sagen, hat das funktioniert oder nicht. Das ist ein großer Unterschied zu selber mit einem Makefile oder tatsächlich mit einer GCC-Zeile zu arbeiten, weil man sehr viele
24:40
Sachen, die implizit schon auf seinem System installiert sind, also der typische Works-on-my-Machine-Fall überhaupt nicht mitbekommt. Deswegen, auch wenn man mit Autotools arbeitet oder ähnliches, das ist mindestens genauso gut, dass man es einfach nur ausgedrückt hat. Es ist halt eventuell bloß weniger modern im Sinne von, dass man halt mehr arbeiten und mehr eine größere Lernlupe am Anfang hat vielleicht.
25:02
Genau. Also das bloß dazu. Dann die Hauptfrage, warum brauche ich einen Paketmanager? Jeder, der auf einem Linux oder Unix arbeitet, kennt die eigentlich von Anfang an. Weil da kommt die Software her irgendwie. Oft in der Windows-Welt gibt es das zum Beispiel noch relativ wenig dazu. Ist aber im letzten Jahr noch einiges passiert.
25:21
Deswegen gehen wir mal kurz drüber, was dann eigentlich die Aufgabe von einem Paketmanager oben drauf ist. Also ein Paketmanager ist eigentlich die Vorbereitung dazu und der macht jetzt im Gegensatz zu einem Bildsystem, sucht ja nicht die Dependencies, auch nicht die Abhängigkeiten, sondern der drückt die aus. Okay, also ein Paketmanager
25:41
sagt dann bloß noch, okay, ich werde abhängen von libpng und das Paket von libpng kann dir sagen, wie du es findest. Aber ich weiß das nicht. Also ein Paketmanager drückt die aus, findet die aber nicht. Finde maximal, wie man die Pakete findet. Dann, auch an der Stelle
26:00
wieder, kann man natürlich schon Konflikte vermeiden. Und was ein Paketmanager vor allem auch erlaubt, ist ein Aninstall erstmal. Also der kann sich merken, welche Dateien man installiert hat und kann die wieder sauber wegschmeißen. Ist besonders relevant für Distributionspaketmanager, weil die schmeißen natürlich gerne was standmäßig in Route-Pfade rein und da kann es dann relativ schnell unübersichtlich werden. Man kann die aber auch in
26:21
separate Orte schmeißen. Das geht ganz genau so. Dann was Paketmanager noch machen, ist bei parallel installierter Software prioritisieren. Also zum Beispiel, wenn ich jetzt auf meinem Rechner vier Browser installiert habe, dann gibt es Tools dazu, die prioritisieren, welche Software genutzt werden soll. Und wir gucken gleich mal an, wie das aktuell geht. Und da kommen wir schon so ein bisschen in die
26:40
Richtung parallel installieren Also ich habe jetzt meinetwegen drei Versionen von Firefox installiert, welche möchte ich nutzen, wenn ich auf einen Link klicke. Und ganz, ganz wichtig, was Paketmanager machen, ist Umgebungen hochfahren. Also was die zum Beispiel machen, ist temporär Umgebungsvariablen hinsetzen, die wir vor uns auf den
27:00
ersten Slides hatten, zum Beispiel include passes oder für dynamische Lips den LDLiveRepass setzten bei der Ausführung dann. Für Compiler entsprechend die Flex verwendet werden. Vorbereiten, indem wir zum Beispiel einen Compiler weitere Hinweise gibt. Auch für Parser zum Beispiel, wo die arbeiten und was die anfassen dürfen, das kann man auch mit dem
27:20
Paketmanager steuern und weitere Pfade hinzufügen. Exekutiv ist, um die auszuführen. Brauchen wir auch erstmal die pass-Variablen. Manpages, all das, sind Umgebungsvariablen. Oder im zweiten Fall Sachen, die man irgendwo hin und her schiebt. Genau, wie das zur Zeit genau gemacht wird, gucken wir dann mal in den Workflows an.
27:41
Required features von so einem Package-Manager. Ich hatte immer versucht ein bisschen aufzuklütern, die Sachen, die meistens drin sind und Sachen, die meiner Meinung nach drin sein müssten. Also erstmal so Features für die Installation. Wenn man einen Paketmanager gibt, einem am Ende, was er uns genau gibt, kommen wir uns gleich an.
28:00
Aber am Ende muss ich das irgendwo hin installieren, source code oder binaries. Und die Frage ist, wohin. Und da kommt es tatsächlich ganz auf den Paketmanager an. Bei Distributionen, zum Beispiel bei Debian, Depp-Paketen, ist das einfach ein Tarf-File und der ist einfach mit einem fixen Pfad oder überschrieben in das System, was man drin hat. Zusätzlich kann man bei dem,
28:21
also man kann so sagen, da nicht angeben, installieren wir das nochmal bitte in meinen Homestead essen. Zusätzlich gibt es davor noch Vorbereitungs- und Nachbereitungs-Skripte, dass es sozusagen ein bisschen flexibler ist, wenn man zum Beispiel Configfile editieren muss beim Installieren. Aber genau, das ist so die Frage. Da kann man beliebt flexibel sein oder unflexibel und dann funktioniert das.
28:41
Multiversionen, das ist schon sehr interessant, ist die Frage, kann ich für ein Paket, die beschreiben jetzt halt auch mit dem Name einfach, wie wir es vor uns gesehen haben, kann ich davon mehrere Versionen gleichzeitig installieren? Und da ist bestimmt die Frage, geht er eins, also exklusiv, oder kann ich die parallel haben und wie verwaltet er das oder verwaltet der Paketmanager das überhaupt?
29:02
Da kann man gleich mal ein Beispiel angucken, wie das zum Beispiel bei verschiedenen Compilern gehandelt wird, wenn man die installiert. Dann Containment, das ist eine sehr interessante Geschichte und ich glaube, da ist am meisten gerade in den populären und diskutierten Paketmanager in letzter Zeit passiert. Das habe ich mal unterteilt in Schwach mit einer Umgebung und Fully Virtual,
29:21
also eine schwache Umgebungsabstraktion sozusagen. Ich würde einfach sagen, okay, der installiert das in Rootfall rein und dann ist das systemweit verfügbar, da wird einfach gar nichts abstragiert. Mit der Umgebungsvariable zum Beispiel oder mit Environment, gute Kandidaten dafür sind zum Beispiel PIP für Python oder Conda.
29:40
Was die machen, die installieren das erst mal in den eigenen Pfad ihrer Software und kümmern sich dann darum, dass die HINs gesetzt werden. Das ist also schon mal so leicht abstrahiert, aber wenn man da vergisst, Abhängigkeiten zu setzen, dann wird da immer auf die Systempfade zurückfallen. Und dann gibt es Containment Fully Virtual, also das ist komplett abgeschirmt vom System oder je nachdem, was man als
30:01
Software macht, so dass es nichts mehr anderes anfassen sollte. Und da gibt es verschiedenste Varianten, also Snap ist ein gutes Beispiel, das kann relativ viel reinpacken. Ein anderes gutes Beispiel ist dann auch komplett auf VMs umzusteigen, das sind in dem Sinne keinen wirklichen Package Manager, aber die sind richtig, richtig virtualisiert und da muss alles drin sein,
30:20
ansonsten wird es nicht laufen. Genau, dann, was wird überhaupt geliefert? Also wird eine Binary geliefert oder Source Code und das ist ganz interessant, weil die ganz viele populäre Paket Manager für Distribution, zum Beispiel, auch mal wieder Dapp als Beispiel oder Jam, die sind standardmäßig Binary ausliefernd und die Binary
30:41
sind natürlich dann gebaut, das sieht man, in den Docs sind sie für verschiedene Architekturen, das läuft aus generischen X86 und ich kann das auf PowerPC ausführen und auf ARMv7 meinetwegen und dann wird es darauf funktionieren. Interessanterweise können viele davon auch Source Code ausliefern, das ist ganz interessant,
31:00
wenn man selber Modifikationen dran machen möchte, allerdings natürlich auch nur genau von den Versionen, die ihr dann ausliefern und das bringt eigentlich hauptsächlich bloß den Vorteil, dass wenn man zum Beispiel jetzt mit einem Debug-Fleck was übersetzen möchte, dass man das danach leicht wieder deinstallieren kann, aber es erlaubt uns nicht zu sagen, ja, beliebig da durchzuspielen. Dann ein ganz
31:21
wesentlicher Punkt, ich gucke es nach an, wie das funktionieren kann, ist Configuration Awareness, also wenn mein Projekt selber verschiedene Optionen unterstützt, zum Beispiel, ich kann komprimieren, ich kann irgendwas in parallel, ich kann das seriell nur und das ist wirklich am Ende ein anderes Projekt, was man installiert, dann muss man das normalerweise ausdrücken können und wie alle hier,
31:42
das gucken wir gleich einmal an, immer wenn man sowas nicht kann, also immer wenn ich sozusagen hier Nein sagen können mit so einer Variante, dann ist das zurzeit so, dass man als immer als Workaround nehmen kann, dann encode ich es halt im Name, dann nenne ich halt mein Paket nicht HDF5, sondern nenne ich das HDF5 minus gebaut mit GCC 5.1 und wenn das immer noch nicht reicht,
32:01
dann treffe ich das nochmal ein, zum Beispiel, kommen wir jetzt bei Edipia, das ist ein guter Fall, dann ist das HDF5 minus Serial, HDF5 minus OpenMPI, HDF5 minus MPI-CH und so werden Nachhängigkeiten ausgedrückt, über Namen, das ist natürlich entsprechend unflexibel und natürlich gibt es dann, wir haben dann so eine N x N Tabelle, mit der man die
32:20
Konflikte managen kann und das ist immer der Fall, wenn etwas fehlt. Dann noch ganz interessant ist natürlich je nachdem, was man für einen Nutzungsgrad hat, ist, ob die Multilanguage unterstützt. Es gibt sehr viele, sehr schöne Package Manager für zum Beispiel JavaScript oder für für Python, die funktionieren wunderbar, solange man sich nur in der Sprache aufhält,
32:40
aber wenn man auf einmal da eine Abhängigkeit zu einer C-Library bekommt, dann wird es dann immer interessant, weil die meistens schon meinetwegen vorimplementiert sind und sehr effizient sind in Mobility Plus eigentlich Interfaces, dann muss man gucken, kann das mal ein Package Manager. Und letzte Sache, das ist jetzt wieder in die Richtung wieder auch bei Ubuntu, war das bei Snap ein großes Thema, kann man mich selber informieren darüber, dass es Updates
33:00
für das Package gibt. Das ist eigentlich standardmäßig für die Linux-Welt gewesen, dass man einfach in seinem Repos nachguckt, gibt es Updates, man installiert es drüber. Dann eben bei so mehr visualisierten Parts, war es halt der Vorteil, ok, ich kann mir jetzt einen Firefax ziehen, der selber nur dieses eine Paket, obwohl es aus einer anderen Umgebung kommt, weiß, es gibt Updates.
33:20
Das war so das Selling-Feature. Ja, cool. Ja, wie laufen Distributionen ab und warum kriegen die das irgendwie hin? Also Distributionen, kennt ihr bestimmt, das habe ich einfach mal von Wikipedia genommen, den Ubuntu-Release-State. Die machen immer große Major- und Minor-Releases und wie die sich
33:40
die meisten Problemen vom Hals halten, ist zum Beispiel, dass man zwischen denen oder nur zwischen großen Schritten Compiler ändert. In dem Moment hat man schon sehr, sehr viele Probleme umgangen und das heißt natürlich auch, wenn ich jetzt auf einen der Systemen entwickle, habe ich dann nur das und die Toolchain, die da gerade zur Verfügung steht. Es gibt dann immer noch Support für, ich kann versuchen, noch zu cross zu compilen, das beziehe ich aber
34:01
meistens nur auf Architekturen, im Sinne von, ok, da habe ich halt das Gleichpaket nochmal gebaut mit anderen ASM-Befähigen drin. Aber es handelt natürlich nichts in dem Sinne von, ok, ich habe jetzt zwei Versionen von, sagen wir mal, LIP-PNG, die wird in dem Moment einfach nur darüber verwaltet, dass man einfach eine andere Paketnahme bekommt und wenn man Pech hat,
34:21
wird die dann irgendwann geskippt in der nächsten Version, dann hat man sie auch nicht mehr. Also genau, ja, die meisten Distributionsabhängigkeiten lösen das halt einfach nur darum, dass man sagt, zum Version 14.04 fangen wir an, alles mit GCC6 zu bauen, GCC4 wird weggeschmissen, die Pakete und alle Pakete, die damit dann nicht bauen, die gehen dann halt nicht oder werden gepatcht.
34:42
Genau, das ist deswegen, ja, gibt es den Schmerz bei Distributionen relativ wenig, weil die einfach nur ein paar Jahresabstände die Abhängigkeiten hochziehen. Auch hier erstmal last but not least, bevor wir mehr an Details gehen. Wenn man zumindest irgendeinen Paketmanager mal versucht, selber anzusprechen und zu ausdrücken, ok,
35:00
ich hänge von den Paketen ab, ich habe das am Anfang mal einfach gemacht mit Sie-Mail und habe einfach angefangen, auszudrücken, von welchen Ubuntu-Paketen ich habe, ist es immer noch besser, als gar keinen mal zu benutzen. Das ist eben einfach ganz interessant zu sehen, ok, was ist denn eigentlich zu erwarten auf anderen Rechnern? Das Wichtige an der Sache ist, das bringt einen nach keinem Mehrwert, weil extrem diverse
35:20
Systeme genutzt werden. Aber, das Wichtigste, was wichtig ist und wenn das Mehrwert bringt, ist, wenn man genau diesen Prozess, zum Beispiel, wenn man nur ein Debian-Paket zu bauen, offen dokumentiert und rausschreibt, ok, ich nehme den, den und die Pakete, weil ich davon abhänge. Und dann fügt man das einfach mal aus, zum Beispiel, auf einem frischen System, mit minimaler Software und guckt, funktioniert das. Kann man das natürlich einfach in einem Docker-Container starten
35:41
nochmal probieren. Das ist einfach schon ein extremer Mehrwert und steigert auf jeden Fall extrem die Nutzbarkeit von Software, sobald man irgendeinen Package-Manager nimmt. Genau, jetzt aber die Schmerzen. So ist es auch Incompetibility. Genau, das ist eigentlich so die Warnung, die man eigentlich sieht, wenn man auf einem System
36:01
irgendwie extra Software herstellen will. Achtung, zusätzliche Fremdquellen können das System gefährden. So, ich kann das gut und schlecht finden. Die Frage ist, was heißt das? Was kann das System gefährden jetzt? Klar, man denkt an dem Moment dran, wenn ich mir eine Fremdquelle von irgendjemanden ziehe, ist natürlich auch ein Sicherheitsrisiko. Ich muss dem Sourcecode oder was auch immer, die Binary, die ich ziehe,
36:20
der muss ich vertrauen. Das wurde nicht von der Distribution abgesenkt, zum Beispiel. Aber es kann auch einfach ein tatsächliches Problem sein, dass einfach was instabil wird in dem Moment, weil etwas nicht mehr kompatibel ist. Zum Beispiel, weil die Fremdquelle mit einem anderen Compiler gebaut wurde. Und das schauen wir uns mal an, was das alles sein kann. Also, was könnte denn schiefgehen? In allen Fällen sind es
36:43
unterausgedrückte Abhängigkeiten. Also, alles, was schiefgehen kann, ist nur, weil ich es nicht genug beschreiben konnte, bevor ich es installieren konnte. Unsere typische Quellen dafür sind zum Beispiel, habe ich schon ein paar Mal erwähnt, mit einem anderen Compiler gebaut. Grundsätzlich sollte das kein Problem sein, ob man das mit einem Intel- oder GCC-Compiler
37:00
baut, oder mit einem PGI-Compiler, oder mit einem XL-Compiler, oder was auch immer man an die Hände kriegt, ist aber nicht so. Ist halt nicht API-kompatibel, die meisten Software. Da gibt es manche, manche Software, die ist dafür anfällig, und andere eher nicht. Eine lustige Quelle, die auch noch, zum Beispiel in C++, jetzt gekommen ist, in den letzten Jahren, ist, wenn man Software
37:20
in C++, also angenommen, die funktioniert mit C++98, aber ich habe die Maus spars mit C++84 übersetzt, weil es ist in der Regel der größte Teil vorwärtskompatibel, oder 14 oder 17. Dann ist es ganz lustig, dass alleine die Wahl, dass ich das mit einem anderen Standard-Fleck übersetzt habe, dazu führen kann, dass es nicht mehr funktioniert. Bestes Beispiel dazu war,
37:40
zum Beispiel, in der Standard-Lib musste das Interface geändert werden von Standard-String. Das ist was, was man jetzt relativ oft wahrscheinlich auch in einem Interface benutzen wird. Und dass sich das geändert hat, wenn ich jetzt sozusagen zwei Libraries nehme, den eine habe ich übersetzt mit C++11, den anderen mit 98, dann würde das nicht mehr zusammenpassen, wenn ich die am Ende wieder in eine weitere
38:01
Executable reinlinke. Ärgerlich. Beziehungsweise, wenn ich die dann wieder mit einem anderen Standard übersetze. So, also kann ich das ausdrücken, es ist halt normalerweise nicht inkodiert. Ich könnte das wieder in den Namen ausdrücken, minus C++14, dann ist mein Paket das, das ich mit C++14 gebaut habe. Auch ganz interessant ist es, wie man Binaries rausbaut. Es gibt verschiedene Möglichkeiten am Ende,
38:21
was man am Ende für wirklich Intrinsics und Assemblerbefehl nimmt. Wenn man wirklich performant sein will, das ist bei mir jetzt im Arbeitsleben relativ relevant, dann wählt man nicht nur aus, es soll für x86 laufen und eine generische Binary erzeugen, sondern wähle ich noch die Sub-Architecture aus. Also sage ich halt, okay, das soll auf Haswell laufen, nur auf Haswell. Ich kann auch sagen, es soll auf Haswell laufen
38:40
und generisch, dann mache ich aber meine Binary im Zeitsfall doppelt so groß, weil ich dann eben entscheidend mehrere Sachen reinpacken muss. Genau, das ist natürlich auch so eine Quelle und das ist in der Regel auch nicht ausgedrückt. Wenn wir jetzt an Paketmanager von Distributionen denken, da gibt es halt die Unterscheidung, ist x86 oder ist, was weiß ich denn, arm. Und dann muss das die Generisten,
39:01
den Generisten den Fehlsatz absetzen, der eventuell nicht der Performanteste ist. Das ist natürlich ärgerlich. Genau, das ist alles Application Binary Interface, Probleme, die ihr ausdrücken könnt, wenn man die nicht richtig ausdrückt. Dann eine andere Variante, zum Beispiel weiß ich nicht selber, meine Software hat halt mehrere Funktionen und ich kann die einmal parallel und seriell, einmal mit Kompression, einmal ohne Kompression,
39:20
einmal mit Bildunterstützung, einmal ohne Bildunterstützung. Je nachdem, was ich mir für Funktionen ausdenken kann, einmal mit oder ohne Netzwerk, alles drin haben. Das ist dann halt ein Problem, wo ich sage, okay, eventuell habe ich dann eine andere API. Kommt auf Anliefer, die ich jetzt selber designt, eventuell habe ich noch die gleiche API, die ja null zurückgibt, eventuell ändert die sich auch, kommt halt nach Anging, was es gebaut hat. Aber grundsätzlich ist halt ein Logikproblem.
39:40
Wenn ich sage, ich hänge von der Software ab und dann kann die aber nicht die Funktionalität nach, der ich frage, weil ich es nicht richtig ausgedrückt habe, dann ist das ein Problem. Und ein ganz lustiges Problem, das ich Funktionen entdeckt hatte, das war bei Protobuff. Das ist so eine Google-Library für Serialisierung. Und da war das ein interessantes Thema, die hatte gesagt, cool,
40:01
wir hatten Autotools, aber jetzt gibt es CMake. Also wir bauen mir einfach Autotools und CMake-Skrips rein in unser Projekt und jeder ist happy. Das war ein guter Gedanke. Das Problem war allerdings, dass die, wenn man die verglichen hat, die Insta-Alpfahrer aussehen, was die erzeugt haben, dass die nicht gleich waren. Also zum Beispiel
40:21
konnte das Autotools-Package, hat dann noch ein Package-Config-Skript dazu gelegt. Das CMake-Skript hat seinen eigenen Skript dazu gelegt, aber kein Package-Config-Skript und dann gab es ein cleveres C++-Projekt, was, genau, das war bei Protobuff und bei ZeroMQ, hab ich das auch noch mal gesehen, und gefixt. Da gab es ein cleveres C++-Projekt, das etwas gesagt hat, und jetzt baue ich noch
40:40
C++11-Bindings da drauf, auf diese C-Library. Und das hat dann halt immer nach einer Variante davon gesucht, und je nachdem, ob der Nutzer hinter das Anleitung installiere die C-Library und dann lege los mit uns. Und dann gingen halt die 50% der Nutzer haben es mit Autotools installiert, die anderen 50% mit CMake und die 50% waren, ich find's nicht. Und, genau, das ist dann halt so ein typischer Problem, das ist einfach eine andere Logik,
41:00
die von dem Bildsystem kommt. Und das ist so ein typischer Fall, das müsste man vielleicht auch mal zusammenfassen. Wenn man ein Bildsystem nimmt, dann bloß eins, nicht zwei. Oder wirklich richtig aufpassen und das nachfixen, dass das noch geht. In dem Fall haben wir es dann nachgefixen, indem wir einfach bei CMake auch die alten Autotools-Package- Configscripten mit erzeugt haben. Und dann war zumindest CMake-Feature complete.
41:20
Na ja. Okay, also das ist dann so ein typischer Logikfehler, der beim Serien auftreten kann. Und da gibt's noch mehr feine Finessen, aber das sind so die Sachen, die schon ziemlich erstaunlich sind, die da einfach rauskommen können. Manuelle Workflows. Also wie kann man das machen? Von Hand oder mit populären Funktionen? Package Manager. Man kann einfach
41:40
verschiedene Namen nehmen. Man kann die so fixen. Zum Beispiel update install minus 4.9. Man kann mit symbolisch links rumhantieren. Man kann einfach sich das Ganze auf ZFS legen und mit Snapshots hin- und herschieben, mounten, unmounten oder einfach immer den gleichen USB-Stick reinhauen. Oder man kann es komplett virtualisieren, dann ist es weg, aber das ist im Grunde genommen genau das Gleiche. Das ist alles relativ unschön.
42:02
Eine saubere Lösung, die man machen kann, ist eine hierarchische Directory anlegen für die Abhängigkeiten. Und genau, Ubuntu zum Beispiel setzt dann die Pfade um mit Update Alternatives. Oder man kann auch mit Skripten einfach dann die Sachen ändern. Anyway, die einzige Lösung,
42:21
die man machen kann, die eigentlich wirklich funktioniert, ist sich selber eine Hierarchie von Directories anlegen. Und das sieht so ein bisschen aus, wie als man noch keine Source Code-Kontrolle gehabt hat, für Abhängigkeiten. Also das ist so ein zypischer Fall hier. Das ist zum Beispiel okay, wir haben hier verschiedene Implementierungen von MPI, und dann legt man die einfach alle hintereinander und machen da drin dann wieder Unterordner für die Software, die davon abhängt.
42:41
Das ist halt genauso, wie bevor ich Skript benutzt habe, habe ich da so meine Operator kopiert und die ineinander gelegt und geschachtelt. Und genau, das kann man loswerden. Und genau, die letzten fünf Minuten werden wir einfach nutzen, um zu gucken, wie man das umgehen kann mit dem Spec Package Manager. Ich überziehe mal fünf Minuten, wir haben noch eine viertel Stunde. Es geht, aber Q&A muss ausfallen.
43:00
Gut, gut. Genau. Also nochmal, das ist alles auf GitHub. Mit dem Docker-Paket können wir jetzt einfach auch mitmachen, aber die Befehle sind relativ leicht zu verfolgen und stehen auch mal im Manual. Software installieren. Also wir hatten vor uns, eigentlich will ich es als Entwickler genauso leicht haben wie der Nutzer. Ich möchte meine Software
43:20
im Zweifelsfall, die letzte und aktuellste Version mit die Forteinstellungen, mit Install holen. Spec ist jetzt einfach, wie der geschrieben ist selber, ist ein Python-Paket, aber der macht genau das, mit Spec installen PNG-Writer zum Beispiel, holt er mir die Software, dröselt wie get die Abhängigkeiten auf und holt sich auch die weiteren Abhängigkeiten. Wir gucken gleich mal, wie das aussieht. Und wenn ich die nutzen will,
43:41
setze ich einfach nur den Befehl install durch load und in dem Moment setzt er Umgebungsvariablen und setzt die Pfade dahin, wo er es geschoben hat. Im Hintergrund macht er genau das Gleiche, wie ich es manuell gemacht hätte. Also er legt sich an eine Hierarchie von Directories und statt die zu nesten, macht er das in einer flachen Hierarchie und gibt den noch einen Char dazu, einfach mit der Konfiguration und dann gibt es einfach
44:01
einen Map, die guckt nach, für welcher Char steht denn für welche Konfiguration. Das ist soweit so gut und so würde das dann in der Praxis aussehen. Also wenn ich jetzt Spec install PNG-Writer mache, dann geht er durch und sagt, ok, ich hol mir jetzt erstmal was brauche ich dazu, CMake, was hat CMake für Abhängigkeiten und so weiter und sofort, habe ich das gefunden und möchte es vom System nehmen,
44:21
dann baut er das, libpng ist jetzt tatsächlich die erste Abhängigkeit, die ich jetzt direkt beim compilen brauche, freetribe ist dann die zweite Zeile und dann baut er es und so weiter und sofort und dann am Ende baut er ein Projekt dazu und nimmt die und dann installiert die in so einem langen Pfad hier, Minus Version ist das einzige, was drin steht und dann sind alle Konfigurationen hier dem Hash encoded.
44:41
Was können das für Konfigurationen sein? Also die aller einfachste wäre eine Version angeben. 0.5.6, dann baut er alles nochmal sauber runter in der Version 0.5.6. Ok, das ist einfach, könnte ich auch über den Namen encoden. Eine weitere Möglichkeit ist aber und das jetzt wird richtig interessant, ist, ich kann jetzt auch durch den gesamten
45:00
Abhängigkeitsbaum, den ich habe, durchgreifen mit diesem einfach kleinen, ja, und kann sagen, ok, die Abhängigkeit libpng möchte ich es aber in der Abhängigkeit in der Version 1.6.27 haben, weil ich will halt gucken, geht das vielleicht mit der 1.4.1.2.1.6 noch meine Software. Ok, und dann baut er das, also das sind alles Bechbefehle dann.
45:21
Genauso, und das kann man beliebig kombinieren. Genauso könnte ich jetzt auch noch angeben oder das kombiniert angeben, ich möchte die gesamte Software-Chain durchgebaut haben mit minus O3, was halt für starke Optimierung steht für den Compiler. Oder mit minus G für Debug Flex oder irgendwas, was ich noch nicht ausdrücken kann, diese Variante. Ok, das ist interessant, da kann ich also schon mal durch.
45:41
Ich kann das auch einfach mit einem anderen Compiler bauen. Also wenn ich das Spec Compiler-List aufrufen würde, bekomme ich eine Liste von Compilern, die auf meinem System gefunden wurden. Ich kann natürlich auch mit Compiler-Add hinzufügen. Und in dem Moment habe ich genauso da wie in der Syntax und in dem Moment ist es einfach ein Prozentzeichen, in dem ich sage, ok, bauen wir das und alle Abhängigkeiten,
46:01
dann hat man das immer durchreichen. Vom Source mit Zileng in der Version 381, weil ich den lokal da habe. Und das ist richtig cool, also in dem Moment kann ich wirklich dann gucken, ok, zum einen habe ich nicht das Problem, dass meine Abhängigkeiten mit einem falschen Compiler gebaut worden sind, wenn die inkompatibel sind, und zum anderen kann ich eben beliebig auch durchspielen, einfach nur mit der Zeile, die das ändert.
46:20
Genau. Dann eigene Varianten kann man ausdrücken. Das ist einfach nur, wie man dann sein Paket schreibt, also mit oder ohne MPI zum Beispiel. Und dann wird das wieder als eigener Char abgelegt. Und wenn ich SpecLoad Pi H5 Pi minus MPI mache, sucht er die richtige Version wieder raus. Und das Letzte zeige ich euch
46:41
noch, wie das Paket aussieht. Und dann sind wir schon durch. Pakete kann man einer einfach anlegen mit SpecCreate. Und da gibt man entweder seinen GitHub-Link an oder einfach einen Turbo und das hinterlegt Schemen, wie er neue Versionen finden kann. Also zum Beispiel bei GitHub-Links hat man schon Regex hinterlegt, wie er nach neuen Versionen sucht. Und danach kann man das installieren. Und das ist, wie das dann gebaut wird.
47:01
Das ist einfach nur ein Python-Paket, das erbt von seinem Bildsystem. Weil ein Package Manager ist on top auf dem Bildsystem. In dem Moment ist es CMake und da ist der Standard, da weiß ich schon, der Standard-Workflow ist okay CMake aufrufen, make, make install. Das kann man dann wieder überschreiben. Das sind einfach Methoden da drin. Und dann gibt man
47:21
standardmäßig, die wichtigsten Sachen sind URL hier. An der Stelle werden neue Versionen gefunden. Und dann kann man Versionen festlegen, die schon als vertrauenswürdig gekennzeichnet sind. Also in dem Moment zieht man die einmal runter, rechnet dort eine MT5-Summe drauf. Oder was ist das? Ich glaube, es ist MT5 zur Zeit. Ist egal. Und legt die dahinter. Man kann auch andere installieren,
47:40
solange die über den Regex findbar sind oder über eine Liste. Und alles, was man dann ausdrücken muss, ist die Dependencies hier. Und hier geht die gleiche Syntax, wie sie auch geht, von Abhängigkeiten, die ich euch davor gezeigt habe auf der Konsole. Man kann also einfach angeben, okay, hängt von libpng ab, muss aber mindestens Version 1.4 sein. Oder hängt nur von libpng ab, wenn ich eine Variante gebaut habe,
48:02
die sich dem PNG-Output unterstützt. Und das war es alles. Genau, dann zeige ich euch noch. Stopp, das war es. Ach, genau. Und dann kann man es noch durchsteuern. Also es gibt Yammel-Files zum Durchkonfigurieren. Die liegen in der Regel in seinem Home. Kann Compiler hinzufügen. Gibt es auch immer Kommando-Zeiten-Interfaces.
48:20
Externe Pakete und Varianten, die Defaults einfach ändern. Wenn ich standardmäßig zum Beispiel immer einen Debug bauen will und aber standardmäßig die Konvention ist immer ohne Debug, dann erstände ich das einfach ein. Und ich kann natürlich auch eigene Repos hinzufügen. Und genau, damit zum Summary. Also das Wichtigste ist,
48:40
was ich denke, was man mitnehmen soll. Wenn man auch mit keinem Bildsystem gearbeitet hat, mindestens mal eins ausprobieren und dokumentieren, das wird extrem die Stabilität und Nutzbarkeit eurer Software erhöhen. Wenn man noch keinen Package-Manager gemacht hat, ich sage nicht, dass man den vollen Weg gehen muss und zu suchen. Ich muss jetzt in die Debian-Main-Distribution reinkommen. Aber einfach mal in den Package-Manager, der mit Nutzerrechten die Software bauen kann, einfach mal irgendeinen nehmen.
49:01
Ich empfehle jetzt an der Stelle mal Speck und das mal auszudrücken. Einer, der leicht geht. Also vielleicht, wie gesagt, nicht so richtig alter wie der Debian-Package-Manager. Macht extrem nutzbar eure Software einfach. Und probiert das gerne mal aus. Das Wichtigste ist, die Skripte, wie ihr das dann machen, dokumentieren. Weil in dem Moment kann dann jemand,
49:20
der euch tatsächlich in der Distribution aufnehmen will, einfach von denen weiter abstrahieren und weiß genau, was ihr für Abhängigkeiten habt. Und ja, damit danke ich euch und dann können wir noch Fragen machen. Sehr interessanter Talk. Danke. Axel, erst mal einen Applaus. So, der nächste Speaker ist noch nie da.
49:40
Wir nutzen die Zeit. Ein, zwei Fragen, aber mehr können wir nie. So, warten. Ich gebe das Mikrofon und dann... Du hast bei dem Pfeil, das du gezeigt hast, die CMake-File inkludiert. Und jetzt habe ich bei dem CMake-File schon die Abhängigkeiten drinnen stehen. Kann sich Speck das nicht direkt rausholen? Und ich muss den Speck nochmal angeben.
50:00
Die Abhängigkeiten und Versionsnummern dazu. Also, das kann man... Genau, das ist ein spezieller Workflow. Der wurde das erste Mal von Conan etabliert. Man kann auch direkt tatsächlich in CMake-Speck aufrufen und sich die Source kurz bauen lassen. Das ist aber so ähnlich wie ein Paket mitschippen in den Source-Files. Das ist dann ein bisschen schwieriger zu kontrollieren. Aber für Developer
50:21
du kannst es auch einfach in CMake Speck aufrufen und dann bauen. Das treibt auch deine Build-Time im Zweifelsfall hoch. Und gegen Speck, wenn er sieht, du hast das Paket schon gebaut, dann verwaltet er das für dich. Ansonsten verwaltet er CMake für dich. Und im Endeffekt kann es halt sein, dass du es doppelt baust. So, haben wir weitere Fragen? Dann... Komm, das war ein
50:41
guter Vortrag. Nochmal klatschen. Danke, alle.