OS4 Entwicklung: Eure Toolchain?

[Arminius]

Hey zusammen,

mich würden mal eure Entwicklungsumgebungen / Toolchains für die Entwicklung unter OS4 Erinnerung? Was nehmt ihr zum Code schreiben, kompilieren, debuggen, ... ?

Im Netz konnte ich keine Beispiele und "Best Practice" zu OS4.1 finden. Ich fände es spannend, die Info an einer Stelle zusammenzutragen und evtl. als Tutorial für Ein- und Umsteiger zusammenzufassen.

Also, was würdet ihr in diesem Fall empfehlen und was ist unbedingt zu beachten?

[whose]

Hey zusammen,

mich würden mal eure Entwicklungsumgebungen / Toolchains für die Entwicklung unter OS4 Erinnerung? Was nehmt ihr zum Code schreiben, kompilieren, debuggen, ... ?

Auf jeden Fall schon mal das SDK... dazu Codebench. Ein wirklich funktionierender (und bedienbarer) Debugger ist derzeit nicht in Sicht. gdb funktioniert nicht unbedingt so, wie es sollte, und Debug101 ist noch nicht so weit, wie es sein sollte.

Der Codebench-Editor lahmt leider etwas, ist aber dennoch gut bedienbar und erfüllt seinen Zweck gut. Inzwischen scheint auch der vbcc in Sachen Fehlerausgabe unterstützt zu werden, ich hatte aber noch keine Zeit, das einmal ordentlich zu testen

Im Netz konnte ich keine Beispiele und "Best Practice" zu OS4.1 finden. Ich fände es spannend, die Info an einer Stelle zusammenzutragen und evtl. als Tutorial für Ein- und Umsteiger zusammenzufassen.

http://wiki.amigaos.net/wiki/DeveloperDoc:Main

Dort, aber auch in den anderen Abteilungen findet man einiges an Information. Leider ist noch lange nicht alles auf dem aktuellen Stand, aber dennoch hilfreich.

[JoTo]

SDK
GoldED aus CubicIDE
Dann ein make und gcc läuft los

[Cyborg]

Jupp, hier auch Cubic IDE plus Shell. Wobei ich, wie JoTo, nur den Editor nutze. Goose hat das OS4 SDK aber komplett in Cubic eingebunden, was mit etwas Arbeit kein Problem ist.. nur nicht meine persönliche Arbeitsweise

[Arminius]

Das ist aber noch eine überschaubare Teilnahme hier - hatte auf mehr Antworten gehofft

Nutzt jemand eigentlich einen Cross-Compiler?

[imagodespira]

Wir nutzen hier CubicIDE (Cyborg: GoosE heißt Gans, Goos reicht ), das läuft perfekt. Ich habe mich mal einen Tag hingesetzt und mit Maktros CubicIDE so eingerichtet, dass die Tastatur wie heute üblich funktioniert (auch strg+c zum kopieren usw.) Compilieren geht alles daraus... passt. Frank hat mir dann die SDK/Compiler Sache gemacht.

Codebench habe ich probiert, da sind mir einfach 1000 Fenster zu viel und der Start dauerte ewig (weil irgendwelche SDK Sachen jedesmal neu eingelesen werden, Stand 1 Jahr her ca.).

Ich glaube Frank spielte vor kurzem mit Crosscompiler herum, weiß aber nicht ob er das weiter verfolgt hat (unsere Engine soll irgendwann auf allen Systemen auf einem Stand sein).

Ich weiß, dass Daniel Müßener (Daytona) und Michael St. Neitzel (AmigaRacer) erfolgreich mit Cross Compiler arbeiten.

[Cyborg]

@ imago
Pff.. kann ich doch nix dafür, wenn ich automatisch korrektes Englisch schreibe und dann ein anderes Wort dabei rauskommt

Ich fand es übrigens schon immer furchtbar bei GoldEd, daß viele Shortcuts aus der Windowswelt übernommen wurden und sich nicht an den AmigaOS-Standard gehalten wurde. Beim ganzen OS benutzt man RAmiga-C, nur der GoldEd meint, er könne es anders machen... und dann erst Alt-F4 zum Beenden... was hat sich Dietmar da nur gedacht

Dein "heutzutage üblich" ist übrigens nur bei Windowskisten "üblich". Bei mir ist es mangels Windows absolut nicht "üblich" sowas wie STRG-C zu benutzen. Aber wenn Du darauf stehst, sei es Dir vergönnt

@ Arminius
Crosscompiler benutze ich auch schon, aber nicht regelmäßig. Amigaentwicklung sollte m.E. auch auf einem Amiga gemacht werden. "Eat your own dog food", wie die Franzosen sagen Schwierig wird es nur dann, wenn man z.B. an Exec, AmigaBoot oder manchen Treiber arbeitet, denn da ist nach jeder Änderung halt ein Neustart nötig, was es auf ein und demselben Rechner schon sehr umständlich macht.

Für solche Fälle benutze ich gerne Crosscompiler, weil ich da halt schon wieder die nächste Änderung und Version fertig habe, bis der Amiga wieder hochgefahren ist. Ich habe zwar auch andere Amigas hier stehen, aber man hat ja nicht immer alle aufgebaut/angeschlossen.

Und weil ich gerade auch Exec als Beispiel nannte: wenn ich ein neues Release für alle Plattformen (8 inzwischen!) bauen muß, nehme ich auch prinzipiell meinen Mac als Kompiliersklave. Mit seinem 4/8-Kernigen i7@3GHz (*) sind alle 8 Varianten in kürzester Zeit gebaut, wohingegen der Amiga (egal, welcher) in der gleichen Zeit wahrscheinlich gerade mal mit einer Variante gerade so fertig werden würde, wenn überhaupt.

Außerdem ist es ganz praktisch, wenn man Amigazeug auch dann kompilieren kann, wenn man gerade nicht zu Hause ist. Was bei mir relativ häufig vorkommt.


(*) Die GCC-Anpassung an AmigaOS macht hier viel aus. Man könnte mit einigen Optimierungen und zusätzlichen Support vom OS weit mehr aus dem nativen GCC rausholen, als das derzeit der Fall ist. Hier ist nicht zufällig ein fähiger Coder, der Zeit und Lust hat, sich in den Untiefen von GCC auszutoben?

[Daytona675x]

90% meiner Entwicklung findet unter Windows 7 mittels Embarcadero RAD Studio XE 8 statt. Letzteres hat zwar ordentlich Macken, aber übersetzt dafür sehr flott (naja, und ich bin es einfach gewohnt, das Ding).
Fast alle meine Projekte sind daher so getrimmt, dass sie auch unter Windows laufen. D.h. der ganze Amiga-systemabhängige Kram ist gekapselt und, wenn nötig, mit analogem Windows-Fleisch gefüllt. So kann ich sehr komfortabel debuggen und testen, denn diese Windows-Version verhält sich und sieht praktisch genauso aus wie die Amiga-Version des jeweiligen Programms.

Wenn es dann ans Testen auf den Amigas (darunter fällt bei mir in der Regel AOS4, MorphOS und AROS x86) geht:
dafür habe ich mir ein Hilfstool namens "BuildAll" geschrieben, das als Input eine XML-Datei bekommt. Da drin gibt es einen "globalen" Bereich, in welchem insb. das RAD Studio Projektfile verlinkt ist und das Verzeichnis, in dem sich die ganzen Assets befinden. Außerdem gibt es für die verschiedenen Systeme und Varianten Sektionen (z.B. <aos4_warp3d> ), wo ergänzende defines o.ä. hinterlegt werden können. Oder auch systemspezifische Tooltypes oder Asset-Weichen o.ä.

Das Tool knattert dann durch das RAD-Studio-Makefile und den ganzen Rest, generiert für die gewünschten Systeme passenden GCC Makefiles, kopiert die Assets (für Demoversionen kann ich auch explizit sagen, dass die und die weggelassen werden sollen o.ä.), verschlüsselt und komprimiert alles was nach XML oder so riecht (Key steht auch im BuildAll-Script und wird vermatscht mit reingelinkt), kompiliert den ganzen Kram mittels Cygwin und der passenden GCC CrossCompiler unter Nutzung der RAM-Disk und aller CPU-Kerne für max. Performance, erzeugt die Icons und generiert fertige LHAs / ZIPs.

Ich kann diese Cross-Herangehensweise nur wärmstens empfehlen. Anders als Cyborg vertrete ich die Philosophie:
the right tool for the job.
Und sorry, bei aller Liebe: meiner Meinung nach ist keines der Amiga-Systeme das richtige Werkzeug, wenn es um Softwareentwicklung geht.
Aber natürlich jeder wie er mag.

Im Falle Tower57 wäre es jedenfalls kompletter Wahnsinn, das nativ zerfrickeln zu wollen. Das braucht mit seinen hunderten CPP Dateien und leider viel zu vielen Abhängigkeiten selbst auf meinem nicht gerade schlaffen PC bei Vollauslastung aller Kerne (4/8 4 GHz) und ausschließlicher RAM-Disk-Nutzung knapp 2 Minuten pro Amiga-Version, um durchzukompilieren. Grob hochgerechnet würde selbst mein X5000 / AOS4 hier locker eine dreiviertel Stunde brauchen (vmtl. eher mehr) - pro Version, versteht sich... Äh, nein danke.

Klar, bei kleinen Projekten, die nur aus einer Handvoll Dateien bestehen und am besten nur für ein OS gedacht sind, da ist es ziemlich Wurscht.
Auch bei mittelgroßen Projekten, die zwar aus nicht allzu wenigen Dateien bestehen, die aber die Abhängigkeiten durch forward declarations etc. so gering wie möglich gehalten haben, mag es noch okay sein, direkt auf einem Amiga-System zu werkeln. Ich könnte mir vorstellen, dass das das Szenario von Entwickler-X ganz gut trifft. Wobei ich einen brauchbaren Debugger definitiv vermissen würde. Bei T57 wäre ich jedenfalls sehr schnell sehr sehr wahnsinnig geworden, nach dem hundertsten Freeze und Reboot.

Auch die ogles2.library ist per Crosscompiler entstanden, allerdings nur mit Hilfe von cygwin und einem alten UltraEdit32.
Zwar ist die mit rund 30 (der eigentliche Lib-Code) plus 35 (der GLSL-nach-SPIRV-Compiler) cpp Units eher in die Kategorie klein / mittelgroß einzuordnen und ich habe hier auch keinen Debuggingvorteil und will auch nur eine Plattform bedienen, aber ich finde 15 Sekunden für einen Build irgendwie trotzdem angenehmer als 3 Minuten. Und wenn was schief ging, konnte der Amiga fröhlich rebooten - wenn er wieder oben war, dann lag die gefixte Version meistens schon auf dem am KVM-Switch eingestöpselten USB-Stick parat.

[Cyborg]

@ Daytona
Aber das ist ja genau der Grund, warum ich "eat your own dog food" vertrete! Auch wenn unsere Kisten rein von der theoretischen Rechenpower nicht an Deinen 4/8-Kerner mit 4GHz rankommen würden, könnte man Deine beispielhaften 3/4 Stunde durchaus auf einen Bruchteil zusammendampfen, wenn man im GCC die OS-Eigenheiten nutzen würde und nicht den saulangsam-aber-läuft-halt-überall-Kram. Dazu noch im OS einige Verbesserungen (Memory mapped files z.B.) und schon würde man in der Singlecoreleistung sicherlich schon weit näher an der Augenhöhe mit anderen Systemen sein.

Nur, wenn man diese Schwächen eben umgeht, indem man einfach die anderen Systeme benutzt, dann wird man auch nie den Drang verspüren, diese Schwächen auszumerzen.

Im Grunde ist doch genau das das Problem bei AmigaOS: die meisten spielen damit ein par Minuten am Tag rum, machen aber alles auch nur entfernt ernsthafte auf anderen Systemen. Fortschritt entsteht aber nur durch Notwendigkeit. Solange man die Notwendigkeit umgehen kann, braucht man auch keinen Fortschritt. Gerade bei Entwicklern ist das ein großes Problem.. natürlich werden weiterhin Kleinigkeiten verbessert, aber die großen Sachen geht man nicht an, weil man es Dank der anderen Systeme nicht braucht.

Verstehe mich nicht falsch: ich erkenne durchaus an, daß Du mit Deinen Multiplattformprojekten natürlich andere Parameter deutlich schwerer gewichten mußt, insbesondere da Du ja auch "nur" Einzelkämpfer bist. Aber das sehe ich als Sonderfall und nicht als das, worauf ich mich mit meiner Aussage bezog. Ich habe ja auch genau deswegen gesagt, daß Amigaprojekte auf Amigas gemacht werden sollten. Und wie ich oben ja schrieb, gibt es durchaus auch andere Gründe, auf einem zweiten System (Amiga, oder nicht) zu entwickeln, wie Dein OGLES-Beispiel der häufigen Reboots. Das ist aber jetzt nicht mein Punkt.

Überspitzt gesagt: würde man Deine Maßstäbe allgemein anlegen, dann müßten wir sofort aufhören, irgendwas mit oder an AmigaOS zu machen. Denn Stand heute ist AmigaOS garantiert für gar nichts "the right tool".

Leider sind die notwendigen Änderungen an GCC und dem OS nicht gerade trivial, so daß man schon jemanden mit genügen Gehirnschmalz dafür bräuchte. Diese Gruppe von Leuten tendiert aber eher sehr klein und bereits mit anderen Dingen sehr ausgelastet zu sein... und da es ja so jetzt auch grundsätzlich geht und für den kleinen Hobbycoder von nebenan auch reicht, wird es immer nach hinten geschoben und die Leute benutzen weiter lieber ein anderes System. (Ja, ich weiß.. es gibt noch andere Kriterien außer der Geschwindigkeit von GCC)

Wie gesagt, die Notwendigkeit oder der Bedarf ist der Motor für Fortschritt. War es schon immer, deshalb haben wir ja überhaupt erst alles, was wir heute haben... aber ich glaube, ich drehe mich hier irgendwie im Kreis :/

[tommysammy]

Da muss ich Cyborg recht geben. Ich versuche alles nur mit meinen Amiga`s zu machen. Ein anderer Rechner kommt nicht in Frage. Meistens komme ich immer ans Ziel und der PC oder so macht es auch nicht besser.Wenn man einen Amiga hat, sollte man nicht immer nach einen PC schielen, nur weil er vieles besser und schneller macht.