Hi, gibt es irgend welche Tricks, mit denen man unter Linux dafür sorgen kann, dass der gcc Dateien auch findet, wenn es Unterschiede in der Klein/Großschreibung gibt? Hab hier ein relativ großes SW-rojekt mit hunderten Dateien, in denen ich eigentlich nicht rumfuschen will. Leider stimmt bei einer Reihe von include-Anweisungen die Groß/Kleinschreibung nicht, da das Projekt nahezu ausschließlich unter Windows entwickelt/benutzt wird. Habt ihr da Ideen?
:
Verschoben durch Moderator
Man könnte wahrscheinlich mit symbolischen Links was tricksen. Aber ganz ehrlich wirst du auf Dauer nur dann Abhilfe schaffen können, wenn du die Window Leute sensibilisierst, dass sie auf Ihre Dateinamen aufpassen müssen und ihnen den Code konsequent wieder zurückschmeisst. Sind die Leute nicht greifbar, dann würd ich mir ein Tool schreiben, dass konsequent alle Textfiles durchgeht und alle auf einen #include folgenden Dateinamen in Kleinbuchstaben umwandelt. Bin zwar schon etwas aus der Übung, aber mit sed oder awk sollte das schnell machbar sein (Gut, ich würds in C schreiben, weil ich da schneller bin, als ich das awk manual finden würde, aber das ist eine andere Geschichte)
Vlad Tepesch schrieb: > gibt es irgend welche Tricks, mit denen man unter Linux dafür sorgen > kann, dass der gcc Dateien auch findet, wenn es Unterschiede in der > Klein/Großschreibung gibt? Die entsprechenden Dateien in einem VFAT-Dateisystem lagern sollte funktionieren. Hat halt auch Nachteile.
Karl Heinz schrieb: > Abhilfe schaffen können, wenn du die Window Leute sensibilisierst gehöre ja normalerweise auch dazu :) Karl Heinz schrieb: > Man könnte wahrscheinlich mit symbolischen Links was tricksen. Das hab ich tatsächlich für den Hauptfehler-Kandidaten auch getan. Karl Heinz schrieb: > würd ich mir ein Tool schreiben, > dass konsequent alle Textfiles durchgeht und alle auf einen #include > folgenden Dateinamen in Kleinbuchstaben umwandelt. das ist ja auch hässlich - und wie gesagt, ich würde die Sourcen ungern modifizieren. Problem ist, dass hier das VCS auch noch böse mitgespielt hat. Das erzeugt böse Probleme, wenn man Verzeichnisse umbenennt (also schon mit dem eingbauten Befehl, nicht einfach im File-System) und nur Groß/Kleinschreibung ändert. (dann ist das ganze Repo kaum noch zu gebrauchen) Normalerweise beginnen zB die Unterordner mit nem Großbchstaben, aber beim bei einem wurde es beim Anlegen/Einchecken vermasselt 'include/math' vs 'include/Math'. Die Includes halten sich aber teilweise an die vorherschende Namenskonvention, zumal es im src-Baum wieder richtig ist. Dank IDE-Unterstützung stimmen ja auch die meisten. Sind dann nur ein paar so subtile Dinge, wie ein großes D hinter Estimation3d, oder bei irgendwas mit Id. rmu schrieb: > Die entsprechenden Dateien in einem VFAT-Dateisystem lagern sollte > funktionieren. Hat halt auch Nachteile. sie lagern im Home-Verzeichnis - keine Ahnung wie ich da ein VFAT reinkriege :). Weiß auch nicht, ob der Rechner-besitze/Admin so glücklich wäre, wenn ich einfach das Dateisystem austausche.
:
Bearbeitet durch User
1) Alle .h Dateien umbenennen so dass nur Kleinbuchstaben verwendet werden. Dann in all den Dateien die #includes entsprechend ändern, mit einem Skript (sed, ask, perl, python) 2) Symlinks für alle Varianten von den -h-Dateien erstellen. Also für eine Datei "module.h": ln -s module.h Module.h ln -s module.h MODULE.h ln -s module.h MODULE.H usw, wie halt gebraucht wird
Vlad Tepesch schrieb: > Weiß auch nicht, ob der Rechner-besitze/Admin so glücklich wäre, wenn > ich einfach das Dateisystem austausche. Kannst ja ein Image mit VFAT mounten. ;-)
Jörg Wunsch schrieb: > Kannst ja ein Image mit VFAT mounten. ;-) wäre das ein Weg? wie darf man sich das vorstellen? Ich arbeite per ssh und smb vom nem Windowsrechner auf der Linux-Kiste und dh ich habe mein Home-Verzeichnis als Netzlaufwerk verbunden. Arbeite quasi wie ein normaler Mensch mit Windows :-P und mach nur was sein muss per ssh.
Vlad Tepesch schrieb: > Ich arbeite per ssh und smb vom nem Windowsrechner auf der Linux-Kiste > und dh ich habe mein Home-Verzeichnis als Netzlaufwerk verbunden. > Arbeite quasi wie ein normaler Mensch mit Windows :-P und mach nur was > sein muss per ssh. eventuell ist es dann einfacher gleich mit einen Cross-Compiler unter Windows zu kompilieren.
Peter II schrieb: > eventuell ist es dann einfacher gleich mit einen Cross-Compiler unter > Windows zu kompilieren. ich hab nen cross compiler, den ich auf der Linux-kiste benutze und ein Dev-Board, dass mit dieser verbunden ist und per NFS das Home-Verzeichnis eben jener mountet. kompliziert... dh ich schreib auf windows den Code, muss auf der linux-Kiste per ssh den code übersetzen und diesen dann per ssh auf dem dev-board ausführen ;). Der Windowsrechner greift per smb und das Target per NFS auf das Home-Verzeichnis der Linux-Kiste zu.
:
Bearbeitet durch User
Vlad Tepesch schrieb: >> Kannst ja ein Image mit VFAT mounten. ;-) > > wäre das ein Weg? wie darf man sich das vorstellen? Vorweg: root-Rechte brauchst du, zumindest einmal. Ansonsten so hier:
1 | $ dd if=/dev/zero of=foo.image bs=1024k count=100 |
2 | 100+0 records in |
3 | 100+0 records out |
4 | 104857600 bytes (105 MB) copied, 0,0512916 s, 2,0 GB/s |
5 | $ mkfs.vfat foo.image |
6 | mkfs.fat 3.0.26 (2014-03-07) |
7 | $ mkdir ~/mnt |
8 | $ sudo mount -t vfat foo.image ~/mnt |
9 | [sudo] password for jwunsch: |
10 | $ ls -l ~/mnt |
11 | total 0 |
12 | $ df -h |
13 | Filesystem Size Used Avail Use% Mounted on |
14 | [...] |
15 | /dev/loop0 100M 0 100M 0% /home/jwunsch/mnt |
Jetzt gibt's also unter $HOME/mnt ein separates Dateisystem von 100 MiB.
Vlad Tepesch schrieb: > Der Windowsrechner greift per smb und das Target per NFS auf das > Home-Verzeichnis der Linux-Kiste zu. das geht auch auf ein und derselben (Linux-) Kiste. Das Verzeichnis per Samba exportieren und dann wieder per cifs (woanders) mounten. Schon ist es case-insensitiv. Schneller wird's dadurch natürlich nicht.
Ich würde die Sourcen reparieren, ein für allemal, das ist doch kein Zustand so wie es ist. Wenn Du die Ordner nicht umbenennen willst dann änder halt jedes Auftreten des entsprechenden includes entsprechend um. Der Code steht unter Versionskontrolle, da kann also nix passieren, also was hindert Dich daran?
Bernd K. schrieb: > Ich würde die Sourcen reparieren Zumal sich das bisschen #include relativ einfach mit einer Scriptsprache der Wahl erschlagen lässt.
Bernd K. schrieb: > Ich würde die Sourcen reparieren, ein für allemal, das ist doch > kein Zustand so wie es ist. Wenn Du die Ordner nicht umbenennen willst > dann änder halt jedes Auftreten des entsprechenden includes entsprechend > um. > > Der Code steht unter Versionskontrolle, da kann also nix passieren, also > was hindert Dich daran? Wie gesagt, ich will das zeug nur benutzen, gehört aber zu einen anderen Projekt. Einfach ändern ist halt in Produktiv-Umgebungen nicht immer so einfach. Striktes Konfigurations- und Änderungsmanagement. Zumal ich auf einer festen Version bin und erst Branches anlegen lassen müsste Hab mir jetzt mit einem symlink und dem Rausschmeißen aus dem makefile von Teilen, die mich ärgern, ich aber nicht brauche, beholfen. Über kurz oder lang wird das aber natürlich richtig gefixt. Die vfat Sache werde ich mit auf jeden Fall merken, falls es schlimmere Probleme geben wird.
Bernd K. schrieb: > Wenn Du die Ordner nicht umbenennen willst dann > änder halt jedes Auftreten des entsprechenden includes entsprechend um. C-Autoren unter Windows machen Groß-Kleinschreibung in include abhängig vom Wochentag, von der Mondphase und vom Kaffesatz. Üblicherweise hat man also einen Mix von unterschiedlichen Groß-/Kleinschreibvarianten über das ganze Projekt. Mal include dir/meinheader.h, mal DIR/MEINHEADER.H, mal dir\MeinHeader.H, mal... Dir\meinHeader.H, ...
Johann L. schrieb: > C-Autoren unter Windows machen Groß-Kleinschreibung in include abhängig > vom Wochentag, von der Mondphase und vom Kaffesatz. Üblicherweise hat > man also einen Mix von unterschiedlichen Groß-/Kleinschreibvarianten > über das ganze Projekt. Mal include dir/meinheader.h, mal > DIR/MEINHEADER.H, mal dir\MeinHeader.H, mal... Dir\meinHeader.H, ... das stimmt doch nicht (zumindest nicht bei uns). in 99% der Fälle passt es ja. Die IDEs unterstützen einen mittlerweile ja auch mit Auto-Completion beim tippen der Includes. Da kommt dann normalerweise die richtige Schreibe raus. Ich hatte nur gehofft, dass es genau für den von dir genannten Fall, irgendwelche Kompatibilitäts-Optionen gibt, die man aktivieren kann, dass sich der Gcc beim Suchen nach Dateien etwas mehr Mühe gibt :-)
Vlad Tepesch schrieb: > dass sich der Gcc beim Suchen nach Dateien Der reicht das nur ans Betriebssystem weiter. Was auch sonst, soll er alle möglichen Permutationen aus Groß- und Kleinschreibung beim OS anfragen gehen, bevor er aufgibt?
Jörg Wunsch schrieb: > Der reicht das nur ans Betriebssystem weiter. Was auch sonst, soll > er alle möglichen Permutationen aus Groß- und Kleinschreibung beim > OS anfragen gehen, bevor er aufgibt? nö einfach ein 'find -iname' in allen include pfaden bemühen. (oder irgend was äquivalentes)
:
Bearbeitet durch User
Vlad Tepesch schrieb: > nö einfach ein 'find -iname' in allen include pfaden bemühen. O můj bože! Dann muss er jedes Verzeichnis durchgehen und jeden Dateinamen darin. Erstens wäre dann das entsprechende Backend nicht mehr betriebssystemunabhängig (mit fopen() durch alle Verzeichnisse gehen ist OS-unabhängig, aber Dinge wie opendir()/readdir() sind es nicht), zweitens ein immenser Aufwand nur für ein paar Trottel (sorry), die mit der Groß-/Kleinschreibung schlampig umgehen. C ist auch ansonsten case sensitive, ein C-Programmierer muss es daher eigentlich gewohnt sein, auf sowas zu achten. Warum wird er plötzlich schlampig, nur weil es sich gerade nicht um einen Bezeichner sondern um einen Dateinamen handelt?
Jörg Wunsch schrieb: > O můj bože! > > Dann muss er jedes Verzeichnis durchgehen und jeden Dateinamen > darin. naja ich hatte angenommen, dass im pattern auch Verzeichnisanteile stehen können. es gibt ja auch noch -[i]regex damit scheint es zu gehen man müsste vorher nur führende .. verarbeiten und von den Include-verzeichnissen abziehen. Jörg Wunsch schrieb: > zweitens ein immenser Aufwand nur für ein paar Trottel (sorry), > die mit der Groß-/Kleinschreibung schlampig umgehen. > > C ist auch ansonsten case sensitive, ein C-Programmierer muss es daher > eigentlich gewohnt sein, auf sowas zu achten. prinzipiell hast du da natürlich recht...
Jörg Wunsch schrieb: > Dann muss er jedes Verzeichnis durchgehen und jeden Dateinamen > darin. Ganz zu schweigen von den Fällen in denen mehrere verschiedene Dateien oder Verzeichnisse existieren die bis auf die Groß-Kleinschreibung identische Namen haben könnten.
Und dann noch... eigenes fopen.so schreiben und mit LD_PRELOAD in den gcc einbinden.
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.