Könnte Free Pascal von etwas wie Apache Maven profitieren?

Freepascal hat an einem eigenen Paketsystem gearbeitet, das zwischen apt-get und freebsd ports style geht. (Download Quelle / Build / Installation automatisch), genannt fppkg. Aber die Arbeit ist ins Stocken geraten. Menschen, die Zeit investieren, sind der Engpass, nicht Menschen, die Werkzeuge wählen wollen.

Soweit Maven geht, mag ich keine Hilfswerkzeuge, die eine Installation von großen externen Laufzeiten benötigen. Es könnte für eine große App (wie Open Office) in Ordnung sein, aber nicht für ein Util.

Ich bevorzuge auch ein Werkzeug, das auf die Realität und den Workflow der FPC abgestimmt ist. Dokumentationstools, Build-Tools, Download-Systeme, Testsuite-Systeme sind bereits vorhanden, es braucht nur eine Person, die viel Zeit dafür aufwendet, um dies zu ermöglichen.

Einige typische Probleme bei der Einführung einer neuen Technologie in einem Projekt als FPC, und warum es eine Tendenz hat, seine eigenen Werkzeuge zu machen:

• muss 20+ Committer in Teilzeit trainieren.
• Die einzige allgemeine Programmiersprache, die Sie annehmen können, ist Free Pascal. Sogar Delphis innere Abläufe können nicht als selbstverständlich angesehen werden (viele Committer kamen direkt zu FPC oder sogar noch über TP oder einen Mac Pascal)
  • Offensichtlich nervt das etwas mit Plugins in einer anderen Sprache.
• Bash-Skript ist eine nahe Sekunde. (g) mach dritt, aber schon eine Größenordnung weniger.
• Alle Server sind * nix-ähnlich (FreeBSD, OS X, Linux), aber nicht alle laufen Apache. (z. B. mein FreeBSD-Spiegel läuft XSHTTPD)
• Jemand, der am besten informiert ist, muss für lange Zeit ein dedizierter Betreuer sein. Beheben Sie Probleme, aktualisieren Sie Migrationen usw., vorzugsweise mehr als eins aus offensichtlichen Gründen.
• Ein großer Nachteil sind Linux-Distributionen (und in geringerem Maße FreeBSD), die meisten Maintainer von * nix-Paketen können nicht mehr als "./configure; make; make install" und müssen mit einem nahebaubaren Repository gespoolt werden und Hilfsdateien.
  • Die In-Distribution-Verpackung von FPC / Lazarus war schon immer wichtig und nimmt weiter zu
  • Alle Distributionen haben ihre eigenen speziellen Regeln bezüglich Metadaten, Dependenzen und wie Quellen veröffentlicht werden müssen. Besonders Debian / Ubuntu ist sehr bürokratisch und langsam.
  • Die meisten mögen keine automatischen Installationsprogramme von Drittanbietern auf ihren Systemen (da dies ihre Abhängigkeitskontrolle umgeht)

Dies alles führt zu der effektiven Praxis, dass eigene Tools in Pascal mit minimalem Scripting am besten funktionieren. Einige Werkzeuge verwendet:

• Gmake wird hauptsächlich verwendet, um den Build-Prozess auf einer Verzeichnisebene zu parametrisieren, ein Nachfolger, fpcmake (nicht wirklich ein Make-Derivat trotz des Namens) hat begonnen, aber die Migration ist nicht abgeschlossen.
• Latex und eine Konvertierung von Latex in HTML (tex4ht, aber Debian verwendet hevea) werden im Dokumentationsgebäude (der Nichtbibliotheksdokumentation) verwendet
• Die Community-Site (Netscape-Community-Server, der TCL-Scripting verwendet, ein schwerer komplexer Anwendungsserver) war seit dem Start ein Problem, aber besonders in letzter Zeit, seit der Betreuer weniger aktiv wurde.
• Mantis war ein Problem (besonders das E-Mail-Modul würde den Server aufgrund des Volumes zum Absturz bringen oder lahm legen), aber es wurde während sukzessiver Updates und der harten Arbeit von mehreren Lazarus-Entwicklern in Form gebracht. Zur Zeit ist es ein ordentliches Arbeitspferd.
• lazarus.freepascal.org PHPBB Forum OTOH ist relativ schmerzlos, da viele jüngere Leute damit umgehen können.
• Gleiches gilt für Subversionen (obwohl die fortgeschrittenere Skala einige Anpassungen erfordert, ist nicht jeder tief in die In- und Outs von mergetracking involviert)

Wenn jemand Maven wirklich ernst nimmt, frage ich ihn normalerweise:

• to KRITISCH untersuchen die Verwendung für das Projekt. Auf sehr konkrete Weise, mit Zeitplan und Zeitschätzungen. Vogelperspektive "alles ist möglich" Übersichten sind im Wesentlichen wertlos.
• Überlegen Sie sich etwas über den zukünftigen Wandel der verwendeten Technologien. In 18 Jahren + Projekten wird schließlich jede Technologie ersetzt, sogar die Inhouse-Technologie. Eine neue Technologie darf die Migration anderer Infrastrukturkomponenten nicht erschweren oder behindern. Die neue Technologie zur Beendigung aller neuen Technologien existiert nicht.
• Erstellen Sie einen Migrationsplan. Migration wird oft unterschätzt und unterschätzt.
• Und am Ende gibt es immer die 1000000 Euro Frage, wer wird die tägliche Wartung machen?

Beachten Sie, dass Sie in einer Firma nur die für den Anwendungsserver verantwortliche Person kicken. Aber in einer informellen Umgebung ist dies viel schwieriger, besonders langfristig, da das Leben, die Beschäftigung und die Zeit, die der Mensch für das Projekt benötigt, variieren.

Klingt nach einem interessanten Plan, aber die Delphi-Gemeinschaft (und FPC, mehr noch, ich könnte es mir vorstellen!) schätzt Bibliotheken als Quelle weit mehr als vorkompilierte Bibliotheken. Der allgemeine Konsens ist, dass jeder, der eine Binary-Only-Bibliothek verwendet, aus zwei Gründen ein Dummkopf ist: Sie können keine Fehler beheben, die darin enthalten sind, und Änderungen am Compiler beeinträchtigen die Kompatibilität.