Probleme beim Setzen von Systemvariablen.

[Nai]

Hallo,

Ich habe ein kleines Problem mit Systemvariablen, wo ich euch gerne um Hilfe bitten würde:
Ich habe ein C++-Programm von dem heraus ich über system("...") unter Windows einen Compiler (ICC) starten möchte. Der Compiler benötigt aber Umgebungsvariablen, die man zuvor in jedem Konsolenfenster einmal durch das Ausführen einer mitgelieferten Batch-Datei setzen muss. Allerdings wenn ich zuvor von meinem Programm heraus die Batch-Datei ebenfalls per system("...") starte, funktioniert dies nicht, d.h. der Compiler findet dann die Systemvariablen nicht. Was aber funktioniert ist, wenn ich über die Kommandozeile zuerst die Batch-Datei ausführe, und danach mein Programm starte, welches dann den Compiler aufruft. Mit der Lösung könnte ich mich ja anfreunden, wenn ich sie mit dem Visual Studio Debugger zum Laufen bekommen könnte; aber ich bekomme es auch nicht hin, dass das Visual Studio vor dem Debuggen die Batch-Datei ausführt.

Was wäre also eine elegante Lösung dafür, dass ich im Visual Studio Debugger mit den korrekt gesetzten Umgebungsvariablen auf meinem Programm arbeiten kann?

Liebe Grüße,
Nai

 

[andy_m4]

Ich denke mal system startet eine neue Shell-Instanz. Die dort gemachten Änderungen gehen also wieder verloren sobald das durch ist und die Shell damit wieder geschlossen ist.
Du musst das also quasi in einem Aufruf machen. Sowohl das setzen der Umgebungsvariablen als auch das starten des eigentlichen Nutzskriptes.

Evtl. gibt es noch eine Möglichkeit dem system-Aufruf direkt Umgebungsvariablen mitzugeben (unter Unix würde ich da jetzt einfach ein env ENVVAR=val ./myscript.sh machen). Schau mal in die Referenz-Doku (evtl. stehen daneben auch noch andere Aufrufe die das leisten; denke da an sowas wie execve)

 

[0x8100]

die umgebungsvariablen sind immer nur in dem kontext gültig, in dem sie auch gesetzt wurden. d.h. wenn du einen prozess mit deiner batch-datei startest und dort die variablen setzt, dann sind die nur dort und in von dort gestarteten unterprozessen gültig. ein separat gestarteter prozess weiss davon nichts.

ich kenne visual studio nicht und kann nicht sagen, ob man beim starten des programms oder des debuggers umgebungsvariablen setzen kann, aber eigentlich sollte das gehen. falls nicht, kannst die umgebungsvariablen aus der batch-datei immer noch global setzen (als user sollte reichen).

edit: google sagt, dass man die variable in vs setzen kann -> https://stackoverflow.com/questions...ent-variables-when-debugging-in-visual-studio

 

[Micke]

a) mit "setx" überleben die Umgebungsvariablen deine Sitzung
b) du kannst deinen compiler und deine batch auch aus einer weiteren batch Datei aufrufen lassen
c) compiler mit Parametern statt Environment settings aufrufen, ist immer zu bevorzugen

oot: mit den Kohlmeisen ist Ironie oder ein persönliches Anliegen ?

 

[Nai]

Vielen Dank für die Antworten 😊

Auf das manuelle Setzen der Umgebungsvariablen bin ich auch schon gekommen. Allerdings scheitert dies bei mir etwas daran, dass ich hierfür erst die etwas komplexeren Batch-skripte durchgehen müsste, schauen welche Umgebungsvariablen sie unter welchen Umständen und mit welchen Werten setzen, was bei meinen rudimentären Batch-Kenntnissen auch kein leichtes unterfangen ist, und ich in diese kleine Nebenbaustelle nicht allzuviel Zeit reinstecken wollte. Da hoffte ich, dass es hierfür eine sehr elegante und einfache Lösung für jemanden gibt, der von Batch keine Ahnung hat.

Du musst das also quasi in einem Aufruf machen. Sowohl das setzen der Umgebungsvariablen als auch das starten des eigentlichen Nutzskriptes.

Das hat mich noch auf eine Idee gebracht die aktuell auch funktioniert: Ich bastle mir nun per String-Konkatenation von meinem Programm aus eine weitere Batch-Datei, die wiederum die Batch-Datei des Compilers aufruft und danach den Compiler mit den passenden Dateien als Argument startet.

mit "setx" überleben deine Einstellungen deine Sitzung

Das wäre natürlich noch eleganter, da ich hier einfach nur sämtliche set-Befehle in den Batch Dateien ersetzen müsste. Werde ich nachher noch probieren.

 

[Yuuri]

a) mit "setx" überleben die Umgebungsvariablen deine Sitzung

Und gleich mal das gesamte System verkonfiguriert... :O

Das wäre natürlich noch eleganter

Ganz im Gegenteil.

Da hoffte ich, dass es hierfür eine sehr elegante und einfache Lösung für jemanden gibt, der von Batch keine Ahnung hat.

Erstell dir ne eigene Batch, die die Compiler-Batch via call aufruft und setz danach deine eigenen Befehle ab. Indirection/Abstraction ist doch der Inbegriff von Softwareentwicklung.

 

[Nai]

Und gleich mal das gesamte System verkonfiguriert... :O

Da es sowieso nur ein Workaround fürs Debuggen ist und ich einfach nur noch damit fertig werden will so dass ich wieder Geld bekomme, ist mir das Verkonfigurieren eigentlich egal. Da bin ich mit jeder Lösung zu frieden, egal wie schmutzig sie ist, hauptsache sie ist einfach. Das einmalige dauerhafte Setzen wäre sogar etwas vorteilhaft, da das Ausführen der Bat jedesmal 2 oder 3 Sekunden dauert, und ich wohl über die nächsten Wochen noch ein paar 10 000 DLLs kompilieren werde....

Erstell dir ne eigene Batch, die die Compiler-Batch via call aufruft und setz danach deine eigenen Befehle ab. Indirection/Abstraction ist doch der Inbegriff von Softwareentwicklung.

Habe ich wie ich bereits im letzten Post geschrieben habe schon getan.

 

[Micke]

da Thema geklärt

und ich wohl über die nächsten Wochen noch ein paar 10 000 DLLs kompilieren werde.

Wie kommt es denn zu so einer Situation 🙂 ? Arbeitest du bei GitHub 🙂 ?

 

[Nai]

Ich muss für die Arbeit an der Uni automatisch ein optimiertes Programm für eine numerische Simulation generieren. Dies löse ich, indem ich das Programm in Teilprogramme zerlege, jedes Teilprogramm als eine eigne DLL kompiliere und diese DLL dann zur Laufzeit lade. Dadurch kann ich die einzelnen DLLs auch getrennt voneinander über diverse Performance-Parameter optimieren, wobei ich sie für jede Parameterkombination erneut kompilieren muss. Da es viele Parameter für jede einzelne DLL gibt, gibt es dennoch eine kombinatorische Explosion von Möglichkeiten. Aktuell mache ich da auch noch Größtenteils eine vollständige Suche mit diversen früheren Abbrüchen, wobei ich das auch noch etwas eleganter gestalten werde.

 

[Micke]

ah interessant. Habt ihr da bereits Kennzahlen, wieviel Verbesserung da geht oder ihr euch erhofft ?

Du kannst die builds übrigens auch mit "start" parallelisieren, falls das hilft.