Wenn man ein Open-Source-Projekt schreibt und Google Code oder GitHub verwendet und eine Bibliothek wie Lua verwenden möchte, wie soll man das tun?
Da die Bibliothek vor dem Kompilieren nicht installiert werden muss.
Antworten:
Ich würde wärmstens empfehlen, die Dokumentation von Git zu Submodulen durchzulesen . Es behebt genau dieses Problem, vorausgesetzt, dass alle Ihre Quellen Git verwenden. Wenn dies nicht der Fall ist, können Sie zum Zwecke der Integration immer ein Git-Repo einrichten. Der Aufwand ist trivial und die Auszahlung ist signifikant.
Soll die Abhängigkeit in das Repository aufgenommen werden?
Ich denke, Abhängigkeiten sollten immer in das Repository aufgenommen werden, solange das Einbeziehen von Abhängigkeiten nicht gegen Nutzungsbedingungen verstößt. Wenige Dinge sind ärgerlicher, als die richtigen Versionen der richtigen Abhängigkeiten manuell zu finden, bevor Sie einen Build erstellen können. Sicher, dies ist einfach, wenn Sie über automatisierte Tools verfügen, mit denen Sie die richtige Abhängigkeit finden und herunterladen können. Was ist jedoch, wenn Sie zur Zeit nicht mit dem Web verbunden sind oder der Server ausfällt oder das Projekt der Abhängigkeit wurde komplett eingestellt und offline geschaltet? Beziehen Sie, wenn möglich, immer die Abhängigkeiten ein.
Soll die Abhängigkeit aus demselben Erstellungsskript wie der Rest des Projekts oder aus einem separaten Erstellungsskript erstellt werden?
Verwenden Sie vorkompilierte Versionen, es sei denn, es gibt einen guten Grund, aus dem Quellcode zu kompilieren.
Und warum nicht Optionen im Build-Skript bereitstellen? Ein einfacher Schalter, um auszuwählen, ob die Abhängigkeiten auch kompiliert werden sollen oder nicht. Wenn der Benutzer auch die Abhängigkeiten kompilieren möchte, rufen Sie einfach seine eigenen Erstellungsskripte aus dem Erstellungsskript Ihres Produkts auf. Auf diese Weise kann der Benutzer die Erstellungsskripte der Abhängigkeiten manuell aufrufen oder einen vollständigen Build von allem erstellen. Aber ich würde die Abhängigkeiten nur als Binärdateien liefern, wenn es keinen guten Grund gibt, sie aus den Quellen zu kompilieren. Ich denke, in der Open Source-Welt erfordern einige Lizenzen, dass Sie die Quellen zusammen mit Ihrem Produkt vertreiben, aber das bedeutet nicht, dass Sie sie nicht vorkompilieren können.
Kurz gesagt: Stellen Sie, wenn möglich, ein vollständiges, eigenständiges Arbeitspaket bereit. Dies bietet Ihren Benutzern den größtmöglichen Komfort.
Dies kann auf Ihren Anwendungsfall zutreffen oder auch nicht. Bei unserer Arbeit legen wir jedoch in jedem Zweig einen Ordner "Referenzen" an. Hier platzieren wir DLLs von Drittanbietern. Dies verursacht eine Menge Duplikate von relativ unveränderlichen Binärdateien in der Quellcodeverwaltung, aber der Speicher ist billig und zu jedem Zeitpunkt weist jeder Zweig und jedes Tag genau die Abhängigkeiten (und Versionen!) Auf, die er erwartet.
Wir kompilieren die Abhängigkeiten selbst und verschieben die kompilierten Binärdateien in diesen Ordner. Auch unsere hauseigene Shared Library wird so behandelt. Auf diese Weise funktioniert die gleiche Technik für vorkompilierte proprietäre Bibliotheken, Open Source-Bibliotheken und interne Bibliotheken.
Wenn Sie Ihre Frage jetzt beantworten, nachdem ich sie noch einmal gelesen habe, tun Sie dasselbe und erwähnen Sie nur, dass Ihr Projekt eine vorkompilierte 1.3.5-Version von Lua verwendet.
Soll die Abhängigkeit in das Repository aufgenommen werden?
Es kann im Repository referenziert werden (mit jeder für SCM verwendbaren Methode), wenn diese Abhängigkeit integraler Bestandteil des Produkts ist (Quellabhängigkeit), nicht die Binärabhängigkeit, die separat aufgelöst werden kann
Soll die Abhängigkeit aus demselben Erstellungsskript wie der Rest des Projekts oder aus einem separaten Erstellungsskript erstellt werden?
Egal. Sie können jede Methode Ihren Anforderungen entsprechend bevorzugen (Geschwindigkeit / Transparenz / Verwaltbarkeit / usw.)
Als Eclipse-Shop haben wir gerade damit begonnen, Buckminster für die Verwaltung unseres Erstellungs-, Zusammenstellungs- und Bereitstellungsprozesses zu verwenden.
Unsere erste Phase bestand darin, alle vorhandenen abhängigen Bibliotheken zu extrahieren und Buckminster für das Materialisieren der richtigen zu sorgen. Dies ermöglicht eine viel schnellere und kleinere Bereitstellung.
Der nächste Schritt besteht darin, unser monolithisches svnRepository auf eine Reihe modularer gitRepositorys zu verschieben.
Ich weiß nicht, wie gut Buckminster sich in gitSubmodule (oder quecksilberhaltige Subrepos) integrieren lässt, aber es ist schön, dass Buckminster in Bezug auf das für eine bestimmte Komponente verwendete VCS agnostisch ist.