Leider noch eine Ergänzung: Die Versionsverwaltung Grev.exe wird nicht mehr ausgeführt. An der Grev.exe liegt*s wohl nicht, da ein Austausch nichts brachte.
Wilfried
Aktuelles SDK
-
OK, hier das gleiche, beide Issues scheinen in Verbindung mit der Projektanlage im LOCAL_ROOT zu stehen.
Bei den internen Tools liegen die Source im SDK selbst unter:
pcgeos/Library/Ruler
(bitte Ruler-Ordner einfach dort hinkopieren) und gebaut wird unter
pcgeos/Installed/Library/Ruler
Die dort liegenden Datein einfach löschen und dann regulär mkmf, dann pmake.
Kannst Du das mal probieren?
-
Weitere Erkenntnis, es ist wichitg, das Ruler im Library-Verzeichnis angelegt ist. Dann baut es auch mit Versionsnummer im LOCAL_ROOT.
Im bisher verwendeten SDK konntest Du es im appl-Verzeichnis bauen? -
Hallo Falk,
bisher hatte ich immer (vergeblich) versucht, die Libraries in selben Verzeichnis wie meine "normalen" Projekte zu compilieren
. Die Voraussetzungen für das Compilieren von Libraries waren mir nicht bekannt. Ich hab's jetzt so gemacht, wie du beschrieben hast und meine GSDK-SHELL.cmd angepasst (Pfad für LOCAL_ROOT): Ruler wird problemlos compiliert 
, so auch mit meinem bisherigen SDK. Bei Grobj treten bei pmake noch 3 Fehler in der Grobj.gp auf (eine nicht definierte Resource, 2 nicht definierte Export-Routinen), was ich mir erstmal näher ansehen werde.Die Sache mit Grev hab ich wohl missverständlich ausgedrückt: In meinen "normalen" Applikationen oder auch bei TicTac wird die Versionsnummer nicht weitergezählt (im Gegensatz zu meinem bisherigen SDK). Beim Compilieren von Ruler klappt es aber.
Wilfried
-
Hi Wilfried, ist mir gar nicht so bekannt, Versionsnummer wurden automatisch hochgezählt? Das habe ich bisher noch nie beobachten können. Ruler zählt bei mir nicht automatisch hoch...
Viele Grüße,
Falk -
Interessant. Kann sein, das es nur im LOCAL_ROOT so ist und nicht unter Installed?.... ich glaube ich muß mir das nochmal genauer ansehen.
Und für Dich geht das für Ruler im LOCAL_ROOT und für Deine Appl nicht? -
Welches SDK verwendest Du bisher?
-
Das Updaten der Releasenummer ist schon extrem wichtig. Der Uni-Installer z.B. verlässt sich darauf, um nicht eine Library (oder was auch immer) mit einer älteren Version zu überschrieben, nur weil man ein älteres Paket installert.
Vielleicht liegts an der grev.exe. Da gibt es mehrere Versionen, die sich auch in der Aufruf-Synatx unterscheiden. Und wenn pmake grev mit mit der falschen Syntax ruft, dann passiert eben nichts.
Gruß
Rainer -
Hallo Wilfried,
natürlich vergleicht der Uni-Installler nicht nur die letzte Ziffer, sondern alle. Er überschreibt also die Version 2.5.7.1 NICHT mir der Version 1.1.2.19.
Und ja, für die anderen Ziffern bist du zuständig, wobei es da noch die Anweisung #incminor in der GP gibt, die die vorletzte Ziffer um 1 erhöht. Sehr praktisch!
Aber wenn du erst die Version 1.7.x.x und dann die Version 1.6.x.x mit neuen Features raus gibst, dann ist dir halt nicht zu helfen
Gruß
Rainer -
Unter pcgeos/Include/Win32/geos.mk
das Nokia SDK definiert:
_REL != $(GREV) neweng $(REVFILE) $(GREVFLAGS) -R -s
das Breadbox SDK hingegen definiert:
_REL != $(GREV) neweng $(REVFILE) $(GREVFLAGS) -R
Das -s sorgt für das speichern, wurde bei Breadbox SDK bewußt entfernt. Wir müssen entscheiden, ob wir das wieder aufnehmen sollten.
-
Rainer:
Jetzt hab ich dich richtig verstanden
.Falk:
<<wurde bei Breadbox SDK bewußt entfernt>>
bewusst hei0t doch, dass es einen Grund geben muss. Welchen? -
Wie gesagt, das automatische Hochzählen der Versionsnummer halte ich für EXTREM wichtig. SEHR EXTREM um genau zu sein.
Rainer
P.S. auch wenn ich den Sinn der Codezeilen nicht verstanden habe -
halte ich für EXTREM wichtig. SEHR EXTREM
Und das als Mathematiker;-).
-
Verehrter Herr Seifert,
Versuch einer konstruktiven Antwort auf Ihren Beitrag im Thread 'PC/Geos in the Press':<<Also wurde nach meinem Verständnis ein unvollständiges SDK frei gegeben wobei es dann kein Wunder ist, dass sich das nicht einfach so "on scratch" übersetzen lässt.>>
Das SDK, das als Beta-Version auf http://blog.bluewaysw.de angeboten wird, ist ein fertiges SDK. Da muss nichts übersetzt werden. Sie könnten damit sofort loslegen.Danke!
Werd ich mir anschauen. Vielleicht geht es dann flotter. Allerdings hat mich irretiert, das das SDK dort und nicht auf Github zum Download angeboten wird. Da schau ich mal hier in der Goes Präsenz nach den Downlods.
Allerdings werden noch ein paar Sachen benötigt: Der Borland-Compiler und der Perl-Interpreter. Das alles können Sie hier unter http://geos-infobase.de/SDK/SDK.HTM bekommen. Die Konfiguration können Sie hier auch nachlesen.Ok, schau ich mir auch an. Den Perl Interpreter habe ich mir damals zusammen mit dem Watcom Compiler schon runter geladen und installiert, ich hhoffe, ich kann den dann auch in dieser Version weiter verwenden. Hab das gemacht, als das SDK frei gegeben wurde, zimlich unmittelbar nacvh Eurem letzten Geos Treffen in Syhra. Biher war ja da der nicht frei verfügbare BDD3.X Compiler nötig. Es gibt ja auch den frei downloadbaren BCC5.5. Geht jetzt also auch oder brauche ich zwingend die Version 4.5?
Am besten fängt man damit an, ein paar im SDK enthaltene Samples zu compilieren, um überhaupt mal in das Programmieren mit dem SDK hinein zu schnuppern.Bei den oben suggerierten Aussichten werde ich da auch machen. Zuerst mnatürlich die Anleitungen durcharbeiten.
Rechtsunsicherheit muss bei der Arbeit mit dem SDK sicher nicht befürchtet werden.Heißt das, ich darf die übersetzten Programme einschließlich GEOS selber an Freedos weiter geben, sobald mir die Übersetzung gelungen ist?
