mikrocontroller.net

Forum: Compiler & IDEs cmake path with whitespaces and so on (Windows)


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Morgenfreude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Morgenfreude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: elder wise (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Du hast dich für Windows entschieden also lebe mit seinen 
Inkonsequenzen.

Autor: test (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: elder wise (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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!

Autor: test (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: elder wise (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: elder wise (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: leo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Morgenfreude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven S. (boldie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.