Sie sind nicht angemeldet.

41

Montag, 4. März 2019, 12:15

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

42

Mittwoch, 6. März 2019, 21:54

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?

43

Mittwoch, 6. März 2019, 22:00

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?

44

Donnerstag, 7. März 2019, 11:59

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 :thumbsup: , 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

45

Sonntag, 10. März 2019, 11:10

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

46

Sonntag, 10. März 2019, 12:08

Hallo Falk,

Ruler kam zu mir mit R 4.1.0.0 <Administrator> <15:32:04 Feb 10, 2004> <BBox>
Mittlerweile ist der Stand: R 4.1.0.64 <WK> <10:48:04 Mar 10, 2019> <>
WK ist mein Benutzername.

Wilfried

47

Sonntag, 10. März 2019, 17:14

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?

48

Sonntag, 10. März 2019, 18:47

Ich hab's eben noch mal getestet: Mit dem 'neuen' SDK wird die jeweilige .rev-Datei nicht angetastet, egal ob ich meine Applikationen oder eine Library kompiliere. Das bisherige SDK tut's dagegen.

49

Sonntag, 10. März 2019, 18:56

Vielleicht ist für dich der Screenshot hilfreich. Die versionsnummer soll wohl erhöht werden (an der letzten Stelle).
»Wilfried« hat folgende Datei angehängt:
  • rulerpmake.jpg (78,86 kB - 125 mal heruntergeladen - zuletzt: Heute, 08:34)

50

Sonntag, 10. März 2019, 22:48

Welches SDK verwendest Du bisher?

51

Sonntag, 10. März 2019, 23:49

SDKVER.bat sagt:

Nokia 9000v20 GEOS SDK for Windows NT
echo Version Number: 2.0
echo Engineering Release: 2.3.5
echo 8/19/97

GeosSetup.exe sagt: NTSDK30b.v2

52

Montag, 11. März 2019, 14:44

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
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

53

Montag, 11. März 2019, 23:00

Hallo Rainer,

<<Der Uni-Installer z.B. verlässt sich darauf, um nicht eine Library (oder was auch immer) mit einer älteren Version zu überschrieben,>>

das hab ich nicht ganz verstanden. Wenn der Versions-Update-Mechanismus richtig läuft, dann wird bei jedem erfolgreichen pmake-Durchlauf doch nur der Wert der letzten Zifferngruppe incrementiert. Für alle anderen Zifferngruppen ist der Entwickler selber zuständig. Wenn der Installer eine z.B. Library nicht überschreibt, weil die letzte Zifferngruppe höherwertig ist, dann läuft da doch etwas falsch.

Wilfried

54

Dienstag, 12. März 2019, 07:06

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
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

55

Dienstag, 12. März 2019, 07:38

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.

56

Dienstag, 12. März 2019, 10:10

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?

57

Mittwoch, 13. März 2019, 20:11

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 ;-)
Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

58

Mittwoch, 13. März 2019, 21:30

halte ich für EXTREM wichtig. SEHR EXTREM


Und das als Mathematiker;-).

Zur Zeit sind neben Ihnen 3 Benutzer in diesem Thema unterwegs:

3 Besucher

Ähnliche Themen

Thema bewerten