Versionsverwaltung mit Git

[PIC18F2550]

Auch wenn ich jetzt Prügel bekomme.

Warum kein php-skript auf einem Apache Server der kümmert sich dann um die binarys wenn es nur um die compilierung der Programme geht.
Den Quellcode können dann immernoch mit einer Git verwaltet werden.
Das währe dann volkommen Systemfrei.
Für den einfachen Benutzer währe dann nur eine seite wo er sich sein System/Programm herraussucht.

[nubok]

@PIC18F2550

Auch wenn das Hive-Projekt kein Copyleft-Open-Source-Projekt (Copyleft-Definition nach Richard Stallman) ist (stattdessen wurde auf eine copyleft-freie Open-Source-Lizenz gesetzt (was ich im Übrigen durchaus befürworte)), so ist es dennoch Freie Software und untersteht damit den vier durch Richard Stallman definierten Freiheiten (http://de.wikipedia.org/wiki/Freie_Soft ... grenzungen):

• Freiheit 0: Das Programm zu jedem Zweck auszuführen.
• Freiheit 1: Das Programm zu untersuchen und zu verändern.
• Freiheit 2: Das Programm zu verbreiten.
• Freiheit 3: Das Programm zu verbessern und diese Verbesserungen zu verbreiten, um damit einen Nutzen für die Gemeinschaft zu erzeugen.

Selbst wenn die Lizenz es nicht verlangt, so stellt ein Setzen auf einen Apache-Buildserver dennoch in gewissem Sinne eine Einschränkung von Freiheit 1. und 3. dar - daher sollte bei Open-Source-Software die Verteilung auf Source-Basis erfolgen. Ich bin mir bewusst, dass aus kommerziellen Gründen das viele Open-Source-Programme gerade in der Windows-Welt anders machen, aber ich persönlich vertrete offen die Meinung, dass wenn der Build-Prozess für "den gemeinen Nutzer" zu kompliziert ist, man sich Gedanken machen sollte, wie man diesen für den Nutzer einfacher gestalten kann, statt einfach auf Binaries zu setzen.

[PIC18F2550]

Hi nubok,

nicht den Teufel an die Wand malen.

Der Code sollte immer open Source sein.

Es ging mir nur darum die Missstände der Verschiedenen Betriebssysteme und ihrer Versionen und ihrer incomartibilität untereinander zu umschiffen.
Und wer die Quelltexte haben will kann sie sich doch dort auch gleich mit runterladen und verbiegen wie er will.
Er kann aber er muß ihn nicht verwenden.
Mann kann immer und zu jederzeit und mit jeden System was mindesten einen Explorer ähnliche Schnittstelle hatt das notwendige binary bekommen.
Einfacher und unabhänniger geht es nun Wirklich nicht mehr.

Warum sollte sich jemand der den HIVE nur zum Spielen oder aus freude am zusammenbau noch mit den ganzen Versionen solch einer Verwaltung rumm Ärgern wenn er seine gewünschten Programme oder das System durch einen Klick bekommen kann.
Du musst bedenken nicht jeder will oder kann sich so intensiv mit der Programmierung befassen und daher auch mein Gedanke mit dem Server.

Übrigens meine Quelltexte liegen auch auf einen kleinen eisfair-Server
Wenn ich ein Modul brauche läd der HIVE eine html Seite wo der Seitennahme eine Modul nummer ist anhand der Nummmer generiert der Apache dan ein binary und schickt es zum HIVE.
Und das immer mit dem Aktuellen Updates.

Das soll die basis für mein Rack System werden wo beim booten außer einen Netzwerk und einem Menü sogut wie nichts drauf ist.

[Zeus]

Auch wenn ich jetzt Prügel bekomme.

Warum kein php-skript auf einem Apache Server der kümmert sich dann um die binarys wenn es nur um die compilierung der Programme geht.
Den Quellcode können dann immernoch mit einer Git verwaltet werden.
Das währe dann volkommen Systemfrei.
Für den einfachen Benutzer währe dann nur eine seite wo er sich sein System/Programm herraussucht.

Ja, wieso nicht? Der Einfachheit halber könnte man nächtens ein gewisses Set an Software (TriOS, Toolboxen + X) bauen und den entstehenden bin-Ordner auch in GIT ablegen. So wie das nach einem make Aufruf aktuell der Fall ist.
Damit hätte der Einsteiger immer eine aktuelle Version für erstes Tests zur Hand, die er direkt flashen kann. Die Fortgeschrittenen können dann immer noch über die Sourcen eigene Stände der Software bauen.

[nubok]

Du musst bedenken nicht jeder will oder kann sich so intensiv mit der Programmierung befassen und daher auch mein Gedanke mit dem Server.

Mit der Grundprämisse, dass nicht jeder sich intensiv mit Programmierung beschäftigen kann oder will, kann ich leben. Allerdings bin ich der Meinung, dass die Lösung des Problems darin bestehen sollte, die Ecken und Kanten, mit denen auch jeder, der mitprogrammieren will, konfrontiert ist, zu entschärfen (da haben alle was davon: vom Endanwender bis zum aktiven Mitarbeiter). Und das ggf. so lange, bis das Ergebnis auch für die Masse tauglich ist.

Dadurch, dass man Binaries anbietet, verschwinden die Ecken und Kanten nicht. Wenn man bislang nur Binaries gesaugt hat, ist der Sprung zur aktiven Mitarbeit deutlich unangenehmer, als wenn man "im Prinzip" die ganzen notwendigen Prozesse bereits die ganze Zeit benutzt.

Ich bin mir bewusst, dass "mein" vorgeschlagener Weg der deutlich unangenehmere und steinigere ist, aber die Resultate dürften dies rechtfertigen.

[joergd]

Das Problem ist, dass sich bei der Projektpflege mit der Zeit dann leicht immer mehr Abhängigkeiten von irgendwelchen UNIX-/POSIX-typischen Programmen einschleichen - zuerst nur die Standard-Shell-Kommandos, dann "make", anschließend noch ein "wget" usw. - da kommt dann rasch im Laufe der Zeit ein Schwanz zusammen.

Deswegen ja mein Vorhaben, nichts weiter zu benötigen außer bstc. Wenn irgendwann doch noch etwas dazukommt, kannst Du mich bitte auf diese meine Aussage hinweisen

Damit gibts dann nur noch die make.sh die unter beiden Umgebungen (Linux/Windows) verwendet werden kann. Ich denke das passt.
Am besten die make.bat löschen, dann kann die Datei nicht bei Windows-Nutzern verwirren.

Wie in den anderen Beiträgen kurz angemerkt, sollten wir auch die make.bat erhalten bzw. (für die anderen Projekte) erstmal erstellen. Damit können auch Windows-Nutzer, welche kein Git mit Bash installieren wollen, dieses Projekt bauen (außer ich werde doch noch von einer anderen Variante überzeugt).

Warum kein php-skript auf einem Apache Server der kümmert sich dann um die binarys wenn es nur um die compilierung der Programme geht.

Da sehe ich keinen wirklichen Vorteil. Es geht ja meines Erachtens nicht darum, möglichst einfach an die Binaries zu kommen. Sondern alles aus den Quellen selbst auf dem eigenen Rechner zu erstellen. Wenn die Quellen nebst kompletter Build-Umgebung auf dem eigenen Rechner sind, ist die Hemmschwelle geringer, selbst mal was am Code zu ändern.

Warum sollte sich jemand der den HIVE nur zum Spielen oder aus freude am zusammenbau noch mit den ganzen Versionen solch einer Verwaltung rumm Ärgern wenn er seine gewünschten Programme oder das System durch einen Klick bekommen kann.

Bekommt er ja auf der Download-Seite vom Hive-Projekt. Nur eventuell nicht ganz aktuell. Das ist dann der Anreiz: Wer es ganz aktuell haben will, lädt sich die Quellen vom Git-Server runter und baut selbst.

[joergd]

Ich hab jetzt noch in alle Projekte (TriOS, Toolbox 1 und 2, Basic sowie Plexus) die Windows-Buildscripts (make.bat) eingecheckt. Wer von der Windows-Fraktion jetzt also kein Git installieren mag, kann sich die aktuellen Quellarchive per Browser über den Git-Server holen. In jedem Projekt gibt es unter "tree" die Möglichkeit des Downloads als ZIP- oder tar.gz-Archiv:

Download Archiv mit aktuellen Quellen

Aus meiner Sicht haben dann die einzelnen Projekte einen Status erreicht, um ein neues Release zu veröffentlichen. Vor allem betrifft das TriOS, die Änderungen seit dem 1 Jahr alten r56 stehen im Logbuch. Hier wäre noch die Frage, ob der IRC-Client drin bleiben oder in ein extra Projekt verschoben werden soll.

In den Toolboxen ist nicht viel passiert, außer daß ich die Boing-Demo in Toolbox-2 aufgenommen habe. Kann aber sein, daß aus den alten Toolboxen mit dem in Administra vorgenommenen Änderungen nicht mehr alles funktioniert.

In Basic und Plexus habe ich nur den Administra-Code entfernt, da wird auf den im TriOS enthaltenen zurückgegriffen.

Ich rufe also nochmal dazu auf, alles zu testen. Vor allem die Hardware-Erweiterungen (Sepia, Joystick...) konnte ich mangels Hardware nicht selbst testen. Und falls noch etwas aufgenommen werden soll: immer her damit. Wer seine Änderungen nicht schon selbst einchecken will, kann mir die auch gern auf anderen Wegen zur Verfügung stellen, ich pflege das dann ein.

[Zeus]

Habe mal versucht, das ganze unter Linux zu kompilieren.
bstc ging leider nicht, da mein RasPi überraschenderweise keinen Intel-Prozessor hat.
Daher habe ich einen Versuch mit OpenSpin (https://code.google.com/p/open-source-spin-compiler/) gewagt.
Mein Erkenntnisse bisher:
- Parameter "-O a" im make-Skript (bstc: alle Optimierungen einschalten) kennt OpenSpin nicht.
- OpenSpin legt die .binary-Datei im gleichen Verzeichnis ab wie die .spin-Datei. bstc legt die .binary-Datei (anscheinend) im akt. Verzeichnis ab. Daher klappt zwar das Kompilieren aus der make.sh, aber nicht die nachfolgenden cp/mv-Befehle.
- Umlaute mag der OpenSpin nicht. Daher meckert er tief in der bel-keyb.spin:400. Da taucht im Assembler-Code ein 'ä' auf. Vielleicht auch nur eine Frage der Compiler-Einstellung. Habe ich mir bis jetzt nicht näher angesehen.

Zumindest die ersten zwei Punkte liesen sich im make-Skript lösen, so dass dieses für beide Compiler funktioniert. Punkt drei müsste ich mir mal anschauen.

[kuroneko]

- Umlaute mag der OpenSpin nicht. Daher meckert er tief in der bel-keyb.spin:400. Da taucht im Assembler-Code ein 'ä' auf.

Funktioniert hier (wird als $E4 compiliert).

openspin: unter MingW32 mit der vor/letzten Revision vom git.

[joergd]

Daher habe ich einen Versuch mit OpenSpin (https://code.google.com/p/open-source-spin-compiler/) gewagt.

Meine ersten Versuche mit OpenSpin waren ja auch nicht erfogreich: Erfahrung mit simpleIDE
Meiner Meinung nach macht es momentan nicht viel Sinn, komplexe Sourcen wie TriOS mit OpenSpin übersetzen zu wollen. Ich werde es aber im Auge behalten, da das sicher die Zukunft ist. Zumindest tut sich jetzt auch mit meinen Bugreports etwas...