Hallo, ich habe folgendes Problem mit diesem Pfad: SET(CMAKE_MAKE_PROGRAM "C:\Users\qwerrtz2\AppData\Roaming\GNU MCU Eclipse\Build Tools\2.11-20180428-1604\bin\make.exe") Formatiert inzwischen zu: "C:\\Users\\qwerrtz2\\AppData\\Roaming\\GNU MCU Eclipse\\Build Tools\\2.11-20180428-1604\\bin\\make.exe" Auch probiert: C:/Users/... -> gleiches Ergebnis Aktueller Message Output im Toolchain File: C:\Users\qwerrtz2\AppData\Roaming\GNU MCU Eclipse\Build Tools\2.11-20180428-1604\bin\make.exe Message Ausgabe im übergeorneten globalen cmake-File: C:/Users/QWERR~1/AppData/Roaming/GNUMCU~1/BUILDT~1/271AC~1.12-/bin/make. exe Wie macht man das richtig?
Ich vermute mal in dem man den Whitespace escaped: "\ " Aber ich würd trotzdem empfehlen einen Compiler-Pfad ohne anzulegen. Whitespaces sind auch 2019 schlichtweg noch ein Ärgernis...
Vincent H. schrieb: > Ich vermute mal in dem man den Whitespace escaped: > "\ " > > Aber ich würd trotzdem empfehlen einen Compiler-Pfad ohne anzulegen. > Whitespaces sind auch 2019 schlichtweg noch ein Ärgernis... Hat nicht funktioniert. Frage mich auch, warum die Strings: C:/Program Files (x86)/GNU Tools ARM Embedded/8 2018-q4-major/… nicht verfälscht werden. Die werden sowohl im Toolchain Script in gewünschter Form bei MESSAGE(WARNING "${VARIABLE}) ausgegeben als auch in den anderen cmake Files.
Du hast dich für Windows entschieden also lebe mit seinen Inkonsequenzen.
elder wise schrieb: > Du hast dich für Windows entschieden also lebe mit seinen > Inkonsequenzen. Du meinst mit kaputter Software. Wer Plattformübergreifend programieren will muss es halt auch tun. Einfach dem Zielsystem die Schuld an den eigenen Fehlern geben zählt nicht. Aber ich verstehe hier das Problem nicht. Was funktioniert denn nun nicht? Gehts nur um die seltsame Anzeige? Nun, leb damit...
test schrieb: > elder wise schrieb: >> Du hast dich für Windows entschieden also lebe mit seinen >> Inkonsequenzen. > > Du meinst mit kaputter Software. Wer Plattformübergreifend programieren > will muss es halt auch tun. Einfach dem Zielsystem die Schuld an den > eigenen Fehlern geben zählt nicht. > > > Aber ich verstehe hier das Problem nicht. Was funktioniert denn nun > nicht? Gehts nur um die seltsame Anzeige? Nun, leb damit... Die Erfahrung des TO fusst auf einem Entwickungswerkzeug das mit inkonsequenter Handhabung von besonderen Characters im Dateisystem nicht klar kommt. Meine Erfahrung hat mich gelehrt auf zuverlässige, deterministische, dokumentierte und Quelloffene Betriebs- & Dateisysteme zu setzen. Auch wenn für andere Zielsysteme zu entwickeln ist. Neudeutsch "Cross development". Da scheint im Pfad nach make.exe Zeichen/Zeichenfolge vor zu kommen, was oberflächlich betrachtet wie ein Leerzeichen aussieht. Das kann aber auch was anderes als SPACE 0x20 sein, wie vom Pfad ...Program Files... erlebt. Unter Windows kann das nun... überflüssigerweise aufwändig (?) werden den Fall zu untersuchen resp. die Ursachen dafür zu verstehen. Beste Strategie: vermeidbare Probleme tatsächlich... vermeiden!
elder wise schrieb: > Unter Windows kann das nun... überflüssigerweise aufwändig (?) werden > den Fall zu untersuchen resp. die Ursachen dafür zu verstehen. Unter Linux genauso, das habe ich auch schon durch. Das Problem ist dann das die Software einfach mal so davon ausgeht das das schon irgendwie klappt und eh niemand irgendwelche (erlaubten) seltsamen Zeichen nutzt. > Beste Strategie: vermeidbare Probleme tatsächlich... vermeiden! Da sind wir und einig.
test schrieb: > elder wise schrieb: >> Unter Windows kann das nun... überflüssigerweise aufwändig (?) werden >> den Fall zu untersuchen resp. die Ursachen dafür zu verstehen. > > Unter Linux Es gibt noch andere Quelloffene *ixoide Betriebs- & Dateisysteme. > genauso, das habe ich auch schon durch. Meine Erfahrung ist dass unter Linux/BSD/etc das Wissen länger anwendbar ist und weniger Ausnahmen (by Design, nicht by Bug denn Bugs gibt's überall) vorkommen. > Das Problem ist dann das die Software einfach mal so davon ausgeht das > das schon irgendwie klappt und eh niemand irgendwelche (erlaubten) > seltsamen Zeichen nutzt. M.M.n. ist hier nicht make.exe schuldig/ursache, sondern jenes Programm welches die Pfade "angelegt" hat. Ferndiagnostisch (alternativ: hellseherisch) behaupte ich dass beim Verzeichnis erstellen irgendeine API-Zwischenschicht eine kreative Transformation von [ [:SPACE:] ] o.Ä. ins Dateisystem geschrieben hat. Nun nützt es wenig wenn TO meint beim erstellen/editieren der (c)make-Regeln sei es mit drücken der Leertaste getan. Also: erst mal GRÜNDLICH untersuchen wie das Verzeichnis GENAU im Dateisystem heisst. Nein, nicht bloss mit DIR aus CMD.COM und auch nicht mit dem Dateiexplorer: diese lügen/schwindeln nähmlich öfter als mir lieb ist.
Ach ja, die hin und wieder unvorhersehbar ändernde Zeichencodierung in Dateisysteme aus dem Hause MS (ich nage da aktuell an etwas aus OneDrive...) ist auch so ein Sport. Je nach dem welche Windowsversion/Patchlevel ein bestimmtes (FAT-&NTFS-)Dateisystem anlegte resp. zu einem späteren Zeitpunkt Verzeichnis- & Dateinamen anlegt gibt es "Varianten" welche Zeichencodierung angewendet wird. Von 7/XP/NT usw. her up-gegradete Systemfestplatten sind wahre Fundgruben an solchen Sonderfälle... Werden Teile von solch gewachsenen Dateibestände von Serverversionen via SMB/CIFS oder eben auch OneDrive ins Netz ausgeteilt, potenzieren sich nochmals Varianten und Ausnahmen an Codierungskonversionen dazu. In keinem sich mir in den Weg gestellten Problemfall konnte je ein Windowsbefürworter/-Admin/-Kenner/-Experte eine Erklärung o.Ä. dazu ausgraben, auch nicht nach ein paar Tagen Recherche in MSDN & co. In jener Welt hat mich enttäuscht dass bei solchen und ähnlichen Vorkommnisse ich nichtmal von Leuten die ich zuvor bewunderte dann was dazulernen konnte. Hingegen in *nics-Kreisen komme ich aus solchen Situationen mehrheitlich mit erfreulichen "wieder was gelernt" Ergebnisse raus. Konsequenz: ich bleib da wo ich an den Herausforderungen wachsen kann UND weniger Frust habe.
elder wise schrieb: > Je nach dem welche Windowsversion/Patchlevel ein bestimmtes > (FAT-&NTFS-)Dateisystem anlegte resp. zu einem späteren Zeitpunkt > Verzeichnis- & Dateinamen anlegt gibt es "Varianten" welche > Zeichencodierung angewendet wird. Yepp, ... ... und auf welches Datum (epoch) sich denn ein Eintrag bezog. leo
test schrieb: > elder wise schrieb: >> Du hast dich für Windows entschieden also lebe mit seinen >> Inkonsequenzen. > > Du meinst mit kaputter Software. Wer Plattformübergreifend programieren > will muss es halt auch tun. Einfach dem Zielsystem die Schuld an den > eigenen Fehlern geben zählt nicht. > > Aber ich verstehe hier das Problem nicht. Was funktioniert denn nun > nicht? Gehts nur um die seltsame Anzeige? Nun, leb damit... Nein, er kann unter dem Pfad die Tools nicht finden. Habe dann jetzt erstmal meine PATH Variable verschmutzt. Python kommt mit dem Pfad auch nicht zurecht … habe einen ganzen Haufen an Varianten ausprobiert. Dazu kommt dann noch so ein BUG: https://bugs.launchpad.net/gcc-arm-embedded/+bug/1810274 manchmal nervts. Ich habe hier übrigens nicht nur WIN10 und WIN7 sondern als Primärsystem ein Debian 9. Das hilft aber nicht, wenn man Dinge auch an andere Leute verteilen muss, auf deren Zielsysteme ich keinen Einfluss nehmen kann bzw. welche zum Teil gar keine Linux-Distri verwenden dürfen.
Bei Whitespaces muss man das Problem meist nicht dort suchen wo er definiert wird, sondern dort wo er genutzt wird. Meist geht dort etwas schief oder es fehlen "" oder escaping.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.