KDevelop und Source Tree
-
Hi,
unter Linux nutze ich KDevelop zur Entwicklung. Nun habe ich ein Projekt, welches zahlreiche (Unter-) Verzeichnisse umfasst, etwa so:src/ src/header.h src/main.cpp src/dir1 src/dir1/foo.cpp src/dir2 src/dir2/bar.cppWenn ich jetzt unter KDevelop (ich nutze Automake) die Dateien beim Automake Manager hinzufuege, meint der immer, er muesse fuer z.B. src/dir1/foo.cpp einen Link erstellen.
src/foo.cpp -> src/dir1/foo.cppNun bindet aber foo.cpp header.h ein:
#include "../header.h" // man beachte '../', da es ja eine Ebene hoeher liegtDer Compiler findet den Header nun natuerlich nicht mehr.
Wie kann man das umgehen? Helfen wuerde ja zum Beispiel eine Option beim gcc, damit er die Links erst verfolgt, aber sowas konnte ich nicht finden.
Weiss jemand Rat?Ich wuerde nur sehr ungerne in den Makefiles rumschreiben, dann kann (/muss) ich ja alles selber machen und kann mir gleich die IDE sparen
Gruss,
DeSoVoDaMu
-
das ganze geht am einfachsten so: du fügst über den automakemanger eine neues subproject hinzu, das dein unterverzeichnis repräsentiert und fügst dann da eine lib (static) als target hinzu, gegen die du die app dann linkst. das sollte in den meisten fällen das sein, was du ausdrücken willst.
-
#include "../x" lässt man auch am besten ganz sein und gibt stattdessen das Verzeichnis zum Include-Pfad dazu und macht nur noch include "x".
-
Danke fuer eure Antworten.
DrGreenthumb schrieb:
#include "../x" lässt man auch am besten ganz sein und gibt stattdessen das Verzeichnis zum Include-Pfad dazu und macht nur noch include "x".
Ist das so (also ich meine die Tatsache, dass man das so macht - moeglich waere es definitiv)? Das wuerde dann ja auch anders herum gelten, sprich Sachen wie
#include "dir1/header.h"waeren nicht mehr noetig.
Wenn ich mir aber zum Beispiel diverse code-snippets zu boost ansehe, fallen mir solche Sachen immer wieder aufboost schrieb:
#include <boost/detail/iterator.hpp>Gruß,
DeSoVoDaMu
-
DeSoVoDaMu schrieb:
Ist das so (also ich meine die Tatsache, dass man das so macht - moeglich waere es definitiv)? Das wuerde dann ja auch anders herum gelten, sprich Sachen wie
#include "dir1/header.h"waeren nicht mehr noetig.
sie wären nicht nötig. allerdings rate ich dir davon ab. wenn das projekt größer wird und man sich schon die mühe macht eine ordnerstruktur zu führen, sollte man dieses auch bei den inkluds kenntlich machen. sonst sucht man sich einen wolf nach der datei, die da inkludiert wurde.
hinzu kommt dann noch, dass man relativ schnell in verschiedenen unterprojekte zu ähnlich klingenden klassen kommen kannst und folglich auch ähnliche oder gar identisch benannte dateien hat. wenn man dann keine ordnerstruktur in den inkluds führt, ist es einfach nur noch unverständlich.
-
include <dir/x> ist kein Problem und durchaus üblich. Nur die Relativ-Angaben mit .. oder gar ../.. sind blöd. Die sagen nichts aus und sind unflexibel.
-
... hinzu kommt dann noch, dass man relativ schnell in verschiedenen unterprojekte zu ähnlich klingenden klassen kommen kannst und folglich auch ähnliche oder gar identisch benannte dateien hat. wenn man dann keine ordnerstruktur in den inkluds führt, ist es einfach nur noch unverständlich.
Das hinkt doch aber etwas. Wenn ich zwei Dateien foo.h (also mit gleichem Namen) in unterschiedlichen Verzeichnisen habe und dann einfach
#include "foo.h"in einer anderen Datei schreibe, tritt doch ein neues Problem auf, naemlich das es zwei zutreffende Dateien gibt.
Nichts desto trotz sehe ich euren Punkt (und letzteres trifft bei mir nicht zu). Danke fuer die Infos!
Gruß,
DeSoVoDaMu
-
DeSoVoDaMu schrieb:
Das hinkt doch aber etwas. Wenn ich zwei Dateien foo.h (also mit gleichem Namen) in unterschiedlichen Verzeichnisen habe und dann einfach
#include "foo.h"in einer anderen Datei schreibe, tritt doch ein neues Problem auf, naemlich das es zwei zutreffende Dateien gibt.
du hast das problem verstanden.
daher auch der hinweise: wenn du ordner nutzt, nutze die auch beim inkludieren.