planetmaker schrieb:Genau diese Eigenschaft macht es eben zu einem nfo-Präprozessor, nicht mehr, nicht weniger. Es verwandelt die m4-makros in nfo - die dann von grfcodec als Compiler zu dem binären Endprodukt verwurstet werden.

Sag ich doch (s.o.)

planetmaker (ergänzt) schrieb:Die Definition von Compiler ist eben die Fähigkeit Quellcode einzulesen und entsprechende für die Zielplattform verwendbare Binärdateien (hier grf) auszugeben.

"Verwendbar" aber im Sinne von i.a. "nicht lauffähig" (da zB Bibliotheksfunktionen oder externe Objektmodule durch einen Linker oder das BS noch hinzugefügt werden müssen).

Aber wenn dich das glücklich macht, schreibe ich gerne noch einmal explizit, dass der Gebrauch von m4nfo zur Erzeugung von grf-Dateien auch das Programm grfcodec zwingend benötigt. (m4nfo ist ein "Übersetzer" (Quellsprache -> Zielsprache), grfcodec ist ein "compiler" (~ -> bytecode)).


Was natürlich keine Einschränkung bedeutet, im Gegenteil. Denn diese "Kompilierung" von nfo und Grafik zu einer "ausführbaren" grf-Datei ist zwar trivial (nfo-code wird praktisch zu 100% in die grf-Datei übernommen, Grafik wird kodiert und komprimiert), aber durch die Grafik-Kodierung doch zeitaufwendig, was mit einem nativen Programm wie grfcodec viel schneller bewerkstelligt werden kann, als durch ein interpretiertes Programm (trotz Anwendung von caching etc).

Insofern ist das Gesamtsystem aus m4nfo-Modulen und grfcodec wesentlich schneller als die Verwendung eines "integrierten Programms", was dann auch noch interpretiert abläuft, und auf dass man möglicherweise auch noch schichtenweise zusätzliche Schichten draufpacken muss, weil man zB keine sinnvollen Makroprozessor-Eigenschaften von Haus aus hat. Von anderen Nachteilen mal ganz abgesehen.

Ich schrieb ja schon anfangs:

mb schrieb:Der Ansatz ist allerdings unterschiedlich

Gruß
Michael