Welche Distro für Lazarus

[kralle]

Moin,

ich stelle hier mal die "ketzerische" Frage: "Welche Distro ist am Besten für Lazarus geeignet?"

Gibt es vielleicht eine Distro bei der die Pakete die man vor dem Start von fpcUpDeluxe installieren muss, schon installiert sind, so das man direkt mit fpcupdeluxe Lazarus installieren kann?

Und mit welcher Distro gibt es im Laufenden Betrieb die wenigsten Probleme mit Lazarus?

Hat das jemand Erfahrungen mit verschiedenen Distros im Zusammenhang mit Lazarus gemacht und mag seine Erfahrungen hier mitteilen?

Gruß Heiko

[af0815]

Stockkonservative Antwort: Debian

Die Basispakete die Fpc/Lazarus benötigen musst du natürlich vorher installieren. Da führt kein Weg daran vorbei.

[theo]

Keine Ahnung.
Ich benutze Lazarus auf OpenSUSE, Kubuntu und Raspberry Pi OS.
Ein paar Abhängigkeiten muss man immer mit installieren, aber dann läuft es eigentlich überall gleich gut.

[af0815]

Genauer definiert: Debian mit LXDE

Hat damit zu tun, das ich die stabilste, wenig anfälligste Distribution für lange Laufzeit benötige.

[Mathias]

Ich verwende Mint, ich habe das Gefühl das es da am einfachsten ist.
Mint-Standard-Installation. die paar Pakete wie hier beschrieben nachinstallieren, fpcupdeluxe durchlaufen lassen, fertig.
https://wiki.lazarus.freepascal.org/fpcupdeluxe/de
Ubuntu oder gar Debian sollte da etwa gleich sein.

Mit SuSE habe ich nicht so gute Erfahrungen gemacht. Dort braucht es viel Handarbeit, bis dieses Linux perfekt läuft.
SuSE ist mehr für erfahrene Freaks.

[Niesi]

Ich nutze Lazarus auch unter Linux Mint, installiert mit FpcUpDeLuxe - keine Probleme. Die notwendigen Pakete habe ich nach dem FreePascal Wiki installiert, ging ohne Probleme. Läuft sehr gut.
Mein Sohn nutzt Arche Linux, Manjaro - da haben wir heute mit FpcUpDeLuxe Lazarus noch mal installiert, die Installation mit der Anwendungsverwaltung war irgendwie fehlerhaft (kein Komponentenmenü). Erfahrung muss er jetzt erst mal damit sammeln ...

[Warf]

Ich benutze OpenSuse Tumbleweed. Als rolling releases hat das immer die neuste Version vom fpc im Paketmanager, und Lazarus Bau ich vom source.

Im Grunde ist eine neu installation nur:

Code: Alles auswählen

sudo zypper in -t pattern devel_basis
sudo zypper in fpc git
git clone https://gitlab.com/freepascal.org/lazarus/lazarus.git
cd lazarus
make all

Kein fpcup oder sonst was notwendig

[HobbyProgrammer]

Ich bin mit KUbuntu bis jetzt sehr zufrieden. Anfangs habe ich Lazarus über die DEB Pakete von der Lazaus IDE Homepage installiert. Seit Frühjahr diesen Jahres mittels Fpcupdeluxe.

[photor]

Hallo,

Archlinux hier in Verwendung:

• Archlinux bringt (halbwegs*) aktuelle FPC- und Lazarus-Pakete aus den eigenen mit Repos mit. "Halbwegs" meint, dass die aktuelle stabile Version zu den Repos gehört; es kann sein, dass es etwas dauert (meine Beobachtung: einige Wochen), bis ein neues Release dort auftaucht.
• Für die Pakete aus den Repos werden die nötigen Abhängigkeiten (wie bei jeder guten Distro) automatisch mitgeliefert, wenn sie noch nicht installiert sind.
• fpcUpDeluxe gehört nicht zu den Paketen (und ist auch nicht im AUR).
• Man kann es natürlich trotzdem nutzen, um FPC und Lazarus zu installieren. Dann ist man allerdings selbst für das drum-herum verantwortlich; per-se ist da bestimmt nichts basis-installiert.
• ich selbst habe (vor ca. 1 Jahr) mal die neueste Lazarus/FPC-Version mittels FpcUpDeluxe installiert. Da hatte ich aber vorher schon länger das entsprechende Paket aus den Repos installiert. Das selbst hatte ich zwar vorher entfernt, aber das ganze "Zubehör" nicht. Ich kann daher nicht sagen, dass wie gut FpcUpDeluxe mit einem Basis-Archlinux klar kommt, bzw, wie gut es den User informiert, was noch zusätzlich benötigt wird.

Mein Fazit: ich konnte FpcUpDeluxe auf Archlinux nutzen, um Lazarus/FPC zu installieren; das hat funktioniert. Ich bin im Endeffekt doch wieder zurück zu den Arch-Paketen gewechselt, da ich dann alles aus einer Hand habe und ich solche Feature wie Cross-Compiling oder die letzte Brand-aktuelle Version nicht brauche (darüber gab es damals schon eine Diskussion, die hier und jetzt nicht noch einmal geführt werden muss).

Archlinux ist also weder besonders gut noch irgendwie schlecht für Lazarus geeignet; wenn man FpcUpDeluxe nutzen will, kann man das - so gut, wie in jeder anderen Distribution auch. Archlinux soll man nutzen, weil man von Archlinux überzeugt ist und es nutzen will und nicht weil man FpcUpDeluxe nutzt.

Ciao,
Photor

[Warf]

Eventuell mal eine kleine allgemeinere Einschätzung zur FPC installation über die verschiedenen Methoden:

1. Systempakete
Bei den Systempaketen aus dem Paketmanager hat man den riesen Vorteil das es automatisch up-to-date gehalten wird, sofern man eine Distro hat die Updates ausliefert. Debian und Derivate (Ubuntu, Mint, etc.) sind "Stabile" Linuxdistributionen. "Stabil" ist Linuxsprech für "Seit 5 Jahren outdated", da werden praktisch wenn die Distro version erstellt wird, die Major version der Pakete festgehalten, und nur noch Minor updates werden Ausgespielt. Weder FPC noch Lazarus bekommen minor Updates, von daher bedeutet das, wenn man sich die neuste Debian Distro von diesem Jahr installiert und die für die nächsten 4-6 Jahre nutzt, bleibt man die nächsten 4-6 Jahre auf der gleichen FPC und Lazarus Version. Stable Distros sind toll für Server, aber als Nutzer gibt es nix frustrierenderes als auf 5 Jahre alter Software rumzusitzen, weil man einfach nix neues bekommt.
Rolling release systeme haben dieses Problem nicht. OpenSuse Tumbleweed, Arch/Manjaro, Debian Unstable, etc. bekommen immer sehr Zügig die neuste Version.

Wenn man eine absolut low-effort installation haben will, einfach ein RR Linux wie Tumbleweed nehmen und über Zypper installieren und man ist glücklich.

Ein Problem ist allerdings Lazarus. Da Lazarus nur Kompilezeit Pakete kann, gehört es zum Lazarus Workflow die IDE regelmäßig neu zu Kompilieren. Wenn man jetzt allerdings natürlich Lazarus über die Systempakete installiert, werden die als "root" systemweit installiert. Natürlich möchte man jetzt nicht seine IDE immer als root starten, und auf einem Mehrbenutzersystem würde das auch bedeuten das es nur eine Lazarus konfiguration geben kann, und verschiedene Nutzer nicht verschiedene Packages installieren können.
Um das zu umgehen kompiliert Lazarus eine Nutzerversion ins Nutzerverzeichnis. D.h. wenn man Lazarus systemweit installiert, installiert man es sich praktisch 2 mal, einmal die Basis version und einmal die Nutzerkonfigurierte version, die von der Basisversion abgeleitet ist.
Das funktioniert erstaunlich gut, aber kann trozdem zu Problemen führen. Grade bei Updates kann die Nutzerversion und die Systemversion sich unterscheiden. Besonders schön wirds wenn man selbst was an den Lazarus sources anpasst oder patcht. Das kann dann schnell mal knallen und Probleme verursachen die nahezu unmöglich zu debuggen sind.

Daher ist meine persönliche Philosophie, FPC über Systemquellen gerne, da benutz ich eh immer die letzte stable version, da ich bei Lazarus eh eine lokale Nutzerkopie bekomme, umgehe ich damit die Fehleranfällige Systeminstallation und bau mirs direkt im Nutzerverzeichnis selbst.

2. Installer Pakete
Damit meine ich die .deb Pakete die man sich auf der Website runterladen kann. Die haben die selben Probleme wie die Systempakete oben beschrieben, nur das man sie manuell updaten muss, und die Installation ein Krampf sein kann.

Sind nur für "stable" Systeme wie Debian zu gebrauchen, da die alternative dort eine 5 Jahre veraltete version ist, aber sonst gewinnt man damit keinen Blumentopf.

3. FPCUp
Mit FPCUp habe ich eine gewisse "Hassliebe". FPCUp ist toll um den z.T. recht komplexen Buildprozess von FPC und Lazarus zu automatisieren. Gleichzeitig sind dabei an sehr vielen stellen allerdings Entscheidungen getroffen worden, die das ganze unnötig kompliziert machen. Außerdem ist der einzige Grund warum man FPCUp braucht, das das bauen vom FPC selbst recht kompliziert und wenig Dokumentiert ist.

Um mal ein paar meiner Probleme mit FPCUp darzustellen, beginnen wir mal mit dem offensichtlichen. Eine FPC Systeminstallation sind ~300 MB, die FPC Sources noch mal so 400MB, Lazarus sources + Kompiliert ~600 MB, alles in allem also 1,3 GB. Nicht wenig, aber kleiner wirds nicht ohne tricks.
Mit FPCUp bin ich bei 2 GB, deutlich mehr, die Frage ist also warum?

Der Grund ist recht simpel, FPCUp räumt nicht auf. Buildartifakte oder auch der .git Ordner, braucht man beim FPC ausschließlich wenn man vor hat aktiv am FPC source zu entwickeln, wenn man aber nur vor hat den FPC und die RTL einmal zu bauen und danach zu benutzen. Als jemand der viel auf Linux VMs mit nur 40 GB Speicher arbeitet, ist das einfach nur absolute Verschwendung, ohne irgendeinen Mehrwert.
Ich benutze gerne FPCUp, z.B. für meine Docker Builds, da FPCUp das installieren von Cross Compilern sehr einfach macht. Allerdings musste ich da mein eigenes Cleanup Script bauen, damit die Docker container nicht komplett in der Größe explodieren: https://github.com/Warfley/LPMDocker/bl ... d_funcs.sh

Code: Alles auswählen

function buildCleanup() {
    echo "Cleaning up FPC build"
    cd $INSTALL_PATH
    mv fpc/bin _fpc_bin
    mv fpc/lib/fpc/3.2.2/units/ _fpc_units
    rm -rf fpc
    mkdir fpc
    mv _fpc_bin fpc/bin
    mv _fpc_units fpc/units

    echo "Cleaning up Lazarus build"
    find lazarus -type d -name units -exec rm -rf {} \;
    find lazarus -type d -name lib -exec rm -rf {} \;
    rm -rf lazarus/.git

    echo "Cleaning up Bootstrap FPC"
    rm -rf fpcbootstrap/
}

Dann ist das Nächste Problem, in FPCUp sind die ganzen Versionsnummern und Parameter gehardcoded. D.h. in dder Aktuellen version von FPCUp ist in der fpcup.ini das folgende geschrieben:

Code: Alles auswählen

stable.zip=https://gitlab.com/freepascal.org/fpc/source/-/archive/release_3_2_2/source-release_3_2_2.zip

Und die .ini wird in die Exe als Resource kompiliert.

D.h. wenn eine neue Lazarus oder FPC Version raus kommt, muss man, um den FPCUp zu benutzen, erst mal die neue Version von FPCUp. Ein Updater der manuelle Updates braucht um dann automatische Updates fahren zu können ist auch mal was neues.
Ab dem Punkt ist das konzept "Updater" so ad Absurdum geführt worden, das man auch einfach gleich die Binaries direkt runterladen kann.

Und falls sich jemand Fragen sollte, warum ich mich so sehr darüber beschwere, obwohl es relativ einfach zu fixende Sachen sind, und ich das einfach selbst in FPCUp einbauen könnte: Ich habe es versucht, aber FPCUp ist eine einzige Gigantische Lazarus Code Base, in der so viel gehardcoded ist, das Funktionen von über 1000 Zeilen keine Seltenheit sind (zum Vergleich, im Linux Kernel Source sind Funktionen typischerweise nicht mehr als 50 Zeilen) und als Außenstehender mal eben sich in den Source einzuarbeiten absolut grausig ist.
Nicht zu vergessen das es den Source nicht einmal sondern zweimal gibt, denn während FPCUp ein Konsolenprogramm ist, was über Parameter gesteuert wird, ist FPCUpDeluxe, nicht einfach ein simples GUI was FPCUp mit den korrekten Parametern Aufruft, sondern ist ein komplett eigenständiges Projekt mit eigener CodeBase die regelmäßig mit FPCUp synchronisiert werden muss.

Wie gesagt ich nutze FPCUp selbst, grade wenn man mehrere FPC und Lazarus Installationen mit Cross Compilern managen will ist es super.
Aber man darf nicht vergessen, alles was FPCUp macht ist im Grunde nur ein paar Kommandozeilenbefehle auszuführen. Und wenn man lediglich die aktuelle Stable FPC version und eine Aktuelle Lazarus installation braucht, ist mir das folgende:

Code: Alles auswählen

sudo zypper in fpc
git clone --branch lazarus_2_2_6 https://gitlab.com/freepascal.org/lazarus/lazarus.git
cd lazarus
make all

deutlich einfacher.

Und der einzige Grund warum das bauen von FPC sowie entsprechende Cross Compiler so kompliziert ist, ist ausschließlich das ich bis heute noch keine vernünftige Dokumentation zu den Make Targets und Parametern gibt.
Beispiel aus der Wiki Seite von Cross Compiling nach Raspi:

Code: Alles auswählen

apt install binutils-arm-linux-gnueabihf
ln -s /usr/bin/arm-linux-gnueabihf-ld /usr/bin/arm-linux-ld
ln -s /usr/bin/arm-linux-gnueabihf-as /usr/bin/arm-linux-as
ln -s /usr/bin/arm-linux-gnueabihf-objcopy /usr/bin/arm-linux-objcopy
ln -s /usr/bin/arm-linux-gnueabihf-strip /usr/bin/arm-linux-strip

sowie danach ein kurzes shell script:

Code: Alles auswählen

 export FPCVER="3.2.2"
 cd /usr/share/fpcsrc/"$FPCVER"/

 make clean all FPMAKEOPT="-T 4" CPU_TARGET=arm OPT="-dFPC_ARMHF" CROSSOPT="-CpARMV6 -CaEABIHF" CROSSBINDIR=/usr/arm-linux-gnueabihf/bin

 make crossinstall OS_TARGET=linux CPU_TARGET=arm OPT="-dFPC_ARMHF" CROSSBINDIR=/usr/arm-linux-gnueabihf/bin   CROSSOPT="-CpARMV6 -CaEABIHF" INSTALL_PREFIX=/usr

 ln -sf /usr/lib/fpc/"$FPCVER"/ppcrossarm /usr/bin/ppcrossarm

Ohne irgendwelche Erklärungen. Wie soll man denn bitte lernen FPC selbst zu Installieren wenn es nirgends eine Erklärung gibt was man warum macht? Kein wunder das man zu FPCUp greift.

FPCUp ist keine gute Lösung. Es ist im Grunde einfach nur eine ganze Menge "Wissen" was in Pascal code gehardcoded wurde, anstatt es in form von verständlicher Dokumentation jedem bereitzustellen.

FPCUp ist keine gute Lösung, aber es ist manchmal die einzige Lösung. Und da in FPCUp alles gehardcoded ist, sollte man sehr stark hoffen das das Projekt mit jeder neuen FPC und Lazarus Version weiter entwickelt wird. Sonst, sobald die Entwicklung pausiert wird, selbst wenn sich am FPC buildsystem nix ändert, geht gar nix mehr

[Mathias]

FPCUp ist keine gute Lösung, aber es ist manchmal die einzige Lösung. Und da in FPCUp alles gehardcoded ist, sollte man sehr stark hoffen das das Projekt mit jeder neuen FPC und Lazarus Version weiter entwickelt wird. Sonst, sobald die Entwicklung pausiert wird, selbst wenn sich am FPC buildsystem nix ändert, geht gar nix mehr

An sowas habe ich auch schon gedacht, was passiert, wen Don Alfredo fpcupdeluxe nicht mehr weiter entwickelt ?
Dann ist fertig lustig mit Cross-Compilern.

Die ganze make Geschichte ist nur das einte Problem.
Was noch schlimmer ist, für Cross-Compiling, werden noch viele externe Tools und libs benötigt. ZB. das Zeugs, welches man unter (deluxe_laz)/cross findet.

[Warf]

Die ganze make Geschichte ist nur das einte Problem.
Was noch schlimmer ist, für Cross-Compiling, werden noch viele externe Tools und libs benötigt. ZB. das Zeugs, welches man unter (deluxe_laz)/cross findet.

Ja das faszinierende dabei ist, die werden ja auch einfach nur runtergeladen, d.h. es gibt irgendwo im FPCUp source eine Liste mit den verschiedenen Targets, Parametern und Downloadlinks. Wenn man diese Liste einfach ins Wiki packen würde, könnte man die sich einfach selbst runterladen und müsste nicht drauf hoffen das FPCUp verfügbar ist.

Im Grunde ist das ja auch alles keine Hexerei, man muss einfach nur die tools und Bibliotheken runterladen und dann beim Kompilieren die Pfade entsprechend über Parameter übergeben. Das sollte man eigentlich selbst mit mittelmäßiger Linux Kommandozeilenerfahrung auch selbst hinbekommen

[fliegermichl]

Im Grunde ist das ja auch alles keine Hexerei, man muss einfach nur die tools und Bibliotheken runterladen und dann beim Kompilieren die Pfade entsprechend über Parameter übergeben. Das sollte man eigentlich selbst mit mittelmäßiger Linux Kommandozeilenerfahrung auch selbst hinbekommen

Ja klar, aber wenn es keiner macht, dann passiert es nicht.

[af0815]

Alfred hat in das Projekt sehr, sehr viel Wissen hinein gepackt. Ich habe das über die Jahre verfolgt, seit er das Projekt weitergebracht hat. Vor allen die Zusammemstellungen von den Paketen die nebenbei noch benötigt werden ist ja mehr als bewundernswert.

Aber genau deswegen weil man von den Coreentwicklern maximal ein RTFM bekommt und gerade die Cross-Sachen zwar einfach sind, aber normalerweise an den kleinen Details immer scheitern, ist Alfred grosser Respekt zu zollen. Weil er hat sich hingesetzt und diese ganzen kleinen Gemeinheiten angefangen durch fpcup und später fpcupdeluxe zu umschiffen. Und auch einiges an Bugs im way of working für eine saubere Compilerinstallation gefunden. Nicht umsonst sind da einige interessante Einstellungen im Setup+ vorhanden.
Und wenn wer Verbesserungen vorzuschlagen hat, Alfred hat sich - meiner Erfahrung nach - nie guten Ideen verschlossen. Einfach auf der GIT Seite das Einreichen. Da ist auch der komplette Source

[Mathias]

Einfach auf der GIT Seite das Einreichen. Da ist auch der komplette Source

An das habe ich gar nicht gedacht.
Ich habe dies bis jetzt immer im englischen Forum getan.
Aber ein Issues wär schon besser. Für jede Frage die da kommt gibt es Trophäen und dies macht das Programm bekannter.