Wozu einen anderen Compiler?

[Uwe Raabe]

Zitat von runningsoft:

Warum benötigt man einen anderen Compiler als den in Delphi eingebauten?

Der paxCompiler läuft innerhalb der EXE beim Kunden um dessen Skripts zu compilieren. Er ist nicht dazu gedacht, deine Delphi-Sourcen zu compilieren.

[runningsoft]

Danke für die Antworten. Die geschilderten Szenarien liegen Gott sei Dank außerhalb meines Anwendungsbereiches für Delphi

[himitsu]

Jo, dieser "Compiler" erzeugt keine "eigenständigen EXEen".

Wie JavaScript, VBScript, Python usw., so wird hier einfach ein Pascal-Script ausgeführt,
nur dass des hier kein "einfacher" Interpreter ist, sondern er compiliert generiert ByteCode (quasi Assembler), welcher direkt von der CPU ausgeführt werden kann.

Andere Script-Interpreter parsend und führen direkt den Text-Code (langsam) aus,
wiederrum andere erstellen erstmal einen "eigenen" ByteCode und verarbeiten den dann selbst. (also statt direkt mit TEXT wird BINÄR gearbeitet ... z.B. siehe JAVA),
oder eben den TEXT in CPU-Befehle übersetzen und die CPU das machen lassen. (anstatt selbst jeden "BEFEHL" einzeln auszuführen)



PS: In Python kann man die Scripte auch in einen ByteCode compilieren lassen und jene dann ausführen ... geht schneller, als erst langsam den TEXT analysieren zu müssen.
python py pyc

[Jens01]

Als ich den PaxCompiler rausgeworfen habe, habe ich mir quasi eine kleine, eigene Entwicklungsumgebung geschaffen, womit ich dann kleine Skripte mit dem externen Delphi-Compiler DLLs compiliert habe, als Stream in eine Datenbank abgelegt und nach Bedarf direkt (über ein Tools von Github) in den Speicher geladen.

[freimatz]

Wenn das dann beim Anwender passieren soll, wird man eine Lizenz von EMB dazu benötigen.

[Jens01]

Zitat:

Wenn das dann beim Anwender passieren soll, wird man eine Lizenz von EMB dazu benötigen.

Schon klar. Das ist bei mir aber nicht so. Ich würde dann Freepascal o.ä. nehmen.