Script beim Öffnen von Solution laufen lassen



  • Gibt es eine Möglichkeit, beim Öffnen, oder vor dem Bauen, einer Solution, ein Script laufen zu lassen, und über dieses Script Umgebungsvariablen in Visual Studio zu setzen?

    Konkret möchte ich einen Pfad dynamisch ermitteln, und diesen dann als Include-Pfad hinzufügen.
    Wenn ich eine Umgebungsvariable setzen kann reicht das, da ich ja im Projekt dann einfach $(VariablenName) bei den "additional include directories" reinschreiben kann.

    Ideal wäre wenn das Script bereits beim Öffnen der Solution läuft. Es würde ansonsten auch reichen wenn es beim Build Vorgang gestartet wird.

    Oder falls es so ohne weiteres nicht geht, gibt es vielleicht irgendwelche fertigen Plugins mit denen man sowas gebacken bekommen würde?

    p.S.: "ein Script" kann natürlich auch "ein Makro" sein. Ich hab's noch nicht ausprobiert, aber ich denke über Makros müsste es gehen. Sind ja auch nur VB .NET Scripts wenn ich mich nicht irre...

    p.p.S.: der Script/Makro-Code müsste dabei nichtmal im Solution/Project-File stehen, sondern könnte ruhig fix als Makro im Studio eingetragen sein. D.h. es würde im Prinzip ausreichen wenn ich ein bestimmtes Script/Makro bei "OnOpenSolution" ausführen lassen könnte.


  • Mod



  • Ja die Property-Sheets kenne ich wohl. Damit bekomme ich das was ich machen möchte allerdings nicht hin.

    Grund: das File aus dem ich Einstellungen laden möchte, liegt nicht immer am gleichen Fleck. Also sowohl der absolute Pfad, sowie der relative Pfad zum .sln/.vcproj File ist je nachdem unterschiedlich.

    Finden würde ich das File indem ich erst im Verzeichnis der Solution anfange, und dann Verzeichnis für Verzeichnis "rausgehe" (in Richtung Root). Das erste File mit Namen X (".xyz-buildenv" oder was auch immer), wird genommen.

    Da drinnen stehen dann einige Definitionen, eben include Pfade etc. Im Prinzip Dinge die das Build-Environment definieren.

    Genau zu erklären *wieso* ich das brauche/möchte ist in zwei oder drei Sätzen leider nicht möglich. Ich glaube auf jeden Fall dass ich gute Gründe dafür habe 🙂

    Ich hab auch bereits eine Möglichkeit gefunden das zu machen, allerdings brauche ich dafür ein Visual-Studio Add-in. Was ich bis jetzt gesehen (und bereits ausprobiert) habe, ist das aber keine Hexerei. Ein kleines Add-in, welches ein File nach dem beschriebenen Muster sucht, lädt, und an Lua übergibt -> fertig 🙂
    (OK, etwas vereinfacht dargestellt, aber das wird sicher kein 10 KLOC Projekt)


  • Mod

    Da man solch ein Sheet nur einmal zuordnen muss, verstehe ich Deine Argumentation nicht. Denn die gesamte Struktur eines Projektes ändert sich ja nicht...

    Außerdem könntest Du das auch dadurch erledigen indem Du das zentrale vsprops Verzeichnis von VS verwendest.

    \Microsoft Visual Studio 8\VC\VCProjectDefaults\



  • Du könntest es mir auch einfach glauben 🙂

    Wir haben verschiedene Projekte.
    Wir haben eigene Libraries, die in allen diesen Projekten verwendet werden.
    Und wir verwenden natürlich ThirdParty Libs.
    Und natürlich diverse SDKs (Windows, DirectX etc.).

    Die eigenen Libraries verwenden im Interface z.T. Klassen aus ThirdParty Libraries (boost::shared_ptr, boost::function, diverse Crypto++ Dinge etc.) oder SDKs.

    Sagen wir wir haben Projekt "Car" und Projekt "Train", und die eigene Library "Screw". Screw verwendet nun Boost, Crypto++ etc. im Interface.

    Car wird mit Boost 1.34.1 und Crypto++ 5.2.1 gebaut, und braucht Screw.
    Train wird mit Boost 1.38.0 und Crypto++ 5.5.2 gebaut, und braucht auch Screw.

    Damit alles funktioniert, muss Screw nun 1x mit Boost 1.34.1 und 1x mit Boost 1.38.0 gebaut werden -- je nachdem für welches Projekt eben.

    Entwickler Franz arbeitet an Car, der hat's relativ einfach.
    Entwickler Susi arbeitet an Train, die hat's auch einfach.
    Entwickler Hans arbeitet an Car UND Train UND Screw. Der hat's doof. (3x darfst du raten wer ich in diesem Beispiel bin.)

    Wie soll ich nun Screw einstellen, damit das alles funktioniert?

    Reicht das um dir eine Vorstellung zu vermitteln?

    ----

    Was das zentrale vsprops Verzeichnis angeht: Horror^3. Diverse Einstellungen sollten nachvollziehbar sein, und im SCC abgelegt. Ein Verzeichnis irgendwo tief in Program Files vergraben ist da IMO nicht der beste Platz um wichtige Konfigurations-Files abzulegen.

    Davon abgesehen bringt es mir nix: ich brauche in Screw einfach je nachdem ob das Projekt Car oder Train compiliert wird unterschiedliche Include-Pfade.

    Derzeit mache ich es so, dass ich mehrere Ordner auf der Platte habe, und die einfach umbenenne wenn ich von einem Projekt zum anderen wechsle.

    Beispiel: C:\Project ist das aktuelle Projekt (sagen wir Train), und C:\Project_Car -- da sind die Car Files drin.

    Die Boost ist so immer unter C:\Projects\Boost zu finden, egal welche Version. In VS sind die Include-Pfade fix auf C:\Projects\Boost etc. eingestellt.

    Nur ist das sehr sehr unkomfortabel. Vor allem ... nach dem umbenennen eines Verzeichnisses rödeln Visual Assist X, TSVNCache und VisualSVN wie die Irren auf der Platte rum. Minutenlang. *kotz*

    Und um dir eine Grössenordnung zu vermitteln...
    Statt den 2 Projekten Car und Train denk dir mal 5
    Statt den 2 ThirdParty Libraries Boost und Crypto++ denk dir ~15
    Statt der einen eigenen Library denk dir ~10
    Und statt der 3 Entwickler denk dir 20

    Die gesamte Anzahl an Solutions liegt weit über 300.


  • Mod

    Ich verstehe. Aber sage Dir gleich dass ich dieses Boost Chaos alleine schon eliminieren würde.
    Dann würde ich die raten, die entsprechenden Pfade der Libs zu Versionieren.

    Versucht es hinzubekommen von jeder Software (Lib) nur eine Version einzusetzen... 😉

    Libraries 
     - Boost
       - Ver 1.34.1
         - Lib 
         - include
       - Ver 1.38.0
         - Lib 
         - include
     - Crypto 
       - Ver 1.34.1
         - Lib 
         - include
       - Ver 1.38.0
         - Lib 
         - include
    Projects
     - Bin
     - Car
       - Inlucde
       - Lib 
     - Screw
       - Inlucde
       - Lib 
     - Train
       - Inlucde
       - Lib
    

    Jedes der Library Projekte hat eine entsprechende vsprops Datei in seinem Folder, der die Include und Lib Pfade benennt. Nur die muss man dann noch in das Train/Screw/Car Projekt einbeziehen

    Ich hoffe Du verstehst was ich meine...



  • Aber sage Dir gleich dass ich dieses Boost Chaos alleine schon eliminieren würde.

    Was für ein Chaos? 🙂

    Versucht es hinzubekommen von jeder Software (Lib) nur eine Version einzusetzen...

    Nicht durchführbar.
    Vor allem bei Versions-Wechsel. Angenommen wir machen jetzt alles auf Boost 1.38. Dann kommt die 1.39. Dann müssten wir 5 Projekte gleichzeitig umstellen. Du kannst davon ausgehen dass min. 2 der Projektleiter mir dann nen Vogel zeigen wenn ich denen sage "heute stellen wir das um".

    Schön in der Theorie, undurchführbar in der Praxis.

    Jedes der Library Projekte hat eine entsprechende vsprops Datei in seinem Folder, der die Include und Lib Pfade benennt. Nur die muss man dann noch in das Train/Screw/Car Projekt einbeziehen

    Ich hoffe Du verstehst was ich meine...

    Ich denke schon.
    Setzt aber - wenn ich dich richtig verstanden habe - voraus, dass alle Projekte die gleichen Versionen von Boost, Crypto++ etc. verwenden. Was wie gesagt undurchführbar ist.

    Was ich mir vorstelle, ist, ein File für jedes Projekt zu haben, wo im Prinzip drinsteht (sinngemäss, nicht genau in dem Format):

    ThirdPartyLibraries= \
        "Boost 1.34.1" \
        "Cryptopp 5.2.1" \
        "zlib 1.2.3" \
        ...
    
    OwnLibraries= \
        "Blah" \
        "Blubb" \
        ...
    
    SDKs= \
        "Windows SDK 6.0" \
        "DirectX SDK 123.456" \
        ...
    

    Und alle Solutions/.vcproj-Dinger sollen dann dieses File als Referenz verwenden, um das Build-Environment zu definieren.

    Bloss wie referenziere ich das?
    Ich würde halt gerne einfach sagen können "$(ProjectRoot)/File.xyz" oder sowas ähnliches.
    Bloss... wie ermittle ich $(ProjectRoot)?

    Dazu war meine Idee eben die, dass ich mich mit irgendeinem Script/Add-in/... in den Verzeichnissen Richtung Root durchhantle, und einfach gucke wo ein File mit bestimmtem Namen liegt. Wird das File nicht gefunden, bleibt einfach alles so wie's im Studio eingestellt ist (also die ganzen Pfade).

    Die einzige andere Möglichkeit die mir einfällt, wäre, die Position jedes .vcproj Files relativ zum "ProjectRoot" zu fixieren. Und das wäre ein ziemlicher Aufwand für uns.

    Vor allem müsste man auch alle Projekte gleichzeitig umstellen, sonst würden die bereits modifizierten Libraries in den Projekten nichtmehr funktionieren, die noch nicht umgestellt wurden. Weil das blöde File eben nicht dort liegt wo es liegen sollte. Ergo: auch schwer durchführbar bis undurchführbar.



  • Nochwas:

    Die Position der Libraries (ThirdParty + eigene) können auf keinen Fall absolute Pfade sein, denn wir müssen auch Branches und Tags bauen können.

    Und die Branches und Tags haben immer Kopien der ganzen Libraries mit drin. Von der Versionisierung wäre das kaum anders machbar. Vor allem weil wir auch mal Änderungen an ThirdParty Libs machen (Bugfixes, kleine Erweiterungen). Wenn wir dann nach ein paar Monaten mal nen alten Tag bauen wollen (müssen), sollte der natürlich genau mit den passenden "Snapshots" der Libraries erfolgen, in dem Zustand wie sie damals waren. Und eben nur "kontrolliert" auf neuere Versionen umgestellt, wenn man z.B. nen alten Tag hernimmt, um nen Hotfix für die Version zu basteln.

    BTW: Releases erfolgen bei uns in min. 3 der grossen Projekte so alle 1-3 Monate. Das ist der Horror schlechthin, aber ich laufe hier gegen ne Wand. Sehe keine Chance das zu verbessern, also langsamer zu Releasen.

    p.S.: Und danke auf jeden Fall für deine Vorschläge 🙂



  • Ist Boost denn überhaupt nicht abwärtskompatibel? D.h. ändert sich so viel, dass man beim Update von 1.38 auf 1.39 alles anpassen muss?


  • Mod

    Und warum machst Du es dann nicht vsprops Dateien. Dies sind schmale XML Dateien, die man je Projekt anpassen kann...
    Langsam verstehe ich Dein problem nicht mehr. Wenn Du alle Libs soieso paralell hast dann sind es doch nur Projektspezifische Einstellungen und die kann man in einer vsprops zusammenfassen!

    Und warum müssen die übergreifend sein? Sie müssen ja gerade im Projekt liegen, damit sie gebranched werden können...

    Ich weißt nicht. Icxh sehe das nicht so kompliziert und ich würde meinem Projektleiter was husten mit den vielen Boost Versionen... Das macht am Ende mehr arbeit als mit einem Hauruck umzustellen.

    Alleine das Branchen ist ja ein Chaos hoch sieben.


Log in to reply