Wie erstelle ich ein eigenes Modul...

Übersicht

BlitzMax, BlitzMax NG

FAQs und Tutorials

	d-bug Betreff: Wie erstelle ich ein eigenes Modul...	Fr, Nov 17, 2006 23:41 Antworten mit Zitat
Ich nehme mir mal die Frechheit heraus ein kleines Tutorial über das erstellen eigener Module zu schreiben... Wichtig Um ein Modul kompilieren zu können muss zuvor MinGW installiert worden sein. Siehe dazu folgenden Link... Der Pfad Wie ihr wohl schon gesehen habt gibt es in eurem BlitzMax Ordner einen Unterordner namens Mod. Dort muss nun auch euer Quellcode für das neue Modul gespeichert werden : Code: [AUSKLAPPEN] [EINKLAPPEN] ..BlitzMax\mod\meinscope.mod\meinmodul.mod\meinmodul.bmx Blitzmax\Mod\ (<-- Win32 Gedöns) Dies sollte eigentlich soweit klar sein. MeinScope.mod Dies ist ein Unterordner, in dem du deine Modulsammlung zusammen fassen kannst. Dies hat den Vorteil, dass man z.B. mehrere Module mit dem gleichen Namen, aber von verschiedenen Autoren haben kann, ohne das BMax anfängt zu zetern. BRL.Mod oder Pub.Mod sind z.B. solche Scopes, ich würde allerdings davon abraten dort meine eigenen Module zu speichern, da dort jeder seine Module speichern kann und es dementsprechend auch zu tollen Konflikten kommen kann. MeinModul.mod Dies ist wieder ein Unterordner, der den Namen deines zukünftigen Moduls tragen muss. Hier wird dein eigentlicher Code rein gespeichert. MeinModul.bmx Jetzt kommen wir endlich zum eigentlichen Codefile. Dies muss allerdings genau so heißen, wie der Ordner in dem es gespeichert wurde. Natürlich nur der Dateiname, ohne die Endung (Suffix). Abschließend ist zu diesem Thema noch zu sagen, dass weder Sonderzeichen noch Zahlen in Scope und Modul-Ordner angenommen werden. Dies ist auch unbedingt nötig, da OSX und Linux nicht so tolerant mit Pfaden umgehen wie Windows. Der Quellcode Code: [AUSKLAPPEN] [EINKLAPPEN] Rem bbdoc: MeinModul End Rem Module MeinScope.MeinModul ModuleInfo "Version: 1.02" ModuleInfo "Author: DerUnglaublicheUeberCoder" ModuleInfo "License: Public Domain" ModuleInfo "History: 1.02 schwafel schwufel schwubb" ModuleInfo "History: 1.01 blablabla" ModuleInfo "History: 1.00 Erste Ausgabe meines Uebermoduls" SuperStrict Import "brl.max2d" 'usw... 'usw... '...mein ganzer toller Code... Rem ... End Rem Dies ist ein Dokumentations Block (siehe unten). Wenn dieser nicht vorhanden ist, liest Docmods die Doku deines Moduls nicht aus. (Danke BtbN) Module MeinScope.MeinModul Diese Zeile muss in einem Modul immer oben stehen. Natürlich bestätigen auch hier wieder Ausnahmen die Regel. Kommentare, Strict oder Superstrict können auch über dieser Zeile stehen. Damit sagt man BMax, dass es sich um ein Modul handelt und wo es zu finden ist. Wie man sieht bezieht sich das ganze auf die Unterordner MeinScope und MeinModul.mod, die wir oben erstellt haben. ModuleInfo Hier kann man alles mögliche an Text unterbringen. Wichtig sind allerdings die oben angegebenen Einträge Version, Author, License und History. Framework Leider ist ein Modul ohne eigenes Framework nicht lebensfähig. Wenn ihr also lustige Befehle verwenden wollt, dann müsst ihr auch das passende Modul in euer Modul importieren. Zum Beispiel möchtet ihr den Befehl DrawText in eurem Modul verwenden, so müsst ihr zuvor das Modul BRL.Max2D in euer Modul importiert haben. Ich sage euch hiermit schon mal anfangs viele Fehlermeldungen beim kompilieren vorraus, denn es nicht so einfach, alle relevanten Module in seinen Code zu bekommen, wie es sich anhört. Man muss anfangs sehr viel suchen, aber das gibt sich mit der Erfahrung. Dokumentation Code: [AUSKLAPPEN] [EINKLAPPEN] Rem bbdoc: Meine tolle Funktion macht etwas tolles. returns: Sie gibt auch was zurück (hoffentlich) about: Meine tolle Funktion ist dazu gedacht etwas tolles zu machen... End Rem bbdoc: Dies ist eine Kurzbeschreibung deiner Funktion oder des ganzen Moduls. returns: Hier wird eingetragen, was deine Funktion zurück gibt. about: Hier wird eine ausführliche Beschreibung eingetragen. Ehrlich gesagt finde ich es hier ein bisschen zu viel auf die komplette Funktionalität von DocMods einzugehen, also recherchiert das doch bitte selbst... Trotzdem ist es für dich, als verantwortungsvoller Programmierer, deine verdammte Pflicht, dein Modul vernünftig zu dokumentieren. Schließlich kann nicht jeder in deinen Schädel schauen. Kompilieren Die einfachere Variante ist es sicherlich im Menü der IDE unter Program -> Build Modules (oder STRG+D) alle Module kompilieren zu lassen. Wenn ihr immer fleisig, nach jedem Synchronisieren, eure Module kompiliert habt, sollte es auch nicht sehr lange dauern. Die etwas schwierigere Variante findet ihr zu hauf, wenn ihr die Forensuche nach dem Stichwort BMK abklappert. mal kurz gesagt : bmk makemods -r meinscope.meinmodul (erstellt die Release Version deines Moduls) bmk makemods -d meinscope.meinmodul (erstellt die Debug Version deines Moduls) bmk makemods -a meinscope.meinmodul (erstellt Release und Debug Version) sowohl Release- als auch Debug-Version deines Moduls sind später notwendig um den reibungslosen Ablauf von BMax zu garantieren. docmods meinscope.meinmodul (erstellt die HTML Dokumentation für dein Modul) docmods und bmk findet ihr im Verzeichniss ..BlitzMax\bin Ich werde, mit Sicherheit, etwas in diesem Tutorial ausgelassen haben, was für mich mittlerweile selbstverständlich ist. Bitte nicht gleich steinigen. Viel Spaß und Glück beim erstellen eurer Module. (...extra für den ollen Saarheini aus den Rippen gezogen...)

d-bug

Betreff: Wie erstelle ich ein eigenes Modul...

Fr, Nov 17, 2006 23:41
Antworten mit Zitat

Ich nehme mir mal die Frechheit heraus ein kleines Tutorial über das
erstellen eigener Module zu schreiben...

Wichtig
Um ein Modul kompilieren zu können muss zuvor MinGW installiert worden
sein. Siehe dazu folgenden Link...

Der Pfad
Wie ihr wohl schon gesehen habt gibt es in eurem BlitzMax Ordner einen
Unterordner namens Mod. Dort muss nun auch euer Quellcode für das neue
Modul gespeichert werden :
Code: [AUSKLAPPEN]

..BlitzMax\mod\meinscope.mod\meinmodul.mod\meinmodul.bmx

Blitzmax\Mod\ (<-- Win32 Gedöns)
Dies sollte eigentlich soweit klar sein.

MeinScope.mod
Dies ist ein Unterordner, in dem du deine Modulsammlung zusammen
fassen kannst. Dies hat den Vorteil, dass man z.B. mehrere Module
mit dem gleichen Namen, aber von verschiedenen Autoren haben
kann, ohne das BMax anfängt zu zetern. BRL.Mod oder Pub.Mod sind z.B.
solche Scopes, ich würde allerdings davon abraten dort meine eigenen
Module zu speichern, da dort jeder seine Module speichern kann und
es dementsprechend auch zu tollen Konflikten kommen kann.

MeinModul.mod
Dies ist wieder ein Unterordner, der den Namen deines zukünftigen Moduls
tragen muss. Hier wird dein eigentlicher Code rein gespeichert.

MeinModul.bmx
Jetzt kommen wir endlich zum eigentlichen Codefile. Dies muss allerdings
genau so heißen, wie der Ordner in dem es gespeichert wurde. Natürlich
nur der Dateiname, ohne die Endung (Suffix).

Abschließend ist zu diesem Thema noch zu sagen, dass weder Sonderzeichen
noch Zahlen in Scope und Modul-Ordner angenommen werden. Dies ist auch
unbedingt nötig, da OSX und Linux nicht so tolerant mit Pfaden umgehen
wie Windows.

Der Quellcode
Code: [AUSKLAPPEN]

Rem
bbdoc: MeinModul
End Rem
Module MeinScope.MeinModul
ModuleInfo "Version: 1.02"
ModuleInfo "Author: DerUnglaublicheUeberCoder"
ModuleInfo "License: Public Domain"
ModuleInfo "History: 1.02 schwafel schwufel schwubb"
ModuleInfo "History: 1.01 blablabla"
ModuleInfo "History: 1.00 Erste Ausgabe meines Uebermoduls"

SuperStrict

Import "brl.max2d"

'usw...
'usw...

'...mein ganzer toller Code...

Rem ... End Rem
Dies ist ein Dokumentations Block (siehe unten). Wenn dieser nicht vorhanden ist,
liest Docmods die Doku deines Moduls nicht aus.
(Danke BtbN)

Module MeinScope.MeinModul
Diese Zeile muss in einem Modul immer oben stehen. Natürlich bestätigen
auch hier wieder Ausnahmen die Regel. Kommentare, Strict oder
Superstrict können auch über dieser Zeile stehen. Damit sagt man BMax,
dass es sich um ein Modul handelt und wo es zu finden ist. Wie man sieht
bezieht sich das ganze auf die Unterordner MeinScope und MeinModul.mod,
die wir oben erstellt haben.

ModuleInfo
Hier kann man alles mögliche an Text unterbringen. Wichtig sind allerdings die oben
angegebenen Einträge Version, Author, License und History.

Framework
Leider ist ein Modul ohne eigenes Framework nicht lebensfähig.
Wenn ihr also lustige Befehle verwenden wollt, dann müsst ihr
auch das passende Modul in euer Modul importieren. Zum Beispiel
möchtet ihr den Befehl DrawText in eurem Modul verwenden, so müsst
ihr zuvor das Modul BRL.Max2D in euer Modul importiert haben.

Ich sage euch hiermit schon mal anfangs viele Fehlermeldungen beim kompilieren vorraus, denn
es nicht so einfach, alle relevanten Module in seinen Code zu bekommen, wie es sich anhört.
Man muss anfangs sehr viel suchen, aber das gibt sich mit der Erfahrung.

Dokumentation
Code: [AUSKLAPPEN]

Rem
bbdoc: Meine tolle Funktion macht etwas tolles.
returns: Sie gibt auch was zurück (hoffentlich)
about: Meine tolle Funktion ist dazu gedacht etwas tolles zu machen...
End Rem

bbdoc:
Dies ist eine Kurzbeschreibung deiner Funktion oder des ganzen Moduls.

returns:
Hier wird eingetragen, was deine Funktion zurück gibt.

about:
Hier wird eine ausführliche Beschreibung eingetragen.

Ehrlich gesagt finde ich es hier ein bisschen zu viel auf die komplette
Funktionalität von DocMods einzugehen, also recherchiert das doch bitte
selbst...

Trotzdem ist es für dich, als verantwortungsvoller Programmierer, deine
verdammte Pflicht, dein Modul vernünftig zu dokumentieren. Schließlich
kann nicht jeder in deinen Schädel schauen. Wink

Kompilieren
Die einfachere Variante ist es sicherlich im Menü der IDE unter Program -> Build Modules
(oder STRG+D) alle Module kompilieren zu lassen. Wenn ihr immer fleisig, nach jedem
Synchronisieren, eure Module kompiliert habt, sollte es auch nicht sehr lange dauern.
Die etwas schwierigere Variante findet ihr zu hauf, wenn ihr die Forensuche nach dem
Stichwort BMK abklappert.

mal kurz gesagt :

bmk makemods -r meinscope.meinmodul (erstellt die Release Version deines Moduls)
bmk makemods -d meinscope.meinmodul (erstellt die Debug Version deines Moduls)
bmk makemods -a meinscope.meinmodul (erstellt Release und Debug Version)

sowohl Release- als auch Debug-Version deines Moduls sind später notwendig
um den reibungslosen Ablauf von BMax zu garantieren.

docmods meinscope.meinmodul (erstellt die HTML Dokumentation für dein Modul)

docmods und bmk findet ihr im Verzeichniss ..BlitzMax\bin

Ich werde, mit Sicherheit, etwas in diesem Tutorial ausgelassen haben, was für mich
mittlerweile selbstverständlich ist. Bitte nicht gleich steinigen. Wink

Viel Spaß und Glück beim erstellen eurer Module.

(...extra für den ollen Saarheini aus den Rippen gezogen...)

Zuletzt bearbeitet von d-bug am Sa, Nov 18, 2006 16:43, insgesamt 3-mal bearbeitet

	BtbN	Sa, Nov 18, 2006 12:24 Antworten mit Zitat
Also, wenn ich mich nicht irre muss das MinGW nicht zwigend installiert sein. Nur wenn man C/++ Code in seinem Modul verwendet. Und docmods ist mitlerweile in einem eigenen Programm. Zitat: Diese Zeile muss in einem Modul immer zuerst stehen. Naja, das SuperStrict/Strict kann ruhig dadrüber stehen, das ist egal. Hier ein Auszug aus BRL.Audio: Code: [AUSKLAPPEN] [EINKLAPPEN] Strict Rem bbdoc: Audio end rem Module BRL.Audio Und dieses Rem mit bbdoc infos MUSS da hin, damit docmods das modul überhaupt dokumentiert. Das wars erstmal. Wenn mir noch was auffällt, liefer ichs nach.

BtbN

Sa, Nov 18, 2006 12:24
Antworten mit Zitat

Also, wenn ich mich nicht irre muss das MinGW nicht zwigend installiert sein.
Nur wenn man C/++ Code in seinem Modul verwendet.
Und docmods ist mitlerweile in einem eigenen Programm.

Zitat:

Diese Zeile muss in einem Modul immer zuerst stehen.

Naja, das SuperStrict/Strict kann ruhig dadrüber stehen, das ist egal.
Hier ein Auszug aus BRL.Audio:

Code: [AUSKLAPPEN]

Strict

Rem
bbdoc: Audio
end rem
Module BRL.Audio

Und dieses Rem mit bbdoc infos MUSS da hin, damit docmods das modul überhaupt dokumentiert.

Das wars erstmal. Wenn mir noch was auffällt, liefer ichs nach.

	klepto2	Sa, Nov 18, 2006 13:22 Antworten mit Zitat
Um Module zu bauen wird MinGW zwingend benötigt, das mit C/C++ bezieht sich auf normalen Quelltext. Also angenommen du hast in deinem normalen Source eine C Datei importiert, dann benötigst du ebenfalls MinGW.
Matrix Screensaver Console Modul für BlitzMax KLPacker Modul für BlitzMax HomePage : http://www.brsoftware.de.vu

klepto2

Sa, Nov 18, 2006 13:22
Antworten mit Zitat

Um Module zu bauen wird MinGW zwingend benötigt, das mit C/C++ bezieht sich auf normalen Quelltext. Also angenommen du hast in deinem normalen Source eine C Datei importiert, dann benötigst du ebenfalls MinGW.

Matrix Screensaver
Console Modul für BlitzMax
KLPacker Modul für BlitzMax

HomePage : http://www.brsoftware.de.vu

	d-bug	Sa, Nov 18, 2006 13:44 Antworten mit Zitat
Okay, die Docmods Geschichte nehme ich mal so hin, Btbn, denn ich selbst verwende es eigentlich nie. Ich gehöre zu den Hotdocs Jüngern. Da ist es egal, ob die ersten Zeilen ein Remblock sind. Strict und Superstrict zählt für mich eher zur Geschmackssache. Ich hab eben lieber die ganzen Infos oben stehen. Werde aber das Tut noch ein wenig nach bessern. Bei MinGW gebe ich klepto2 recht. cheers

d-bug

Sa, Nov 18, 2006 13:44
Antworten mit Zitat

Okay, die Docmods Geschichte nehme ich mal so hin, Btbn, denn ich selbst verwende es eigentlich nie. Ich gehöre zu den Hotdocs Jüngern. Da ist es
egal, ob die ersten Zeilen ein Remblock sind.

Strict und Superstrict zählt für mich eher zur Geschmackssache. Ich hab eben
lieber die ganzen Infos oben stehen. Werde aber das Tut noch ein wenig
nach bessern.

Bei MinGW gebe ich klepto2 recht.

cheers

	BtbN	Sa, Nov 18, 2006 16:37 Antworten mit Zitat
Ich habs grad nochmal getestet, ich habe auf meinem PC kein MinGW, und habe ein Test-Modul erstellt: Code: [AUSKLAPPEN] [EINKLAPPEN] SuperStrict Rem bbdoc: Test EndRem Module BtbN.Test ModuleInfo "Hallo!" Import BRL.StandardIO Function Bla() Print "Hallo!" EndFunction Und das kompilieren klappt super: Zitat: C:\Programme\BlitzMax\bin>bmk makemods btbn Compiling:test.bmx flat assembler version 1.66 3 passes, 913 bytes. Archiving:test.debug.win32.x86.a Compiling:test.bmx flat assembler version 1.66 3 passes, 535 bytes. Archiving:test.release.win32.x86.a Und das, obwohl ich kein MinGW habe.

BtbN

Sa, Nov 18, 2006 16:37
Antworten mit Zitat

Ich habs grad nochmal getestet, ich habe auf meinem PC kein MinGW, und habe ein Test-Modul erstellt:

Code: [AUSKLAPPEN]

SuperStrict

Rem
bbdoc: Test
EndRem
Module BtbN.Test
ModuleInfo "Hallo!"

Import BRL.StandardIO

Function Bla()
Print "Hallo!"
EndFunction

Und das kompilieren klappt super:

Zitat:

C:\Programme\BlitzMax\bin>bmk makemods btbn
Compiling:test.bmx
flat assembler version 1.66
3 passes, 913 bytes.
Archiving:test.debug.win32.x86.a
Compiling:test.bmx
flat assembler version 1.66
3 passes, 535 bytes.
Archiving:test.release.win32.x86.a

Und das, obwohl ich kein MinGW habe.

	Dreamora	Sa, Nov 18, 2006 16:48 Antworten mit Zitat
Das ist logisch, da bei dem Module build ja auch kein C Source kompiliert werden muss. Da die Module andere importe Module nur referenzieren (also das StandardIO wird einfach aufgerufen wie eine DLL, es ist nicht Teil von deinem Modul), kannst du bei reinen BM Code Modulen auf MingW verzichten.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Sa, Nov 18, 2006 16:48
Antworten mit Zitat

Das ist logisch, da bei dem Module build ja auch kein C Source kompiliert werden muss.
Da die Module andere importe Module nur referenzieren (also das StandardIO wird einfach aufgerufen wie eine DLL, es ist nicht Teil von deinem Modul), kannst du bei reinen BM Code Modulen auf MingW verzichten.

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Übersicht

BlitzMax, BlitzMax NG

FAQs und Tutorials

Nach Oben

BlitzBasic Portal

Wie erstelle ich ein eigenes Modul...

d-bug

Betreff: Wie erstelle ich ein eigenes Modul...

BtbN

klepto2

d-bug

BtbN

Dreamora