spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hi,

Ich stecke gerade in einem Dilemma und zwar zum Thema syncsys. Aktuell ist es so, dass enet einen expliziten include-Pfad bedarf. Die Pfade für zlib sind aber angepasst. Entweder ich passe die Pfade von ENet an und erzwinge so die Nutzung der mitgelieferten Version von zlib und enet oder ich führe die Pfade von zlib auf die Standardwerte zurück.
Ersteres wäre für windows Nutzer und Nutzer von den lokalen Versionen angenehmer, allerdings besteht die Gefahr, dass linux und mac Nutzer ausversehen die zlib header von der lokalen Version nutzen, aber gegen eine global installierte Version linken, da ich unter linux/mac nicht festlegen kann, dass er nur gegen die mitgelieferte Version linkt.
Die andere Alternative ist, dass ich nur auf den enet bzw. zlib header verweise, aber die Pfade angeben lassen. Somit ist das Includieren/Linken auf Linuxsystem einfach, wenn die libs installiert sind. Allerdings könnten dann für jedes OS andere lib Versionen genutzt werden mit der Gefahr von Inkompatibilitäten. Außerdem müssten dann Windowsnutzer dann immer explizit die Includepfade der mitgelieferten Libs angeben.
Die dritte Alternative ist, dass ich zlib und enet als integralen Bestandteil von syncsys auffasse und es komplett integiere. Allerdings könnte im leichtesten Fall bei der Nutzung von Zlib durch andere Libs doppelter Bincode entstehen und im schlimmsten Fall doppelte Definitionen (bin ich mir nicht so ganz sicher).

EDIT: Es wäre natürlich hilfreich, wenn ich auch eine entsprechende Frage formuliere, auch wenn der Sinn eigentlich schon oben drinne steht;
Welche Variante würdet ihr als Benutzer, sprich Entwickler, vorziehen? Welchen Ansatz empfindet ihre als den "nativsten"?

Naja, da ich ja für die Windowsnutzer sowieso die Libs mitliefere und regelmäßig update, sollte das weniger kritisch sein. Ich persönlich mag es halt nicht, wenn man als Entwickler gesagt bekommt "ja du brauchst noch a,b,c. Dafür musst du noch x,y,z installieren/kompilieren".
Bisher habe ich so halt auch sicher gestellt, dass die genutzten Versionen von enet und zlib immer gleich sind für alle OS. Im Prinzip ermöglicht auch nur Variante 2 die Nutzung einer externen Version, wenn ich mal genauer drüber nachdenke, weil die Pfade ja auf die entsprechend lokale Version umgebogen sind. Ich könnte höchstens durch ein MACRO bei Version 1 erreichen, dass sowohl als auch funktioniert.
Gäbe es einen Weg in eine statische Bib auf andere statische Bibs zu verweisen, wäre die erste Version kein Thema, weil der Nutzer sich nie fragen müsste woher er noch die symbole für zlib und enet hernehmen soll.