Guten Tag erstmal (erster Post )
Wir sind gerade dabei eine Art Schulungssoftware unseres Profs von Windows nach Linux (Qt) zu portieren (hätte ihm bloß niemand erzählt, dass Linux mittlerweile auch nen Desktop hat><) - sei's drum wir müssen es ausbaden^^.
Wir haben uns als Buildsystem für cmake (wenn KDE/Qt es verwendet wird es für uns wohl auch ausreichend sein) entschieden (auch für eine komfortable Arbeit in KDevelop 4 wenn es denn mal läuft)
Der Qt-Port ist fast abgeschlossen aber wir können unter Linux aus folgendem Grund nicht richtig arbeiten:
Unser Programm verwendet Plugins. Wir haben jetzt erst mal ziemlich straight-forward das ganze Projekt zum kompilieren gebracht und es funktioniert tadellos - nur wir können nicht debuggen und das ist fatal.
Gehen wir mal von einer vereinfachten Projektstruktur aus:
root/hauptprogramm/CMakeLists.txt+Quellcode
root/CMakeLists.xt
root/plugin1/CMakeLists.txt+Quellcode
root/plugin2/CMakeLists.txt+Quellcode
Wenn wir jetzt das Programm kompilieren haben wir in root/hauptprogramm die hauptprogramm.exe (oder halt das Linux-Äquvivalent liegen)
in root/plugin1/ liegt nun plugin1.dll (oder .so) wie ihr wollt
in root/plugin2/ liegt plugin2.dll (oder .so unter Linux)
Damit die hauptprogramm.exe aber ihre Plugins laden kann müssen die alle in root/hauptprogramm liegen.
Unter Visual Studio haben wir das einfach über Projectsettings->Output Directory erledigt.
Wir könnten jetzt natürlich die Files einfach kopieren aber wir befürchten, dass dann KDevelop, oder die zugehörigen Quelltexte nicht finden kann etc.
Wir haben es nun über das INSTALL-Kommando geschafft in die richtigen Verzeichnisse zu bringen ABER: Wenn wir jetzt KDevelop auf das Projekt loslassen führt KDevelop nur make aus und nicht make install und startet dann den debug Vorgang - mit dem resultat dass unser hauptprogramm kein Plugin findet und wir neben einem Eintrag in unserem Logfile ("plugin xyz not found") ein leeres Qt Fenster haben.
Wie könnte man das mit der output directory mit cmake bewerkstelligen? Oder konkreter - welches cmake Kommando kommt dem Visual Studio "Output Directory" gleich?
Cu
[gelöst] cmake und KDevelop
-
- Beiträge: 7319
- Registriert: 26. August 2004 14:11
- Wohnort: Bremen
- Kontaktdaten:
Ok ich hasse es - 3 Tage rumprobiert und 5 Minuten nachdem ich diesen Post gemacht habe stolpere ich über die Lösung.
SET(LIBRARY_OUTPUT_PATH Verzeichnis in das ihr die Bibliothek haben wollt)
SET(EXECUTABLE_OUTPUT_PATH Verzeichnis in das ihr eure Exe files haben wollt)
Z.B.
Für eine static library
SET(LIBRARY_OUTPUT_PATH [verzeichnis in das die bibliothek rein soll])
ADD_LIBRARY(Core ${myFiles})
Dann für eine dll
SET(LIBRARY_OUTPUT_PATH [verzeichnis in das die bibliothek rein soll])
ADD_LIBRARY(Plugin1 MODULE ${myFiles})
Und dann für den executable
SET(EXECUTABLE_OUTPUT_PATH verzeichnis in das der executable rein soll)
ADD_EXECUTABLE(Main ${myFiles})
Und cmake verteilt die Files ganz brav in die Ordner in die ihr sie haben wollt (funktioniert für VC Projekte (kann nur von für VC8 sprechen und für Linux makefiles).
Und warum der ganze Ärger? Wegen der absolut "§$%$>< Dokumentation.
cmake my day...
Lol danke für die Antwort aber ich habe es nach 5 Minuten nachdem ich den absenden Knopf gedrückt habe gefunden.>< Thread vielleicht löschen und wenn ihr keine cmake faq oder sowas habt oder eine Liste der Befehle in eurem Forum - macht besser eine sonst kommen solche Fragen immer wieder^^
Sry nochmal und schönen Tag nach
SET(LIBRARY_OUTPUT_PATH Verzeichnis in das ihr die Bibliothek haben wollt)
SET(EXECUTABLE_OUTPUT_PATH Verzeichnis in das ihr eure Exe files haben wollt)
Z.B.
Für eine static library
SET(LIBRARY_OUTPUT_PATH [verzeichnis in das die bibliothek rein soll])
ADD_LIBRARY(Core ${myFiles})
Dann für eine dll
SET(LIBRARY_OUTPUT_PATH [verzeichnis in das die bibliothek rein soll])
ADD_LIBRARY(Plugin1 MODULE ${myFiles})
Und dann für den executable
SET(EXECUTABLE_OUTPUT_PATH verzeichnis in das der executable rein soll)
ADD_EXECUTABLE(Main ${myFiles})
Und cmake verteilt die Files ganz brav in die Ordner in die ihr sie haben wollt (funktioniert für VC Projekte (kann nur von für VC8 sprechen und für Linux makefiles).
Und warum der ganze Ärger? Wegen der absolut "§$%$>< Dokumentation.
cmake my day...
Lol danke für die Antwort aber ich habe es nach 5 Minuten nachdem ich den absenden Knopf gedrückt habe gefunden.>< Thread vielleicht löschen und wenn ihr keine cmake faq oder sowas habt oder eine Liste der Befehle in eurem Forum - macht besser eine sonst kommen solche Fragen immer wieder^^
Sry nochmal und schönen Tag nach
-
- Beiträge: 7319
- Registriert: 26. August 2004 14:11
- Wohnort: Bremen
- Kontaktdaten:
Der Thread ist zwar schon sehr alt, aber passt so schön zu meinem Problem:
Und zwar bekomme ich unter Windows mit CMake in der Visual Studio Projektmappe bei der Angabe des Outputfiles immer noch die Konfiguration dran gehängt.
Also z.B.
Binaries\Windows\Debug\Sample.exe
statt
Binaries\Windows\Sample.exe
Weiß jemand woran das liegt? Die EXECUTABLE_OUTPUT_PATH Variable wurde durch
gesetzt.
Das ganze tritt nur unter Windows auf, sowohl mit CMake 2.4.8 als auch mit CMake 2.6
Und zwar bekomme ich unter Windows mit CMake in der Visual Studio Projektmappe bei der Angabe des Outputfiles immer noch die Konfiguration dran gehängt.
Also z.B.
Binaries\Windows\Debug\Sample.exe
statt
Binaries\Windows\Sample.exe
Weiß jemand woran das liegt? Die EXECUTABLE_OUTPUT_PATH Variable wurde durch
Code: Alles auswählen
SET(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/Binaries/${CMAKE_SYSTEM_NAME}
Das ganze tritt nur unter Windows auf, sowohl mit CMake 2.4.8 als auch mit CMake 2.6
Bitte seid so nett und ändert den Titel von Beiträgen die gelöst wurden, auf [gelöst] Beitragstitel
-
- Beiträge: 7319
- Registriert: 26. August 2004 14:11
- Wohnort: Bremen
- Kontaktdaten:
Das ist so eingebaut weil MSVC das normalerweise auch so macht.
Aber es gibt einen 'offiziellen' Hack
Aber es gibt einen 'offiziellen' Hack
Code: Alles auswählen
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES PREFIX "../")
MfG Christian
'Funktioniert nicht' ist keine Fehlerbeschreibung
'Funktioniert nicht' ist keine Fehlerbeschreibung