Ein bißchen Ärger mit KDevelop

[axeljaeger]

Ich habe ein bißchen Ärger mit KDevelop 2.1.5, es sind während der Arbeit Probleme aufgetreten, die ich selber nicht lösen konnte:

1. Ich nutze libxmms in einem Projekt. Den Linkerflag kann ich auch gut in den Projektoptionen angeben, nicht aber die zusätzlichen Inlcudedirs. Die kann ich zwar bei CPPFLAGS, CXXFLAGS oder auch bei den CFLAGS eintragen, mein Programm kompiliert dann auch in der IDE, nicht aber, wenn ich einen Tarball mache und versuche, die Dateien mit dem configure-Skript und dem anschließend erstellten Makefile aufzurufen, weil KDevelop die C*FLAGS als Environmentvariablen in die Shell übergibt. Wenn man das Makefile aus einer normalen Konsole aufruft, werden diese Flags nicht gesetzt und es werden wie zu erwarten nicht alle includes gefunden.

2. Ein Bildschirmschoner hat bei KDE normalerweise die Endung .kss. Ich möchte die Sourcen eines Screensavers mit KDevelop verwalten. Das Projekt heist KGPS, die executable soll aber kgps.kss heißen. Ich sehe in den Projektoptionen keine Möglichkeit, das einzustellen. Wenn ich von Hand im Projectfile bin_program=kgps in bin_program=kgps.kss umändere, wirft KDevelop das wieder zurück. Auch ein Umbennen des Projektes in den Projektoptionen hilft nicht. Es auch nicht möglich, das Projekt gleich KGPS.kss zu nennen, weil im Projektassistent der Punkt (".") im Projektnamen nicht akzeptiert wird.

[peschmae]

Hallo,

ich kann dir leider auch nicht helfen.

Aber das sind zwei klassische Gründe wieso ich IDEs nicht so sehr mag. Die machen alles selbst und machen probleme, wenn man mal was selber machen möchte.

Versteht mich nicht falsch: Ich nutze auch Eclipse - ab einer gewissen Projektgrösse kommt man kaum um eine IDE herum - aber manchmal machen die Dinger wirklich Probleme

MfG Peschmä

[anda_skoa]

Original geschrieben von axeljaeger
1. Ich nutze libxmms in einem Projekt. Den Linkerflag kann ich auch gut in den Projektoptionen angeben, nicht aber die zusätzlichen Inlcudedirs. Die kann ich zwar bei CPPFLAGS, CXXFLAGS oder auch bei den CFLAGS eintragen, mein Programm kompiliert dann auch in der IDE, nicht aber, wenn ich einen Tarball mache und versuche, die Dateien mit dem configure-Skript und dem anschließend erstellten Makefile aufzurufen, weil KDevelop die C*FLAGS als Environmentvariablen in die Shell übergibt. Wenn man das Makefile aus einer normalen Konsole aufruft, werden diese Flags nicht gesetzt und es werden wie zu erwarten nicht alle includes gefunden.


Wie man die Configure Inputfiles entsprechend anpasst, um sie nach weiteren Bibliotheken suchen zu lassen, entzieht sicher leider meiner Kenntnis.
Eventuell wird das in einem autoconf/automake Tutorial behandelt.



2. Ein Bildschirmschoner hat bei KDE normalerweise die Endung .kss. Ich möchte die Sourcen eines Screensavers mit KDevelop verwalten. Das Projekt heist KGPS, die executable soll aber kgps.kss heißen. Ich sehe in den Projektoptionen keine Möglichkeit, das einzustellen. Wenn ich von Hand im Projectfile bin_program=kgps in bin_program=kgps.kss umändere, wirft KDevelop das wieder zurück. Auch ein Umbennen des Projektes in den Projektoptionen hilft nicht. Es auch nicht möglich, das Projekt gleich KGPS.kss zu nennen, weil im Projektassistent der Punkt (".") im Projektnamen nicht akzeptiert wird.

KDevelop3 hätte ein Projekttemplate für einen KDe Bildschirmschoner :)

Du kannst aber auch in den Projektoptionen das automatische Makefilehandling abschalten und die Makefile.am Dateien dann von Hand editieren.
Mache ich praktisch nach den Initial creates immer so.

Ciao,
_

[axeljaeger]

Ich wollte mir durch die Verwendung von KDevelop eigentlich das Einabeiten in Autoconf/Autoamek ersparen. Ich finde QMake ja ganz toll, leider kann ich da mit meinem xmms-config --cflags nichts anfangen. Außerdem finde ich es nicht angebracht, zu einem 50kb-Programm 1.9 MB Skripte zum kompilieren mitzuliefern.

[anda_skoa]

Original geschrieben von axeljaeger
Ich wollte mir durch die Verwendung von KDevelop eigentlich das Einabeiten in Autoconf/Autoamek ersparen.


Das automake Handling von KDevelop2 ist noch ziemlich simpel. Ich schätze mit dem Automakemanager von KDevelop3 geht da mehr.

Aber das händische anpassen sollte nicht so schwer sein, es müsste glaub ich mit Copy/Paste/Edit gehen.



Ich finde QMake ja ganz toll, leider kann ich da mit meinem xmms-config --cflags nichts anfangen.

Du kannst mit qmake Functions zB xmms-config auführen lassen, den Output in eine Datei schreiben und diese dann einlesen.



Außerdem finde ich es nicht angebracht, zu einem 50kb-Programm 1.9 MB Skripte zum kompilieren mitzuliefern.

Nunja, der Nachteil von automake/autoconf sind halt die zugehörigen Scripts.
Dafür gehts fast überall.
Außerdem halte ich 1.9MB für übertrieben, ca. 200-300KB sind das eher.

qmake ist da weniger flexibel, dafür braucht man dort nur die .pro Datei.

Ciao,
_

[axeljaeger]

Original geschrieben von anda_skoa
Das automake Handling von KDevelop2 ist noch ziemlich simpel. Ich schätze mit dem Automakemanager von KDevelop3 geht da mehr.

Aber das händische anpassen sollte nicht so schwer sein, es müsste glaub ich mit Copy/Paste/Edit gehen.



Ich hatte mir aus einem anderen Projekt, was die libxmms verwendet, die Makros in meine configure.in kopiert. Das ging auch, bis ich dann was am Projekt geändert habe und mir KDevelop alles wieder zerschossen hat


Original geschrieben von anda_skoa

Du kannst mit qmake Functions zB xmms-config auführen lassen, den Output in eine Datei schreiben und diese dann einlesen.

Das Problem ist: Man gibt in einem .pro-File die libs mit führendem -l an., Das heist, man kann auch linkerflags übergeben. Sowas wie xmms-config --libs wäre kein Problem. Mit Includedirs geht das nicht, weil man die dirs ohne vorrangestelltes -I angibt. QMake ergänzt das. Wenn ich da jetzt xmms-config --cflags einbaue, ernte ich sowas wie -I-I/usr/include


Original geschrieben von anda_skoa

Nunja, der Nachteil von automake/autoconf sind halt die zugehörigen Scripts.
Dafür gehts fast überall.
Außerdem halte ich 1.9MB für übertrieben, ca. 200-300KB sind das eher.


Naja, ich finde das mit den Skripten doch ziemlich aufgeblasen. Warum muss ich auch ein Makro schreiben, was manuell testet, ob xmms-config installiert ist? Wäre doch schön, wenn ich xmms in KDevelop bei Abhängigkeiten ankreuzen könnte. Es sollte nicht mein Problem, sondern das der libentwickler, das zu testen

[anda_skoa]

Original geschrieben von axeljaeger
Ich hatte mir aus einem anderen Projekt, was die libxmms verwendet, die Makros in meine configure.in kopiert. Das ging auch, bis ich dann was am Projekt geändert habe und mir KDevelop alles wieder zerschossen hat


Hattest du Makefilegeneration nicht abgeschaltet?



Das Problem ist: Man gibt in einem .pro-File die libs mit führendem -l an., Das heist, man kann auch linkerflags übergeben. Sowas wie xmms-config --libs wäre kein Problem. Mit Includedirs geht das nicht, weil man die dirs ohne vorrangestelltes -I angibt. QMake ergänzt das. Wenn ich da jetzt xmms-config --cflags einbaue, ernte ich sowas wie -I-I/usr/include


Hmm.
Man könnte natürlich im Script mit sed das -I wegfiltern.
Aber vielleicht geht es, wenn du den Output von xmms-config --cflags an eine der CFLAGS Variablen von qmake anhängst, QT_CFLAGS_MT zum Beispiel.



Naja, ich finde das mit den Skripten doch ziemlich aufgeblasen. Warum muss ich auch ein Makro schreiben, was manuell testet, ob xmms-config installiert ist?


Musst du nicht, du kannst es als Requirement angeben :)



Wäre doch schön, wenn ich xmms in KDevelop bei Abhängigkeiten ankreuzen könnte.


Klar wäre das schön, aber ich denke wenn es für jede mögliche Bibliothek eine Checkbox gäbe, wäre diese Dialogseite ziemlich groß. Gibt sicher tausende externe Bibliotheken.



Es sollte nicht mein Problem, sondern das der libentwickler, das zu testen

Da hast du vermutlich recht. Am besten du schreibst den XMMS Entwicklern, dass du gerne einen entsprechenden autocifng Check zum Download haben möchtest, bzw dass er im -devel Paket enthalten sein sollte.

Ciao,
_

[axeljaeger]

Original geschrieben von anda_skoa
Hattest du Makefilegeneration nicht abgeschaltet?


Nein, ich will ja nicht jede Datei einzeln eintragen

Original geschrieben von anda_skoa

Hmm.
Man könnte natürlich im Script mit sed das -I wegfiltern.
Aber vielleicht geht es, wenn du den Output von xmms-config --cflags an eine der CFLAGS Variablen von qmake anhängst, QT_CFLAGS_MT zum Beispiel.

Gute Idee, sollte ich mal ausprobieren

Original geschrieben von anda_skoa

Musst du nicht, du kannst es als Requirement angeben :)

Hab ich mir auch schon gedacht, auch das ich die Includedirs in das .pro hardcode. Ich glaub nicht, das es da so große Unterschiede zwischen den Distributionen gibt.

Original geschrieben von anda_skoa

Klar wäre das schön, aber ich denke wenn es für jede mögliche Bibliothek eine Checkbox gäbe, wäre diese Dialogseite ziemlich groß. Gibt sicher tausende externe Bibliotheken.

Naja, jede Bibliothek, die installiert ist, legt ein pkg-config-File an und KDevelop könnte sich diese Dateien ansehen. Leider muss ja wieder jeder sein eigenes Süppchen kochen. GTK, XMMS und SDL müssen ja unbedingt ein eigenes Programm für cflags und libs mitliefern.

Original geschrieben von anda_skoa

Da hast du vermutlich recht. Am besten du schreibst den XMMS Entwicklern, dass du gerne einen entsprechenden autocifng Check zum Download haben möchtest, bzw dass er im -devel Paket enthalten sein sollte.

Diesen Check habe ich schon auf der Platte, ich bin nur zu faul, den immer wieder selber reinzufummeln.

[axeljaeger]

So, ich hab das mal mit dem sed ausprobiert, aber irgendwie spinnt meint qmake, $$system wird nicht ausgewertet:



CONFIG += qt thread
SOURCES = main.cpp outpost.cpp outpostsetup.h
HEADERS = outpostsetup.h outpost.h
OUTPUT = outpost
INCLUDEPATH += $$system(xmms-config --cflags | sed s/-I//g)
LIBS += $$system(xmms-config --libs)
message(Includes $$INCLUDEPATH) # Interessanterweie wird $$system nicht ausgeführt
message(Libs $$LIBS) # Interessanterweie wird $$system nicht ausgeführt

[anda_skoa]

Bist du dir sicher, dass es du da $-Zeichen brauchst?

In den Beispielen der qmake Doku sind da keine.

Ciao,
_

[anda_skoa]

Original geschrieben von axeljaeger
Nein, ich will ja nicht jede Datei einzeln eintragen


Nunja, das ist einer der Kompromisse zwischen Selbstmachen und Generierenlassen.

Ich hab da halt lieber Kontrolle über die Files.

Der Autoconf Manager von KDevelop3 ist da aber eh flexibler.



Naja, jede Bibliothek, die installiert ist, legt ein pkg-config-File an und KDevelop könnte sich diese Dateien ansehen. Leider muss ja wieder jeder sein eigenes Süppchen kochen. GTK, XMMS und SDL müssen ja unbedingt ein eigenes Programm für cflags und libs mitliefern.

pkg-config ist noch ziemlich neu.
Das wird in der Zukunft sicher mehr eingesetzt werden.

Ciao,
_

[axeljaeger]

Original geschrieben von anda_skoa
Bist du dir sicher, dass es du da $-Zeichen brauchst?
In den Beispielen der qmake Doku sind da keine.


Doch, da sind welche: Such mal auf dieser Seite nach $$system
http://doc.trolltech.com/3.2/qmake-manual-6.html

Mit $$system kommt auf jeden Fall nur Unsinn raus. Auch mit Sed, da kommen dann so schöne sachen wie -Ixmms-config -I-cflags -I| -Ised usw.

Ich hoffe, pkg-config wird mehr genutzt, sonst haut man sich ja auch etliche zusätzliche Binarys in /usr/bin/*-config. Die Lösung mit Gerüst erstellen und dann editieren möchte ich eigentlich nicht machen. Wenn ich selber editieren muss, lass ich mir lieber ein sehr kompaktes Makefile von qmake bauen und mache dann von hand `xmms-config --cflags`rein.

Nach allem, was ich gehört habe, muss KDevelop 3 ja der Hammer sein. Ich hab es leider noch nicht getestet, aber ich denke mal mit:

Linux 2.6
KDE 3.2
Gideon

werd ich mir mal Debian auf 2 DVDs brennen lassen. Mandrake tue ich mir nicht nochmal an.