[C++] Fragen zu Import Libs

[ponx]

hallo Leute,
ich arbeite an ein einer Musik-Middleware, die ich als DLL plus dazugehöriger Import Lib anbiete. Die Middleware gibts in mehreren Versionen, die sich in der jeweils verwendeten Audio-Schicht unterscheiden. Dann existieren nochmal jeweils eigene Configurations für die (interne) Debug und öffentliche Release-Version, plus eine Release-Version mit aktiviertem Logging. Also mittlerweile gibts eine stattliche Anzahl an Configurations, die mir alle eine eigene Import Lib raushauen.
Jetzt die Frage: Ich hab festgestellt, dass die Import-Libs sich binär unterscheiden, obwohl sie alle die gleiche API bedienen. Gesetzt den Fall, dass alle meine Configurations eine DLL mit dem gleichen Namen ausspucken, ist es dann egal, welche der Import Libs ich verwende ? Oder macht so eine Import-Lib intern noch mehr, und ich kann mir da irgendwie ins Knie schießen?

Danke schonmal und viele Grüße,
ponx

[jumphigh]

Gesetzt den Fall, dass alle meine Configurations eine DLL mit dem gleichen Namen ausspucken, ist es dann egal, welche der Import Libs ich verwende ? Oder macht so eine Import-Lib intern noch mehr, und ich kann mir da irgendwie ins Knie schießen?

Bei reinem C-API mag die Gefahr nicht groß sein, da kann man i.d.R. die Release- mit der Debug-DLL unmerklich für den Client vertauschen. Bei C++ mit Name-Mangeling würde ich mich nicht mehr darauf verlassen, dass die verschiedenen Versionen einer Funktion alle den gleichen Namen haben bzw. noch wichtiger, übergeben Objektinstanzen gleich gebaut werden. Falls falsche Bindings hereinkommen, wirst du die selbst mit dem Debugger nur schwer finden. Schließlich geht man davon aus, dass Compiler und Linker ihre Arbeit richtig machen und sucht den Fehler bei sich.

Ich halte deinen Ansatz schon für falsch. Du hast mehrere Konfigurationen, diese sollten meiner Meinung nach auch verschieden benannte DLLs inkl. Importlib auswerfen. Über die Header (#pragma comment) solltest du dann die Versionen automatisch einbinden lassen.

MfG
Andreas

[ponx]

hallo jumphigh,
danke für deine Antwort. Wegen verschiedener Benamsung: Ich geb dir bei Debug- und Release-Versionen bzw logging Recht, dass eine unterschiedliche Benamsung besser wäre, aber für die verschiedenen Versionen mit jeweils anderer Audio-Wiedergabeschicht hätte ich mir die Option gerne noch offen gelassen. Es kann z.B. sein, dass ich nach Release feststelle, dass es mit einer Audioschicht Probleme gibt. Dann wär's schön, die Version meiner Middleware einfach auszutauschen, ohne dass neu kompiliert werden muss.
Dass man über #pragma comment auch libs einbinden kann, hab ich nicht gewusst, danke. Bis jetzt mach ich das immer in den Properties über die verschiedenen Configurations.

[dot]

Dass man über #pragma comment auch libs einbinden kann, hab ich nicht gewusst, danke. Bis jetzt mach ich das immer in den Properties über die verschiedenen Configurations.

Und mach das auch bitte weiterhin so, denn das ist die ordentliche Lösung. #pragma comment ist imo eine furchtbare Unsitte. Sowas ist Aufgabe des Buildsystems und gehört auf keinen Fall in den Code.

[jumphigh]

Transparent Austauschen kannst du nur, wenn Binärkompatibilität gegeben ist, z.B. bei einer POD-C-DLL oder COM. C++ selbst ist nur auf Quellcodeebene "transportabel" und eine übersetzte Lib von Toolset A wird eher nicht mit einem von Toolset B übersetzten Programm zusammenpassen. Es gibt viele Bereiche bei der Struct/Class-Definition, wo man in Probleme rennen kann: Unterschiedliche Instanz-Größen durch Alignment oder unterschiedliche Memberimplementierung, nicht standardisiertes Namemangeling oder der Klassiker modulübergreifendes dynamisches Speichermanagement.

Für ein sicheres dynamisches Plugin-System bleibt dann immer nur C-DLL oder COM. Dazu gibt es viele Threads auch hier im Forum.

MfG
Andreas

[jumphigh]

Und mach das auch bitte weiterhin so, denn das ist die ordentliche Lösung. #pragma comment ist imo eine furchtbare Unsitte. Sowas ist Aufgabe des Buildsystems und gehört auf keinen Fall in den Code.

Nein, selbst Boost verwendet das. Oder musstest du da schon mal mehr als die Header einbinden?

Es ist für die Kunden der Bibliothek viel einfacher, in ihrem Code einfach ein

Code: Alles auswählen

#define MYLIB_VERSIONX_CONFIGY
#include <MyLib.h>

zu machen, als zu fordern, dass sie herausfinden, welches nun der richtige Bibliotheksname für den Linker ist. Das soll doch bitte schön der Lib-Hersteller tun. Das Buildsystem spielt eher keine Rolle dabei, wenn nur Header und Lib-Dateien ausgeliefert werden.

MfG
Andreas

[eXile]

Es ist für die Kunden der Bibliothek viel einfacher

Nein, ist es nicht. Ich bin selber „Kunde“ einiger quelloffener Bibliotheken (sofern man da überhaupt von Kunde sprechen kann), und ich kriege immer wieder krampfhafte Wutanfälle wenn solcher Code vor meiner Nase landet. Die Gründe habe ich bereits hier einmal aufgeschrieben.

Außerdem ist ein „selbst Boost verwendet das“ kein plausibler Grund. Zu lange ist es in der C++-Entwicklung so gewesen, dass die Anfänger irgendwelchen Pseudo-Gurus nachgelaufen sind, welche Code schrieben, der nicht auf RAII setzt, keine Exception-Safety besitzt, keine Templates aber dafür #defines benutzt, merkwürdige Variablenprefixe statt Namespaces benutzt, ohne besseren Grund die STL verabscheut und stattdessen ungeeignete Privatlösungen benutzt. Dagegen gibt es nur ein Mittel: Sich selbst die Gründe vergegenwärtigen, warum ein bestimmtes Sprachkonstrukt für ein Problem gut oder schlecht geeignet ist. Ohne plausiblen Grund kommt man evolutionär nicht weiter. Ein lakonisches „aber Super-Guru xy verwendet das“ reitet einen voll in die Scheiße.

Von GoingNative 2012 - Day 1 Keynote - Bjarne Stroustrup: C++11 Style:

It is just not a good idea.
[…]
The amateurs do much worse.
And the students aim for this level of code.
They feel great when they write this code.
They are convided that they write efficient, good code.

It's cool.

Well, they think it's cool, and their idols did it.
Maybe their idols did it back when there was nothing else you could do.
But still, this is the kind of code that bright students aim to write.

This is sad.

Das was ich eben in Bezug auf „Gurus“ gesagt habe, gilt natürlich auch für Stroustrup. Ich stimme ihm nicht zu, weil er ein „Guru“ ist. Ich stimme der Implementierungsweise einer Library nicht zu, weil sie eine „Guru-Library“ ist. Sondern ich stimme zu, wenn Gründe, die überzeugen können, geliefert werden. Die sehe ich bei Herrn Stroustrup in der Präsentation. Die sehe ich nicht bei #pragma comment(lib, …). ;)

[dot]

Ich muss zugeben: Mir war neu dass boost das verwendet. Ändert aber auch nix dran dass sowas imo im Code nichts verloren hat.

[kimmi]

Jeder, der schon mal Boost mit einer STLPort-Variante benötigt hat, weil einem die pragma-Direktiven diesen Ärger eingebracht haben ( sprich ich :) ), kann den Vorredndern einfach nur nickend zustimmen.

Gruß Kimmi

[Artificial Mind]

Jeder, der schon mal Boost mit einer STLPort-Variante benötigt hat, weil einem die pragma-Direktiven diesen Ärger eingebracht haben ( sprich ich :) ), kann den Vorredndern einfach nur nickend zustimmen.

Ich habe letzte Woche sogar noch den Spaß gehabt, zusätzlich zu Boost mit STLPort, das Ganze als C++/CLR zu kompilieren.

[BeRsErKeR]

Mal abgesehen davon, dass #pragma comment(lib, ...) nicht standardkonform ist (bzw. nicht von allen Compilern ausgewertet wird) und z.B. im g++ keine Wirkung hat.

[jumphigh]

Ich kann den Argumenten nicht ganz folgen. Im Besonderen kann ich beim besten Willen nicht erkennen, wie das Buildsystem bei einer 3rd-Party-Lib erkennen soll, welche Libdatei nun auf die aktuelle Client-Programm-Konfiguration passt. Wie schon richtig erwähnt, gibt es u.U. sehr viele Versionen einer Lib, die *irgendwie* in den Dateinamen kodiert sind. Sieht man am besten beim Übersetzen von Boost. Ich halte es daher für gefährlich, dem Bibliotheksnutzer das Herausfinden der richtigen Lib-Version aufzubürden, zumal es eben auch automatisch geht. Hier mal mein eigener Code, der zeigt wie kompliziert das sein kann. Wie soll das die Buildengine leisten, ohne sie umständlich mit Daten füttern zu müssen?

Code: Alles auswählen

#pragma once
#ifndef WINLIB_LIBVERSION_H
#define WINLIB_LIBVERSION_H

#define WINLIB_VSTRING2(s)	#s
#define WINLIB_VSTRING(s)	WINLIB_VSTRING2(s)

#include <WinLib_Version.h>

#if (defined _M_IX86) 
	#define VERSION_PLATFORM "x86"
#elif (defined _M_X64)
	#define VERSION_PLATFORM "amd64"
#else
	#error Platform not supported!
#endif

#if (defined UNICODE) || (defined _UNICODE)
	#define VERSION_ENCODING "Unicode"
#elif (defined _MBCS)
	#define VERSION_ENCODING "MBCS"
#else
	#define VERSION_ENCODING "Unknown"
#endif

#if _MSC_VER == 1400
	#define VERSION_TOOLSET "vc80"
#elif _MSC_VER == 1500
	#define VERSION_TOOLSET "vc90"
#elif _MSC_VER == 1600
	#define VERSION_TOOLSET "vc100"
#else
	#error Unsupported toolset!
#endif

#ifdef _DEBUG
	#ifdef _DLL
		#define VERSION_CONFIGURATION "MDd"
	#else
		#define VERSION_CONFIGURATION "MTd"
	#endif
#else
	#ifdef _DLL
		#define VERSION_CONFIGURATION "MD"
	#else
		#define VERSION_CONFIGURATION "MT"
	#endif
#endif

#define WINLIB_VERSION_STRING WINLIB_VSTRING(VERSION_MAJOR) "." WINLIB_VSTRING(VERSION_MINOR) "." WINLIB_VSTRING(VERSION_MAINTENANCE) "." WINLIB_VSTRING(VERSION_BUILD)
#define WINLIB_LIBRARY_STRING VERSION_NAME "-" WINLIB_VERSION_STRING "-" VERSION_PLATFORM "-" VERSION_TOOLSET "-" VERSION_CONFIGURATION ".lib"

#ifndef WINLIB_MANUAL_LIB_OVERRIDE
	#pragma comment(lib,WINLIB_LIBRARY_STRING)
#endif

namespace HaH
{
	namespace WinLib
	{
		static const char* Version_Name			=VERSION_NAME;
		
		const unsigned int Version_Major		=VERSION_MAJOR;
		const unsigned int Version_Minor		=VERSION_MINOR;
		const unsigned int Version_Maintenance	=VERSION_MAINTENANCE;
		const unsigned int Version_Build		=VERSION_BUILD;
		static const char* Version_String		=WINLIB_VERSION_STRING;
		
		static const char* Version_Platform		=VERSION_PLATFORM;
		static const char* Version_Encoding		=VERSION_ENCODING;
		static const char* Version_Toolset		=VERSION_TOOLSET;
		static const char* Version_Configuration=VERSION_CONFIGURATION;
		static const char* Version_Library		=WINLIB_LIBRARY_STRING;
	}
}

#undef WINLIB_VERSION_STRING
#undef WINLIB_LIBRARY_STRING

#undef VERSION_NAME
#undef VERSION_MAJOR
#undef VERSION_MINOR
#undef VERSION_MAINTENANCE
#undef VERSION_BUILD
#undef VERSION_PLATFORM
#undef VERSION_ENCODING
#undef VERSION_TOOLSET
#undef VERSION_CONFIGURATION

#undef WINLIB_VSTRING
#undef WINLIB_VSTRING2

#endif

Damit wird dann automatisch die richtige Bibliotheksdatei eingebunden, die einen komischen Namen wie
WinLib-0.2.0.0-amd64-vc100-MD.lib
WinLib-0.2.0.0-amd64-vc100-MDd.lib
WinLib-0.2.0.0-amd64-vc100-MT.lib
WinLib-0.2.0.0-amd64-vc100-MTd.lib
WinLib-0.2.0.0-x86-vc100-MD.lib
WinLib-0.2.0.0-x86-vc100-MDd.lib
WinLib-0.2.0.0-x86-vc100-MT.lib
haben kann.

MfG
Andreas

[kimmi]

Wenn du allerdings einen STLPort installiert hast, aber Boost ohne STLPort verwenden willst, dann wird das spassig. Irgendwo baut er sich den Namen zusammen, was man halt erst einmal nachvollziehen muss. Nicht jede implizite Annahme über das Zielsystem ist richtig :).

Gruß Kimmi

[jumphigh]

Richtig, und für die 5% Ausnahmen habe ich auch vorgesorgt:

Code: Alles auswählen

#ifndef WINLIB_MANUAL_LIB_OVERRIDE
#pragma comment(lib,WINLIB_LIBRARY_STRING)
#endif

Wenn ich mir den Abschnitt aus boost/config/auto_link.hpp ansehe, scheint es da keine solche Option zu geben. Allerdings fällt auch auf, dass speziell STLPort massive Checks benötigt. Es schient also, dass du mit deinen Problemen eher zu den 5% gehörst. :-P Sollte das von dir beschrieben Verhalten wirklich ein breites Problem darstellen, müsstest du bei Boost den Vorschlag machen, einen Schalter analog wie bei mir zur Verhinderung des automatischen Linkens einzuführen.

Für dich selber könntest du die entsprechenden Stellen lokal auskommentieren. Bei einer offenbar exotischen Kombination wohl kein unerwartet großer Arbeitsschritt. Zumal ich dein Vorgehen nicht ganz nachvollziehen kann. Du mixt offenbar zwei verschiedene Standardlib/STL-Implementationen. Da scheinen mir die Probleme beim Linken noch die geringsten zu sein...

MfG
Andreas

[BeRsErKeR]

Ich kann den Argumenten nicht ganz folgen. Im Besonderen kann ich beim besten Willen nicht erkennen, wie das Buildsystem bei einer 3rd-Party-Lib erkennen soll, welche Libdatei nun auf die aktuelle Client-Programm-Konfiguration passt. Wie schon richtig erwähnt, gibt es u.U. sehr viele Versionen einer Lib, die *irgendwie* in den Dateinamen kodiert sind. Sieht man am besten beim Übersetzen von Boost. Ich halte es daher für gefährlich, dem Bibliotheksnutzer das Herausfinden der richtigen Lib-Version aufzubürden, zumal es eben auch automatisch geht. Hier mal mein eigener Code, der zeigt wie kompliziert das sein kann. Wie soll das die Buildengine leisten, ohne sie umständlich mit Daten füttern zu müssen?

...

Damit wird dann automatisch die richtige Bibliotheksdatei eingebunden, die einen komischen Namen wie
WinLib-0.2.0.0-amd64-vc100-MD.lib
WinLib-0.2.0.0-amd64-vc100-MDd.lib
WinLib-0.2.0.0-amd64-vc100-MT.lib
WinLib-0.2.0.0-amd64-vc100-MTd.lib
WinLib-0.2.0.0-x86-vc100-MD.lib
WinLib-0.2.0.0-x86-vc100-MDd.lib
WinLib-0.2.0.0-x86-vc100-MT.lib
haben kann.

Ein Programmierer sollte mit solchen Namen was anfangen können. Zur Not gibst du halt noch eindeutigere Namen an. Aber mal ehrlich jeder halbwegs intelligente Programmierer wird wissen welche Lib er wann und wo einbinden muss. Wenn nicht dann musst du es halt dokumentieren. Scheinbar hast du noch nie unter Linux programmiert. Da (gcc/g++) gibt es das pragma zum Glück nicht und da musst du auch genau wissen was du dazu linken musst.

[dot]

Ich kann den Argumenten nicht ganz folgen. Im Besonderen kann ich beim besten Willen nicht erkennen, wie das Buildsystem bei einer 3rd-Party-Lib erkennen soll, welche Libdatei nun auf die aktuelle Client-Programm-Konfiguration passt.

Gar nicht, es gibt keinen Weg das unter allen Voraussetzungen korrekt zu erkennen. Das ist auch nicht Aufgabe des Buildsystems der Library. Das Buildsystem der Library baut die Library und nicht die Anwendung die die Library verwendet. Welche Library in welcher Konfiguration verwendet werden soll, entscheidet das Buildsystem der Anwendung die die Library verwendet, genau für solche Dinge ist es schließlich überhaupt erst da.

Wie schon richtig erwähnt, gibt es u.U. sehr viele Versionen einer Lib, die *irgendwie* in den Dateinamen kodiert sind.

Ich hoffe doch sehr, dass das nicht tatsächlich "irgendwie" passiert, sondern erschöpfend dokumentiert ist.

Ich halte es daher für gefährlich, dem Bibliotheksnutzer das Herausfinden der richtigen Lib-Version aufzubürden, zumal es eben auch automatisch geht.

Ich halte es für den einzig vernünftigen Weg, da es, wie man an einigen der Posts hier schon schön sehen kann, im Allgemeinen eben nicht korrekt automatisierbar ist...

[kimmi]

Richtig, und für die 5% Ausnahmen habe ich auch vorgesorgt:

Code: Alles auswählen

#ifndef WINLIB_MANUAL_LIB_OVERRIDE
#pragma comment(lib,WINLIB_LIBRARY_STRING)
#endif

Wenn ich mir den Abschnitt aus boost/config/auto_link.hpp ansehe, scheint es da keine solche Option zu geben. Allerdings fällt auch auf, dass speziell STLPort massive Checks benötigt. Es schient also, dass du mit deinen Problemen eher zu den 5% gehörst. :-P Sollte das von dir beschrieben Verhalten wirklich ein breites Problem darstellen, müsstest du bei Boost den Vorschlag machen, einen Schalter analog wie bei mir zur Verhinderung des automatischen Linkens einzuführen.

Für dich selber könntest du die entsprechenden Stellen lokal auskommentieren. Bei einer offenbar exotischen Kombination wohl kein unerwartet großer Arbeitsschritt. Zumal ich dein Vorgehen nicht ganz nachvollziehen kann. Du mixt offenbar zwei verschiedene Standardlib/STL-Implementationen. Da scheinen mir die Probleme beim Linken noch die geringsten zu sein...

MfG
Andreas

Zur Zeit hat das Problem keine größere Priorität, jedoch war es sehr lästig. Und nein, nicht ich mische 2 verschiedene Wege, zwei verschiedene Projekte, bei denen ich helfe, benutzen unterschiedliche Build-Konfigurationen, die sich gegenseitig beeinflussen. So etwas kommt bei mir im Job öfter mal vor. Allerdings ist das eine Projekt in der Tat etwas leichtsinnig, was die Build-Konfiguration betrifft :).

Gruß Kimmi

[jumphigh]

Gar nicht, es gibt keinen Weg das unter allen Voraussetzungen korrekt zu erkennen. [...] Ich halte es für den einzig vernünftigen Weg, da es, wie man an einigen der Posts hier schon schön sehen kann, im Allgemeinen eben nicht korrekt automatisierbar ist...

Es ist wie bei jeder Automatik, in 95% der Fälle funktioniert es einfach. Die restlichen 5% können in der Tat schwierig werden. Allerdings halte ich dein Vorgehen für noch fragwürdiger: Du erklärst deine Spezialprobleme offenbar zum Allgemeinfall. Deshalb als Pauschalmeinung ein "taugt nichts, muss das Buildsystem machen" zu verbreiten, halte ich für problematischer als den Einsatz des Pragmas. Bei Boost, bei mir und bei MS-SDKs funktioniert das Pragma für die deutlich überwiegende Mehrheit der Windows-Entwickler problemlos.

Das ist auch nicht Aufgabe des Buildsystems der Library. Das Buildsystem der Library baut die Library und nicht die Anwendung die die Library verwendet. Welche Library in welcher Konfiguration verwendet werden soll, entscheidet das Buildsystem der Anwendung die die Library verwendet, genau für solche Dinge ist es schließlich überhaupt erst da.

Was versuchst du mir hier zu erklären? Es ist doch offensichtlich, dass es nur um das Buildsystem des Lib-Clients gehen kann. Bisher ist mir aber jeder von euch die Antwort schuldig geblieben, wie das dieses ominöse System von sich aus anstellen soll. Das manuelle Eintragen der Libversion erfüllt auf jeden Fall nicht eure Forderungen nach Übernahme dieser Aufgabe durch das Buildsystem.

Ich hoffe doch sehr, dass das nicht tatsächlich "irgendwie" passiert, sondern erschöpfend dokumentiert ist.

Ich schrieb niemals, dass die Automatik nicht dokumentiert sein sollte noch der einzige Weg sei.

Ich bleibe also dabei: Bisher konnte noch niemand zeigen, dass ein Buildsystem in diesem Bereich besser sei als eine vernünftig angelegte Automatik.

MfG
Andreas

[dot]

Gar nicht, es gibt keinen Weg das unter allen Voraussetzungen korrekt zu erkennen. [...] Ich halte es für den einzig vernünftigen Weg, da es, wie man an einigen der Posts hier schon schön sehen kann, im Allgemeinen eben nicht korrekt automatisierbar ist...

Es ist wie bei jeder Automatik, in 95% der Fälle funktioniert es einfach. Die restlichen 5% können in der Tat schwierig werden. Allerdings halte ich dein Vorgehen für noch fragwürdiger: Du erklärst deine Spezialprobleme offenbar zum Allgemeinfall.

Nanu? Was für Spezialprobleme hab ich denn? Ich wollte eigentlich genau das Gegenteil erklären, nämlich dass ein Spezialfall eben nicht der Allgemeinfall ist. Wie bereits einige andere hier aufgezeigt haben, funktioniert die Lösung mit #pragma comment nur in einem sehr schmalbandigen Bereich, auch wenn dieser aus deiner Sicht vielleicht wie 95% erscheinen mag, kommt natürlich immer drauf an was genau die 100% jetzt für einen bedeuten...

Deshalb als Pauschalmeinung ein "taugt nichts, muss das Buildsystem machen" zu verbreiten, halte ich für problematischer als den Einsatz des Pragmas. Bei Boost, bei mir und bei MS-SDKs funktioniert das Pragma für die deutlich überwiegende Mehrheit der Windows-Entwickler problemlos.

Kein mir bekanntes MS-SDK verwendet sowas und boost tut das auch nur für einen Spezialfall (MSVC) und dort bricht das Kartenhaus schon selbst bei minimalen Abweichungen (andere STL Implementierung) von dem was du hier als "Allgemeinfall" postulierst in sich zusammen wie schon gesagt wurde.

Das ist auch nicht Aufgabe des Buildsystems der Library. Das Buildsystem der Library baut die Library und nicht die Anwendung die die Library verwendet. Welche Library in welcher Konfiguration verwendet werden soll, entscheidet das Buildsystem der Anwendung die die Library verwendet, genau für solche Dinge ist es schließlich überhaupt erst da.

Was versuchst du mir hier zu erklären? Es ist doch offensichtlich, dass es nur um das Buildsystem des Lib-Clients gehen kann. Bisher ist mir aber jeder von euch die Antwort schuldig geblieben, wie das dieses ominöse System von sich aus anstellen soll. Das manuelle Eintragen der Libversion erfüllt auf jeden Fall nicht eure Forderungen nach Übernahme dieser Aufgabe durch das Buildsystem.

Was genau ist denn deiner Meinung nach die Aufgabe eines Buildsystems wenn nicht genau solche Dinge? Irgendwer muss das Buildsystem natürlich auch mal bauen und Konfigurieren, da kommt man so oder so nicht drumherum!? Das spart man sich auch mit #pragma comment nicht, denn man muss das Buildsystem immer noch so einrichten, dass es weiß wo es die Libraries zu suchen hat.

Abgesehen davon kann man als Libraryhersteller entsprechende Integrationen für verbreitete Buildsysteme wie z.B. MSBuild liefern (Stichwort Property Sheet etc.) die der Libraryuser einfach verwenden kann. Das wär imo z.B. eine ordentliche Lösung...


Wie du selbst sagst:

Im Besonderen kann ich beim besten Willen nicht erkennen, wie das Buildsystem bei einer 3rd-Party-Lib erkennen soll, welche Libdatei nun auf die aktuelle Client-Programm-Konfiguration passt.

Wenn es schon das Buildsystem nicht kann, wie soll es dann erst der Code können?

[jumphigh]

Nanu? Was für Spezialprobleme hab ich denn? Ich wollte eigentlich genau das Gegenteil erklären, nämlich dass ein Spezialfall eben nicht der Allgemeinfall ist. Wie bereits einige andere hier aufgezeigt haben, funktioniert die Lösung mit #pragma comment nur in einem sehr schmalbandigen Bereich, auch wenn dieser aus deiner Sicht vielleicht wie 95% erscheinen mag, kommt natürlich immer drauf an was genau die 100% jetzt für einen bedeuten...

Wer hat was aufgezeigt? Bisher hat nur Kimmi mehr als nur Andeutungen von seinen Problemen gemacht, und wenn ich ihn richtig verstanden habe, sucht er den Fehler eher nicht bei dem Pragma, sondern bei den kruden Projekteinstellungen. Dein "schmalbandiger Bereich" ist allgemeiner Standard in der Windows-Entwicklung.

Kein mir bekanntes MS-SDK verwendet sowas und boost tut das auch nur für einen Spezialfall (MSVC) und dort bricht das Kartenhaus schon selbst bei minimalen Abweichungen (andere STL Implementierung) von dem was du hier als "Allgemeinfall" postulierst in sich zusammen wie schon gesagt wurde.

Tja, da solltest du mal die Header des Windows-SDK durchsuchen. Im Include-Verzeichnis des aktuellen 7.1 finden sich 39 Header mit einem "#pragma comment(lib" (zumeist "uuid.lib", das mag das ganze etwas entwerten als Beweis), in den Samples wird das in den Beispielen massenhaft verwendet. Boost verwendet das Pragma bei MSVC, Borland und Intel, womit IMHO die bedeutendsten Win-C++-Compiler abgehandelt sind. Einen Wechsel der STL würde ich nicht gerade als "minimale Abweichung" bezeichnen, aber auch STLPort ist bei Boost AFAIK eine getestet Konfiguration, die beim Auto-Linking bedacht ist. Andere Konfigurationen wurden nicht getestet und sind daher nicht unterstützt. Keiner behauptet, dass die Linking-Automatik auch dann noch funktioniert. Ein Fehler von Boost mag sein, dass es keinen "Abschaltknopf" für die Automatik gibt.

Anstatt die Leute mit nichtssagenden Andeutungen zu verunsichern, wäre es langsam an der Zeit, die Probleme detaillierter zu benennen.

Was genau ist denn deiner Meinung nach die Aufgabe eines Buildsystems wenn nicht genau solche Dinge? Irgendwer muss das Buildsystem natürlich auch mal bauen und Konfigurieren, da kommt man so oder so nicht drumherum!? Das spart man sich auch mit #pragma comment nicht, denn man muss das Buildsystem immer noch so einrichten, dass es weiß wo es die Libraries zu suchen hat.

Häufig genutzte Zusatzlibs kommen bei mir in den allgemeinen Suchpfad für Header und Libs. Das muss genau einmal eingetragen werden und gilt dann für alle Projekte. Das mit dem *händischen* Eintragen bei jedem Projekt und jeder Konfiguration des jeweiligen Projektes vergleichen zu wollen, kann nicht dein Ernst sein. Was das alles mit dem Buildsystem zu tun hat, entzieht sich weiterhin meiner Kenntnis. Ich kennen nämlich kein solches System (im Bereich des unmanaged Code), welches sich die die Librarys selber heraussucht. Mir fiele nicht einmal ein Algorithmus ein, wie das zuverlässig funktionieren könnte, ohne vorher bisher nicht existente Standards festzulegen. Ich wiederhole mich: Das manuelle Eintragen ist *keine* Funktion des Buildsystems.

Abgesehen davon kann man als Libraryhersteller entsprechende Integrationen für verbreitete Buildsysteme wie z.B. MSBuild liefern (Stichwort Property Sheet etc.) die der Libraryuser einfach verwenden kann. Das wär imo z.B. eine ordentliche Lösung...

Was würde sich ändern? Ich müsste noch immer alles selber machen, nur statt einer Texteingabe eine Dropbox bedienen.

Wenn es schon das Buildsystem nicht kann, wie soll es dann erst der Code können?

Hast du dir boost/config/auto_link.hpp oder mein Beispiel etwa nicht angesehen? Aber feste weiter diskutieren...

MfG
Andreas