Include- und Lib-Pfade in VS2010

[Schrompf]

Moin alle,

soweit ich weiß, benutzt so mancher von Euch bereits die Betaversion von Visual Studio 2010. Aufgrund der Gerüchte über stark verbesserten C++-Support wollte ich die jetzt auch mal ausprobieren. Also habe ich die Installation über mich ergehen lassen, die bei Microsoft-Produktion ja auch immer zu einem Teil auf ein Windows-Update hinausläuft. Klappte alles prima, startet, konvertiert das alte Projekt prima, sieht tauglich aus.

Aaaaber: wie vermittle ich der IDE jetzt die Pfade für Includes, Libs usw.? Aus den Optionen ist der entsprechende Eintrag ja verschwunden. Dafür gibt es jetzt in den Projekteinstellungen Platz dafür. Nun will ich aber nicht für jede einzelne Build-Konfig in jedem einzelnen Projekt getrennt die Pfade einstellen - eine gesammelte Bearbeitung geht ja nicht, weil da schon gewisse Pfade vorher drinstehen, die ich dann ersetzen würde. Bliebe also nur manuelles Durchklicken durch jede einzelne Permutation... das ist mir jetzt zu blöd. Außerdem wären die Pfadeinstellungen dann ja im Projekt drin. Und Projektfiles sollen eigentlich eingecheckt werden. Aber bei jedem Programmierer aus dem Team liegen die Libs in anderen Pfaden, meine Pfade wären also nicht übertragbar.

Wir handhabt ihr die Pfade in euren Projekten bei VS2010? Habt ihr da schon Erfahrungen sammeln können? Ich habe mich jetzt auch mal in einem Property Sheet erprobt, aber meine Pfad-Einstellungen da werden irgendwie ignoriert...

Danke im Voraus!

Bye, Thomas

[Sternmull]

Hallo. Hab VS10 noch nicht selber ausprobiert. Im VC9 konfigurier ich mehrfach genutzte Einstellungen über die schon von dir erwähnten Propertysheets. Statt absoluten Pfadangaben verwende ich Umgebungsvariablen. QT hat ja z.B. sowieso seine QT_DIR-Umgebungsvariable (oder so ähnlich). Damit man auch verschiedene Versionen der gleichen Bibliothek verwenden kann, bennenne ich die Variablen immer recht ausführlich, z.B. BOOST_1_39_VC9. Zur flexibleren Konfiguration gibts auch solche Tools wie Pkg-config die Parameter zu vorhandenen Softwarepaketen abfragen können. Das hab ich zwar bisher ausschließlich unter Linux verwendet, aber unter Windows sollte das genau so gehen (bin mir nur nicht ganz sicher ob VS Kommandos ausführen kann um deren Ausgabe als Konfigurationsvariable zu verwenden).
Evtl. könnte man sogar beides gleichzeitig verwenden (sowohl Umgebungsvariable als auch Pkg-Config-Kommando) zur Konfiguration verwenden. Dann ist das Projekt funktionsfähig sobald eine der beiden Konfigurationsvarianten vorhanden ist. Das was fehlt evaluiert halt zu einem leeren String und wird (bis auf eine Warung "Umgebungsavriable nicht vorhanden" oder so ähnlich) ignoriert. Allerdings könnte das hässlich und verwirrend werden wenn beides Vorhanden ist, da dann evtl. verschiedene Bibliotheksfunktionen vermischt werden. Deshalb ist es wahrscheinlich besser sich auf eins festzulegen.

[Gelöschter Benutzer]

Hast du in den Projekteinstellungen nachgesehen?:

Configuration Properties --> VC++ Directories

Ansonsten finde ich die Lösung relativ suboptimal, da dies global nicht mehr möglich zu sein scheint (aus der IDE raus).

[VizOne]

Die globalen Einstellungen für die Pfade existieren noch, sind aber woanders zu finden (im Property Manager, Abschnitt Microsoft.Cpp.Win32.User).

Eine gute Erklärung dazu und zu den Gründen der Änderung findest du hier: http://blogs.msdn.com/vsproject/archive ... ories.aspx

[Schrompf]

Vielen Dank! Das erklärt den Wandel, und auch die Gründe dafür.

Ich bin inzwischen am Übelegen, ob ich nicht wirklich alle Dependencies einfach relativ zur Solution mit ins Repos packe. Nur leider sind einige davon ziemlich groß (Qt), und andere brauchen noch eine richtige Installation (PhysX), bevor sie überhaupt starten... nicht ganz einfach, das Ganze.

[Thoran]

Hi Schrompf!

Ich denke du kommst langsam an den Punkt wo sich ein Buildsystem bezahlt macht, oder eben alle Dependencies ins Projekt eingecheckt werden, wie du schon erwähnt hast.

Thoran
P.S.:Bitte versteh mich nicht falsch, ich will keine Werbung für Buildsysteme machen.

[VizOne]

P.S.:Bitte versteh mich nicht falsch, ich will keine Werbung für Buildsysteme machen.

Ich wohl! Automatisierte Builds/Continuous Integration sind mMn einfach ein Muss für jedes (nicht-triviale) Projekt. Ich verwende z.B. rake als Buildsystem (Ruby ist eine grandiose Sprache für so etwas) und als CI-Server CruiseControl.NET.

Ich bin inzwischen am Übelegen, ob ich nicht wirklich alle Dependencies einfach relativ zur Solution mit ins Repos packe.

Bei Subversion bietet sich z.B. svn:externals an. D.h. Tools und Shared Libs verwalte ich in einem(!) zentralen Repository, die einzelnen Projekte ziehen sich dann davon eine Kopie über svn:externals.

[Sternmull]

Allerdings gibt es z.B. für PhysX kein SVN repo, und für QT soweit ich weiss auch nicht (ehrlich gesagt verspühre ich auch keine Lust so ein Monster wie QT per SVN auf die Platte zu ziehen). Man sollte ohnehin nicht dazu gezwungen werden die externen Abhängigkeiten durch das Repository oder Projekt diktiert zu bekommen. Die Buildumgebung kann bei jedem anders aussehen. Ich will ja nicht für jedes Projekt eine neue Version der gleichen Bibliothek installieren. Statt dessen will ich die Dependencies nicht nur in einem Projekt, sondern potentiell in mehreren verwenden.
Projekte wie Ogre machen es so dass sie die externen Abhängikeiten für einige Compiler in vorkompilierter Form zum Download anbieten. Wer die Abhängikeiten noch nicht hat, kann sie sich dort runterladen und ist zufrieden. Wer die Abhängikeiten aber sowieso schon installiert hat, kann das auch sein lassen. Das ist eine ausreichend bequeme und flexible Lösung. Das anlegen von wenigen Umgebungsvariablen oder (was natürlich noch besser wäre) das ändern einer Konfigurationsdatei sollte man als Softwareentwickler hin bekommen.
Um die Installation von sowas wie PhysX kommt man halt nicht drum rum, es sei denn der Hersteller ermöglicht einem eine installationsfreie Verwendung. Wenn nicht, nimmt einem kein Buildsystem der Welt die Installation ab.

[VizOne]

Allerdings gibt es z.B. für PhysX kein SVN repo, und für QT soweit ich weiss auch nicht (ehrlich gesagt verspühre ich auch keine Lust so ein Monster wie QT per SVN auf die Platte zu ziehen).

Ich meinte auch eigentlich eher die Binaries.

Man sollte ohnehin nicht dazu gezwungen werden die externen Abhängigkeiten durch das Repository oder Projekt diktiert zu bekommen. Die Buildumgebung kann bei jedem anders aussehen.

Sollte sie aber möglichst wenig, sonst gibt's diesen Preis hier schneller als einem lieb ist:

Quelle: codinghorror.com

Im Ernst, ein Projekt sollte idealerweise auf jeden Entwicklerrechner erstellt werden können, OHNE dass dafür persönliche Einstellungen vorgenommen werden. Wie gesagt, idealerweise, aber man kann dem Ideal relativ nahe kommen. Zumindest erleichtern einem solch autarke Projekte das Leben ungemein.

Ich will ja nicht für jedes Projekt eine neue Version der gleichen Bibliothek installieren. Statt dessen will ich die Dependencies nicht nur in einem Projekt, sondern potentiell in mehreren verwenden.

Ja sicher, davon rede ich ja: auf deinem eigenen Build/SVN/etc-Server erstellst du dir ein Repository mit diversen Tools, Libs und anderen Abhängigkeiten. Die "richtigen" Projekt-Repositories binden dieses Repos über svn:externals "virtuell" mit ein. Wenn jetzt einer deiner Entwickler ein Projekt auscheckt, liegen alle Dependencies immer an der selben Stelle relativ zum Projekt. Das macht das schreiben von Build-Files viel leichter. Ob die Libs etc. dabei physisch mehrfach auf der Platte liegen ist dabei egal, sie werden zentral (über das Dependencies-Repos) verwaltet. Und HDDs sind billig (zumindest die mit den rotierenden Scheiben "von früher" :lol:)

Um die Installation von sowas wie PhysX kommt man halt nicht drum rum, es sei denn der Hersteller ermöglicht einem eine installationsfreie Verwendung. Wenn nicht, nimmt einem kein Buildsystem der Welt die Installation ab.

Das ist allerdings wirklich ärgerlich, aber hoffentlich nur eine seltenere Ausnahme.

[Sternmull]

Du willst doch nicht im ernst das ich mir häufig genutzte Bibliotheken wie Boost, Qt, wxWidgets, etc. mehrfach installiere oder? Für jedes Projekt bei dem einer meint das ich die Version aus seinem Repo nehmen soll?!? So etwas installiert man sich an einem zentralen Ort (den jeder für sich selbst bestimmen kann), und verwendet es dann in mehreren Projekten. Damit die Dinger gefunden werden gibt es Tools, wie eben z.B. das bereits erwähnte pkg-config. Viele Buildsysteme sind auch in der Lage (zumindest standard-)Bibliotheken automtisch zu finden. Für VS reicht es wenn man Umgebungsvariablen setzt, ein Propertysheet oder eine Projektkonfiguration für sich anpasst. Solange die notwendigen Schritte trivial und dokumentiert sind, ist mir das tausend mal lieber als dein Vorschlag.

[VizOne]

Du willst doch nicht im ernst das ich mir häufig genutzte Bibliotheken wie Boost, Qt, wxWidgets, etc. mehrfach installiere oder? Für jedes Projekt bei dem einer meint das ich die Version aus seinem Repo nehmen soll?!?

Doch, genau das. Von mir aus 5, 10 oder 100 mal auf dem Entwicklungssystem, aber jeweils aus einem zentralen Repository.

So etwas installiert man sich an einem zentralen Ort (den jeder für sich selbst bestimmen kann), und verwendet es dann in mehreren Projekten.

Wer ist "man"? Klar kann "man" das machen und wird ja wohl offensichtlich auch erschreckend oft so gehandhabt. Wenn man alleine an einem Projekt rumfrickelt ist das auch alles prima. Aber viel Spaß, wenn du eine neue Version einer Bibliothek auf 50 Rechner deployen willst. Nach vier Wochen haben dann 23 Entwickler Version 1.3, 12 haben 1.3.2 und 15 haben noch 1.2.9. Bei der einen Hälfte läuft alles wunderbar, der Rest beschwert sich, "welcher Vollidiot die Änderungen eingecheckt hat - das kompiliert ja nicht mal mehr".

Besonders schön ist es, wenn man nach 12 Monaten ein altes Projekt neu compilen möchte (kritischer Bugfix etc.), aber sich die "persönliche Buildumgebung" massiv geändert hat. Wer sich den Stress antun möchte, bitte.

Damit die Dinger gefunden werden gibt es Tools, wie eben z.B. das bereits erwähnte pkg-config. Viele Buildsysteme sind auch in der Lage (zumindest standard-)Bibliotheken automtisch zu finden. Für VS reicht es wenn man Umgebungsvariablen setzt, ein Propertysheet oder eine Projektkonfiguration für sich anpasst. Solange die notwendigen Schritte trivial und dokumentiert sind, ist mir das tausend mal lieber als dein Vorschlag.

Alles, was über "auschecken und eine .bat Datei doppelklicken zum Erstellen des Projekts" hinausgeht, wird umso problematischer, je größer das Entwicklerteam ist. Ich sag ja: "Works on MY machine" ist kein Qualitätsmerkmal.

Vielleicht mal als Literaturtipp: The Productive Programmer, Kapitel 5, "Canonicality".

[Sternmull]

Du ersetzt "Works on MY machine" durch "Works with MY Library on MY system". Tu doch gleich noch den einen Compiler dazu den du als einziges unterstützt, und die STL die damit läuft. Und schick denen die unter Linux entwickeln ein Memo das sie sich ne Platte machen sollen wie sie deine Batchdatei starten. Am besten gleich eine VM in der die eine Systemkonfiguration drin ist in der das alles gebaut werden kann.

[VizOne]

Am besten gleich eine VM in der die eine Systemkonfiguration drin ist in der das alles gebaut werden kann.

Kein Witz, das ist tatsächlich eine sehr sinnvolle Lösung und äußerst empfehlenswert, quasi das Ideal: jeder hat die selbe Maschine.

Um mal besagtes Buch zu zitieren: "The unacceptable alternative is unfortunately the default in most projects: each developer has libraries on his or her own machines, sometimes in different directories. Anyone who has lived through a project setup like this knows what nightmare maintaining this wet* infrastructure can be."

* "wet" im Bezug auf DRY (don't repeat yourself)

EDIT: es geht auch nicht darum, nur einen Compiler oder eine Bibliotheksversion zu unterstützen, sondern sicherzustellen, dass jeder Entwickler unter den gleichen Bedingungen arbeitet, also ein bestimmtes Setup, das garantiert unterstützt wird.

[Matthias Gubisch]

Die Theorie dass jeder Entwickler das gleiche System/ die gleiche Konfiguration haben soll ist ja an und für sich nicht schlecht.
Sollte in einer Firma wo die Rechner zentral von der IT-Abteilung aufgesetz werden auch kein Problem sein

Bei Hobbyprojekten sieht die Sache schon wieder anders aus...
von daher war mir die Option dass ich alles einmal Zentral habe immer ganz lieb.

Hatte auch schon mal den Fall dass zwei verschiedene QT-Versionen installiert waren, naja beim Setuperstellen wurden dann promt die falschen DLLs kopiert, also so ganz ohne ist das auch nicht wenn man alles doppelt und dreifach hat.

Ausserdem sind verschieden Konfigurationen beim Entwicklen auch nicht unbedingt falsch, weil dann sieht man beim Entwicklen möglicherweiße schon die Probleme mit verschiedenen Dingen und kann gegensteueren, sonst kann es sehr leicht vorkommen dass dann das böse erwachen kommt wenn man das ganze mal auf einem anderen System testet und dann gibts doch wieder das nicht sehr begehrte Prädikat "Works on My Machine"

Hat also beides seine vor und Nachteile würd ich sagen

[Schrompf]

Ich glaube, die feurige Diskussion stammt primär daher, dass hier zwei sehr unterschiedliche Szenarien veranschlagt werden. VizOne hat eine Firma im Auge, bei der natürlich alle Programmierer nach Möglichkeit ein identisches Setup haben - Compiler, Bibliotheken, Pfade. Da ist es nur logisch, dass im Idealfall alles fertig miteinander verknüpft aus der Versionverwaltung purzelt. Für solche Szenarien ist die neue Dependency-Verwaltung von VC++2010 ein Segen. Bzw. ein leichter Segen, denn das ging vorher über "Zusätzliche Include-Pfade" und "Zusätzliche Bibliothekspfade" auch schon.

Sternmull dagegen hat die Situation der Hobby- oder OpenSource-Programmierer im Auge. Vermutlich auch deswegen, weil der Thread ursprünglich von mir begründet wurde und ich nunmal eine Lösung für unser kleines Hobbyteam gesucht habe. Wir können mit Mühe und Not noch die IDE vorschreiben, aber definitiv keine Pfade. Und bei OpenSource-Projekten kommen die Leute mit allen möglichen IDEs und Setups angerannt, eine Vereinheitlichung ist da ausgeschlossen. Stattdessen muss man Code schreiben, der mit möglichst vielen Compilern und Dritt-Lib-Versionen zusammenspielt. Und dafür war das alte System für Include- und Lib-Pfade einfach ideal. Nach obigem Link geht das allerdings auch unter VC10 noch, nämlich über das dort genannte User-PropertySheet, dass bei der Projektkonvertierung automatisch eingebunden wird.