qtforum.de

Hallo,

ich bin Neuling in der Arbeit mit Qt und habe auch mit langer Webrecherche keine Lösung für diese Problem gefunden.

Ich möchte ein Project modular organisieren:

Jedes Modul hat einen eigenen Namespace, so daß Klassennamen mehrfach vorkommen können.

Wenn ich das Projekt mittels "qmake -project" aufsetzte, wird die Verzeichinshierarchie nicht berücksichtigt. Alle Objectdateien wandern in ein einziges Verzeichnis namens Debug oder Release.

Dabei überschreiben sich gleichnamige Klassen aus unterschiedlichen Modulen natürlich.

Gibt es eine Möglichkeit Qt beizubringen, anstatt mit einem flachen Kompilationsverzeichis mit einem hierarchischen zu arbeiten, das die hierarchie der Quellen abbildet, wie das der CDT Builder in Eclipse tut?

Vielen Dank für klevere Hilfe

1. gleiche Dateinamen sind nicht wirklich sinnvoll - wie Du selbst siehst. Also nenn sie einfach um und fertig.
2. qmake -project ist nur ein Hilfsmittel zum erstmaligen Erstellen der pro-Datei.

Christian81 hat geschrieben:1. gleiche Dateinamen sind nicht wirklich sinnvoll - wie Du selbst siehst. Also nenn sie einfach um und fertig.

Dafür wurden Namespaces eingeführt. Einheitliche Klassenbezeichnungen schaffen einheitliche Schnittstellen. Der Workaround mittels Prefixes ist eigentlich veraltet. So möchte ich ungern arbeiten, wenn es sich vermeiden läßt.

Christian81 hat geschrieben:2. qmake -project ist nur ein Hilfsmittel zum erstmaligen Erstellen der pro-Datei.

Richtig. Was ich suche ist aber eine sinvolle Lösung.

Grüße

Ich wüsste, außer die Klassen in einzelne Libs zu splitten, keine Möglichkeit - weder mit qmake, cmake oder direkt ein msvc-Projekt (ohne irgendwelche Hacks).

Christian81 hat geschrieben:Ich wüsste, außer die Klassen in einzelne Libs zu splitten, keine Möglichkeit - weder mit qmake, cmake oder direkt ein msvc-Projekt (ohne irgendwelche Hacks).

Das Splitten in einzelne Libs ist vielleicht die eleganteste Lösung und macht bei einem modularen Projektaufbau ja durchaus Sinn. Trotzdem bin ich verwundert, daß eine solche triviale Anforderung von diesen Tools nicht beherrscht wird.

Beim CDT Builder in Eclipse habe ich erlebt, daß er ganau das tut, was ich intuitiv erwarte. Dafür kennt er sich mit den Sonderseiten von Qt nicht aus, wie die Erzeugung der moc-Klassen. Wahrscheinlich könnte man ihn entsprechend konfigurieren. Dazu fehlt mir leider noch die Erfahrung.

Es ist auf jeden Fall gut von Dir eine Enschätzung zu bekommen, was geht und was nicht. Dann muß ich nicht in Sackgassen suchen.

Danke

Elmar

Wie gesagt - ich habe so eine Anforderung noch nie gesehen.

Christian81 hat geschrieben:Wie gesagt - ich habe so eine Anforderung noch nie gesehen.

Ich denke, das liegt an der Geschichte von C und C++. Da wurde sehr lange mit Prefixes gearbeitet. Das ist immer noch in den Köpfen und in vielen Werkzeugen. In Java würde man so etwas sicher nicht so erleben, weil die Sprache von vorneherein mit Namensräumen konzipiert wurde.

Wenn man in C++ die Namensräume parallel mit Prefixes abbilden muß, erhöht das den Aufwand und die Fehlermöglichkeiten. Aus Gründen des Pragmatismus setzt man Namensräume dann sicherlich eher spärlich ein.

Ich sehe wirklich keinen Unterschied ob ich jetzt #include "FileModule/Factory.h" und #include "HelpModule/Factory.h" schreiben muss oder ob ich ein Prefix oder was auch immer vor meinen Dateinamen bauen muss um sicherzugehen dass der richtige Header benutzt wird. Aber mir egal

Christian81 hat geschrieben:Ich sehe wirklich keinen Unterschied ob ich jetzt #include "FileModule/Factory.h" und #include "HelpModule/Factory.h" schreiben muss oder ob ich ein Prefix oder was auch immer vor meinen Dateinamen bauen muss um sicherzugehen dass der richtige Header benutzt wird. Aber mir egal

Wenn ich es mit Unterverzeichnissen organisiere, wird dieses Beispiel inklusive Prefix zu:

#include "HelpModule/HelpModule_Factory.h"

statt

#include "HelpModule/Factory.h"


Insofern ist da ein kleiner Unterschied. Dafür wird man, wie schon diskutiert, den Namespace fallen lassen, weil sonst die Unterscheidungskriterien redundant werden.