Also bei einem Custom Makefile Project ist das ohne Problem möglich, indem ihr das File in $(PROJECTNAME).kdevelop.filelist eintragt. Hier ein Beispiel:
snorre c4dconverter # cat c4dconv.kdevelop.filelist
# KDevelop Custom Project File List
AUTHORS
c4dconv.kdevelop
ChangeLog
COPYING
Doxyfile
INSTALL
Makefile
NEWS
README
TODO
templates/cpp
templates/h
src/c4dconverter.cpp
src/n3d.cc
src/n3d.h
src/importxml.cc
src/modeldatastorage.cc
src/modeldatastorage.h
src/util.h
tinyxml/tinyxml.h
bin/c4dconv
src/importxml.cc
src/importxml.h
Ihr set es ja selbst - einfach den Relativen Pfad mit Filename. Und schon erscheint der Kram in der GUI, im Classbrowser, Doxygen docu &co
P.S. mach das aber wenn du das Projekt das du bearbeitest nicht geladen hast, sonst ist die Info über die neuen Files weg, denn Gideon schreibt seine Daten am Ende wieder dort rein.
Edit: Hö - da waren Zeilen drin, die gar nicht sein können - mpf
hi ihr,
ich habe das problem, dass ich einige archive (rar, zip, ace) habe, in denen dateinamen mit umlauten vorkommen.
da ich die dateien jedoch gerne verwenden würde, sie aber nicht entpacken kann, wüsste ich nun gerne, obs ne möglichkeit gibt, dateien schon im archiv umzubenennen, oder irgendwie zu sagen, dass er umlaute umwandeln soll...
wäre überaus dankbar wenn mir jemand helfen könnte
kompilier es neu auf der Maschine deines Freundes oder sorg dafür, dass die Librarys in den gleichen Verzeichnissen in gleichen Versionen vorliegen oder linke die Librarys statisch.
btw. kann ich alle nur davor warnen das Programm auszuführen, da man sich ja nie sicher sein kann (und wer hat schon lust auf nen Trojaner?)
sollte genau das gleiche sein.
Die Standard Distributionen unterscheiden sich ja eigentlich alle nur durch ein paar Grundkomponenten, wie verwendetes Packetsystem und Konfigurationstool und vorallem zwischen Mandrake (was von RedHat abgleitet ist) und RedHat, sollte es kaum Unterschiede geben.
ich habs mittlerweile auch gelöst. jetzt gibts komischerweise keinen speicherzugriffsfehler mehr, obwohl ich sonst keine Zeile Quellcode geändert habe.
Ähm,
$ for i in b?a ; do if [ "$i" = bla ]; then echo $i; fi; done
mit den üblichen Einschränkungen? Schöner fände ich Regexps und dann find(1) oder, wenn es mal ein richtiges Programm werden soll vielleicht awk.
(edit: Oder geht es nur um die Möglichkeit, daß es passt, dh es passt nicht wirklich auf eine reale Datei? Dann häßlich tricken: in einem Verzeichnis, wo man Schreibrechte hat ein 'touch bla' davor und ein 'rm bla' dahinter.)
Also ned wie erwartet bei eintritt in main ... sondern bei:
cout << ...
in _ostream.h
zeile 121
if(this->rdbuf())
...
beim flushen des buffers von basic_ofstream
da bekommt er SIGSEV ...
nehm mal an, irgendwas stimmt mit threading ned .... !?
Ciao ...
Hm... Ich möchte eine *.pro-Datei mit Hilfe eines Makefiles und dem GNU C++-Compiler Kompillieren...Was muss ich in das Makefile schreiben?
Erklärt am besten gleich den ganzen Vorgang!
Danke im Vorraus
z.B. Telnet oder SSH
Es gibt ein Protokoll indem festgelegt wird das der Client ein Passwort zu versenden hat.
Genau das musst du auch machen.
Du definierst ein Protokoll bzw. einen Ablauf wie sich der Client anzumelden hat.
TomDaHomm schrieb:
Ich bin aber trotzdem sehr überrascht. Der Compiler verweist auf Zeilen in main.cpp und der Fehler liegt aber in mycannonfield.h. Das ist doch total unlogisch.
Nicht wirklich. #include ist eine reine Textersetzung, d.h., an der Stelle, wo #include "blah.h" steht, fuegt der Praeprozessor den Inhalt der Datei blah.h ein. Und damit ist der Fehler dann auch in Deinem Hauptprogramm.
Wundert mich allerdings trotzdem, normalerweise ist der gcc so intelligent, BEIDE Dateien anzugeben... Vielleicht ist das Problem, dass der Fehler erst hinter dem Ende der Headerdatei erkannt werden kann.
ich würde einfach mal darauf tippen, dass hier
QListBoxItem* currentItem = this->trinken->selectedItem();
ein null-pointer zurückgegeben wird.
vielleicht ist garkein item ausgewählt!? oder die funktion ist fehlerhaft.
Da haben wirs ja. outputfile ist nicht initialisiert. Damit zeigt er unkontrolliert irgendwo in die Botanik, ausserhalb deiner Kontrolle. Mit strncpy kopierst du jetzt einen ganzen Haufen Zeichen an die Stelle, wo outputfile hinzeigt. Dass das nicht gut ist, sollte sich von selbst verstehen.
Wenn dein Programm an der Stelle abstürzt, heißt das nur, dass outputfile zufälligerweise an eine "verbotene" Stelle gezeigt hat.
Na schön, ich weiss jetzt was es war. Kurze Erklärung was los ist:
Der Compiler bekommt in dem Makefile, welches von qmake erstellt wurde folgenden Paramenter mit übergeben -I /usr/share/qt3/mkspecs/default (siehe oben). Nun ist diese Datei default ein Link auf default -> linux-g++. Also der Hinweis für qmake das als Compiler der g++ auf Lin benutzt wird.
Es existiert in /usr/share/qt3/mkspecs ein Verzeichnis namens linux-g++. In diesem Verzeichnis befindet sich ausserdem eine Datei, namens qmake.conf. In dieser Datei seht wiederum der Conf-Parameter:
QMAKE_INCDIR_QT = /usr/include/qt3/
Okay, den hab ich jetzt schon auf den richtigen Pfad angepasst. Dann geht's.
Das sieht mir mal wieder nach einer typischen Schlampenimplementation von den Debianfutzis aus. Die QT3-Dev files in /usr/include/qt3 gesteckt, wo sie natürlich, wie von TrollTech empfohlen, nicht reingehören, und dann die QT-DEV-Tools (enthalten qmake und moc) in /usr/share/qt3 installiert und die Confdatei falsch angepasst.
Daraus folgt: wieder einmal einen User mehr in den Wahnsinn geschickt.
Aber warum beschwer ich mich überhaupt ? Debian will doch nur die Welt verbessern und macht eben genauso wie Susi auch nur ihren eigenen DistriMist.
mfg
tom
du kannst doch einfach die Gtk::Textbuffer::get_text Funktion nehmen, den Text auslesen und via. std::wofstream in eine Datei schreiben (für UTF-8/16 Ausgabe müsstest du dir aber eigene Ausgabe Funktionen schreiben!)
http://www.gtkmm.org/gtkmm2/docs/reference/html/classGtk_1_1TextBuffer.html#a33