Gibt es einen Best Practices-Leitfaden zum Verteilen nativer C-Bibliotheken für Windows?
Kennt jemand einen Best Practices-Leitfaden für die Bereitstellung nativer (kein COM, kein .NET) gemeinsam genutzter ANSI C-Windows-Bibliotheken?
Unser Produkt verwendet zlib und wir vertreiben vorgefertigte Binärdateien auf unserer Downloadseite, die sich von denen auf der offiziellen zlib-Seite unterscheiden. Ich vermute, dass der Grund dafür istum zu vermeiden, C-Laufzeiten zu mischen. Die offiziellen Versionen wurden mit VC ++ 6.0 gegen msvcrt erstellt, und VS.NET/2005/2008 wird msvcrt71 / 80/90 verwenden.
Was ich tun möchte, ist, VS2005 / 8-Lösungen und -Projekte zu erstellen, die die ZLIB ordnungsgemäß für uns erstellen und sie anstelle unserer derzeitigen verteilen. Ich möchte dies sorgfältig tun und ein richtig nützliches Paket verteilen, das ich dann auch an die Kuratoren von zlib zur Aufnahme in deren Quelldistribution senden könnte. Es hat sich jedoch als schwierig erwiesen, zuverlässige Informationen zu finden. Ich habe eine Reihe von Büchern über die Win32-Programmierung und ich habe viele Artikel im Web gefunden, aber nichts davon scheint eine gründliche Beschreibung dessen zu leisten, was Sie tunJa wirklich verteilen müssen.
Beispielsweise verteilt zlib die Dateien .exp, .lib stub und .def, wobei fftw die Dateien .def verteilt, nicht jedoch die Dateien .lib stubs und .exp. Ich denke, ich könnte einfach alles ablegen, was dort nützlich aussieht (oder nur spiegeln, was die offizielle zlib derzeit hat), aber ich würde gerne wissenWarum es muss da sein und in welche Verzeichnisse es gehört.
Gibt es gute Beispiele für gut gewartete Windows-Distributionen von Bibliotheken, die aus der Unix-Welt stammen?
Offizielle zlib-Binärdistributionen (nach unten scrollen)
ZU KLÄREN:
Wir verteilen eine Bibliothek und stellen die zlib (meistens) Windows-Benutzern zur Verfügung, da diese sie normalerweise nicht zur Verfügung haben. Ich möchte, dass unser Build der ZLIB im Allgemeinen als Komponente und nicht nur als DLL-Datei, die unser Produkt verwendet, nützlich ist. Wir sind Open Source und weit verbreitet, daher möchten wir unsere gesamte Build-Umgebung verfügbar machen und einfach an jeden Compiler anpassen, den Sie verwenden möchten.