cmake path with whitespaces and so on (Windows)

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.