Hallo, * Frank Liebelt [2004-03-11 13:01]:

...

aber, warum nimmst Du bei Qt-Projekten kein qmake? zum einen bietet das kdevelop auch, ist portabel und funktioniert, zum anderen sind die qmakefiles _sehr_ einfach von hand zu schreiben

Jetzt habe ich mir so eine .pro Datei geschrieben, aber der Fehler ist der selbe! Alle was QT Header ist wird nicht gefunden! Übrigens, KDevelop meckert genauso rum?

QTDIR gesetzt? [~] $ echo $QTDIR /usr/lib/qt3 [~] $ cat /etc/SuSE-release SuSE Linux 9.0 (i586) VERSION = 9.0 Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ "Wir sollten den Kosmos nicht mit den Augen des Rationalisierungsfachmanns betrachten. Verschwenderische Fülle gehört seit jeher zum Wesen der Natur." -- Wernher von Braun

Nachtrag :) leider macht Suse 9.0 da ein unset in einer KDE startdatei, deshalb wird es nicht gesetzt sein, es sei denn, Du änderst daran was Möglichkeiten: a/ in er .bashrc setzen oder b/ in dem opt/kde-tree suchen und in der Datei das unset auskommentieren Andreas

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi!

Irgendein Shell-Script werde ich da wohl noch zusammen bekommen.

Ich nehme alles zurück. Vieleicht sollte ich doch mal langsam schlafen gehen ;-) 36 Stunden ist ne lange Zeit :) Gruß Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAUI8XQdEg+G+HKLERApzyAKC1p2lByWMNDadPI5HQ3In+yI0NEACgvsUn /FqPvyGBGBMHOkW5VeI3cnI= =5zhf -----END PGP SIGNATURE-----

Hi, On Thu, 11 Mar 2004, Frank Liebelt wrote:

######################### libfile.o: libfile.c libfile.h define.h gcc -c -Wall -Werror libfile.c -g -o libfile.o

########################### SOURCES += libfile.c SOURCES += myapp.cpp

myapp.o: In function `MyApp::mk_file(file_ll*)': myapp.o(.text+0x1611): undefined reference to `_debug(char*, ...)'

Diese Fehlermeldung deutet darauf hin, das erwartet wird dass _debug() ne C++ funktion ist, i.e. in myapp.cpp ist sie nicht als 'extern "C"' deklariert.

_debug(char*, ... befindet sich übrigens in der libfile.o.

libfile.c wurde offenbar im ersten Versuch (wieso auch immer) mit nem C++ Compiler uebersetzt, so dass _debug() dann auch Tatsache so zur Verfuegung stand. Mit dem qmake File wird der Compiler aber offenbar korrekt gesetzt (i.e. C Compiler fuer .c file), damit ist _debug nur ne C Funktion (heisst also '_debug'), und wird deshalb nicht mehr unter dem Namen '_debug(char*,...)' gefunden. Der Fix ist wie gesagt diese Funktion in den Headern als 'extern "C"' zu markieren. Viel besser ist natuerlich wenn du gar nicht erst versuchst selber Makefiles zu schreiben, schon gar keine portablen. Es wird nicht gelingen, man macht dabei _immer_ Fehler. qmake ist ganz okay. Ciao, Micha.

* Andreas Loesch [2004-03-11 14:14]:

leider macht Suse 9.0 da ein unset in einer KDE startdatei, deshalb wird es nicht gesetzt sein, es sei denn, Du änderst daran was

Möglichkeiten: a/ in er .bashrc setzen oder b/ in dem opt/kde-tree suchen und in der Datei das unset auskommentieren

c/ kein KDE verwenden ;-) Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ Melchior FRANZ wrote: [Unsinn] -- Melchior Franz in suse-linux

Hallo, * Ralf Corsepius [2004-03-11 14:02]:

On Thu, 2004-03-11 at 12:09, Frank Liebelt wrote:

...

Da mir dieses automake Geschichte von KDevelop dermassen auf den Senkel geht habe ich mich nun entschlossen ein eigenes Makefile zu schreiben.

Eine kurzsichtige Entscheidung. Sie mag Dir kurzfristig weiterhelfen, langfristig wird sie Dir das Genick brechen.

wenn man in dem Projekt ausschließlich Qt verwendet ist qmake keine schlechte Wahl: geht schnell und man kann daraus auch MSVC++ Projektdateien generieren. LinCVS verwendet bspw. qmake, um mal ein größeres OpenSource-Projekt zu nennen. Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ Computer der Zukunft werden nicht mehr als 1,5 Tonnen wiegen. -- Die Zeitschrift »Populäre Mechanik« (1949)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi

...

...

Eine kurzsichtige Entscheidung. Sie mag Dir kurzfristig weiterhelfen, langfristig wird sie Dir das Genick brechen.

Meine (zugegeben launische) Anmerkung bezog sich darauf "eigene, händisch geschriebene" Makefiles statt "durch ein Tool generierte" Makefiles zu verwenden:

* Ab einer gewissen Projektgrösse werden "eigene Makefiles" in der Regel _schnell_ derart komplex, dass man praktisch keine Chance hat, diese Komplexität auch nur annähernd zu bewältigen.

* Sind mehrere Personen an einem Projekt beteiligt, werden "eigene Makefiles" auf längere Sicht nicht mehr handhabbar, da irgendwann der Zeitpunkt kommt, an dem sie niemand mehr versteht (Fluktuation, Komplexität). Tools (z.B. automake) erzwingen eine Systematik, die nicht auf dem Know-How eines Einzelnen beruht.

* Verwendet man Tools, erhält man als Seiteneffekt oft (Makefile/Projektkonfigurations-) Features, die ein Projekt momentan zwar nicht braucht, sich längerfristig aber auszahlen. In bez. auf automake ist dies z.B. Portabilität.

...

wenn man in dem Projekt ausschließlich Qt verwendet ist qmake keine schlechte Wahl:

Es ist zumindest ein Tool und damit "händisch geschriebenen" Makefiles überlegen.

Ob es mehr als eine Qt-spezifische, proprietäre Insellösung und "temporäre Erscheinung" ist, wird die Zukunft weisen müssen. Wie leistungsfähig es wirklich ist, kann ich nicht beurteilen, da ich noch nie den Bedarf gesehen habe, qmake verwenden zu wollen.

...

geht schnell und man kann daraus auch MSVC++ Projektdateien generieren. LinCVS verwendet bspw. qmake, um mal ein größeres OpenSource-Projekt zu nennen.

Das besagt nicht viel. Es gibt viele Beispiele für OpenSource-Projekte, die schlechte/unterentwickelte Tools verwenden, dass ich auf derartige Aussagen nichts mehr gebe.

Es kommt immer auf die Ziele, die Historie, die beteiligten Personen, deren Know-How und den Bedarf eines Projekte an. Alle Tools haben Vor- und Nachteile. Da machen automake, qmake, imake, metaconf, ant, MS-<irgendwas> und was es sonst noch alles gibt, keine Ausnahmen.

Ein Punkt bleibt: Nahezu jedes "Projekt/Buildscript/Makefile-Generierungstool" ist händisch geschriebenen Makefiles/Scripten _weit_ überlegen.

Ich lass mal den ganzen Text stehen. Sicherlich hasst Du recht. Kein Zweifel. Bei meiner OneManShow brauchte ich an soetwas aber weniger zu denken. Bis halt das Problem der Portabilität auftrat. Nun bin ich schlauer und werde wohl immer ein generiertes Makefile verwenden. Gruß Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAUU2vQdEg+G+HKLERAp2OAJ9TytLFOhPJQ8CDPeQUDGeYu0A+mACg3lEV TDs0qvCcEus/05XV2bP7WxU= =1FN+ -----END PGP SIGNATURE-----

On Fri, 2004-03-12 at 09:34, Andreas Loesch wrote:

Ralf Corsepius wrote:

...

Meine (zugegeben launische) Anmerkung bezog sich darauf "eigene, händisch geschriebene" Makefiles statt "durch ein Tool generierte" Makefiles zu verwenden:

im weitensten Sinn Ack (wobei ein verständnis für Makefiles nicht verkehrt ist und daher auch ein manuell geschriebenes zu Anfang helfen kann. Klar, man muss erst alle Fehler selbst erst einmal gemacht haben, bevor man den Sinn der Tools versteht.

...

* Ab einer gewissen Projektgrösse werden "eigene Makefiles" in der Regel _schnell_ derart komplex, dass man praktisch keine Chance hat, diese Komplexität auch nur annähernd zu bewältigen.

nicht unbedingt, man muss nur mehr Zeit investieren, ... extrem viel Zeit ... es bleibt schwierig, selbst wenn Portabilität keine Rolle spielt:

Beispiel: Die Linux-Kernel Makefiles. Portabilität spielt keine Rolle, reine gmake, nur Linux als Ziel-Plattform, 12 Jahre Entwicklungzeit, 10^x Entwicklern beteiligt, trotzdem bis einschliesslich 2.4.x doch nur bescheidene Qualität. Mit den 2.6er Kernel soll sich was verbessert haben, doch habe ich es mir noch nicht angesehen ;) Wenn Portabilität ins Spiel kommt, wird das ganze noch weitaus schwieriger.

aber dafür gibts ja die Tools ;) Man muss mit den Tools auch umgehen können (was nicht viele können), die Tools müssen gepflegt werden und die Quellen müssen gepflegt werden (was nicht viele tum).

Die meisten Leute scheinen von der Vorstellung "Einmal implementiert, Deckel zu" auszugehen, und zu vergessen, dass sich die Infrastruktur von Paketen ebenfalls weiterentwickelt.

...

* Verwendet man Tools, erhält man als Seiteneffekt oft (Makefile/Projektkonfigurations-) Features, die ein Projekt momentan zwar nicht braucht, sich längerfristig aber auszahlen. In bez. auf automake ist dies z.B. Portabilität.

NACK. Ich habe hier ein Beispiel vor mir liegen, ein C++-Projekt, ca 100.000 Zeilen Code und viele statische Libs und noch mehr Source und Headerfiles.

Die Masse ist nicht so entscheidend, auf die Komplexität der Konfiguration kommt es an.

Historie: das Programm wurde mit KDEStudio Gold gebastelt (autoconf/aufotmake) (Version weiss ich jetzt nicht auswendig, aber die 'ältere') und zum einen lässt es sich unter einer aktuellen Linux Distri (z.B. Suse 9 nicht erstellen!) und auch auf dem ursprünglichen Rechnerpark geht nix meht :( da wurde zwischenzeitlich autoconf/automake aktualisiert.... KDEStudio kenne ich nicht, doch sollte die Abhilfe einfach sein: Alte autoconf/automake's installiert und es sollte wieder tun.

Oder sollte es sich bei KDEStudio um einen Fall von Vaporware handeln, die nicht weiter gepflegt wird?

ich kann die Fehlermeldung jetzt nicht nachsehen, aber solltest Du einen guten Link haben, in dem die _manuelle_ Portierung der alten Autoconf/automake Dinger auf die neue Version beschrieben ist, würde ich um einen link bitten. Es ist relativ einfach: Neue autotools installieren, autoreconf -Wall starten und den Warnungen nachgehen.

Für configure-Scripte gäbe es noch autoupdate, das bei halbwegs sauberen und nicht zu komplexen Scripten recht gut funktioniert. Allerdings können sich die Details recht schwierig gestalten, insbesondere dann, wenn configure Scripte Interna alter autoconf Versionen verwenden (Davon gibt es leider zahlreiche).

[qmake]

...

Wie leistungsfähig es wirklich ist, kann ich nicht beurteilen, da ich noch nie den Bedarf gesehen habe, qmake verwenden zu wollen.

ich finde es _sehr_ gut, insbesondere da ich häufig MS/Linux Portabilität brauche und dafür auch Qt einsetze, Ich verwende weder Qt noch MS, dafür aber andere OSe.

als Alternative könnte man noch cmake ins Rennen schicken, da habe ich mit der vtk auch noch keine Probleme gehabt und ist ebenfalls sehr portabel. Noch'ne Insel ... Im Ernst, wir sind hier beim Thema "Proprietäre Lösung/Insellösung vs. Portabilität" gelandet.

Insellösungen haben immer im Augenblick Vorteile, ob Insellösungen aber langfristig tragen oder nur zeitweise Mode-Strömungen sind, weiss keiner. Die wirklichen Probleme entstehen dann, wenn eine Insellösung zur wirklichen Insel wird (Projekt gestoppt, Produktlinie beendet u.ä.). Ralf

On Fri, 2004-03-12 at 11:41, Andreas Loesch wrote:

Ralf Corsepius wrote:

...

KDEStudio kenne ich nicht, doch sollte die Abhilfe einfach sein: Alte autoconf/automake's installiert und es sollte wieder tun.

dann funktionieren 101 andere Sachen nicht mehr :( fällt leider aus Da muss einiges im Argen liegen. Die alten auto*tools unter einem Nicht-Standard-Prefix zu installieren sollte immer funktionieren.

...

Oder sollte es sich bei KDEStudio um einen Fall von Vaporware handeln, die nicht weiter gepflegt wird?

naja, für Version 3.3.5 schreiben Sie zwar * updated for autoconf 2.57, automake 1.7 aber der Erfolg ist IMHO nicht so gross :) Wenn sich die standard-projektfiles nicht übersetzen lassen....

Ergebnis :) KDEStudio wurde von uns in die Ecke geworfen, mit KDevelop3 wird man glücklicher, insbesondere da hier die qmake Unterstützung einbebaut ist. Das gleiche habe ich mit kdevelop gemacht ...

...

...

[qmake automake und portabilität]

...

könnte man noch cmake ins Rennen schicken, da habe ich mit der vtk auch noch keine Probleme gehabt und ist ebenfalls sehr portabel.

Noch'ne Insel ... Im Ernst, wir sind hier beim Thema "Proprietäre Lösung/Insellösung vs. Portabilität" gelandet.

Sorry, aber cmake (http://www.cmake.org/HTML/Index.html) ist genau so eine Opensource Insel, wie autoconf/automake.

Jein, momentan würde ich es als ein exotisches, wenig verbreites Tool einstufen, über das kaum Erfahrungswerte vorliegen, über dessen langfristige Perspektiven keine Aussage möglich ist und das scheinbar auf diskutablen Funktionsprinzipien basiert. Auch die Liste der Referenzanwendungen spricht nicht unbedingt für sich. Ähnliche Tools hat es schon viele gegeben, gibt es immer wieder und wird es immer wieder geben. Eine zeitlang waren GUI-basierte Projectbuilder in Mode, manche haben versucht Alternativen zu "make" zu etablieren, andere versuchten sich in "meta"-Prozessoren zu make, usw. usf. Bestand hatten bislang nur wenige, durchgesetzt haben sich noch wenigere. Interessant erscheinen mir im Moment ant (java) oder jam (boost/C++). Verwendet habe ich bislang allerdings noch keines dieser Tools, weil ich mit den autotools relativ gut auszukennen glaube und bislang keinen Bedarf hatte, mich nach Alternativen umzusehen. autoconf/automake sind weit verbreitet, seit langem im Gebrauch (ca. 10 Jahre) und GNU-Standard. Allerdings leiden beide an "Krankheiten", die ihren Ursprung in ihrer Historie haben und an Usern, die zwar kein Problem damit haben alle 1/4 Jahr oder noch öfters ihren Quellcode an die momentane Implementation eines GCC und die sich laufend änderenden APIs ihrer Toolkits anzupassen, gleichzeitig aber erwarten, dass aktuelle auto*tools kompatibel zu 3-4 Jahre alten Versionen sind ;)

Insbesondere: autoconf/automake läuft wunderbar auf Unixoiden Maschinen aber die Windows Unterstützung ist AFAIK nahe Null, evtl. mit cygwin aber sonst.... Mit Einschränkung gebe ich dir recht. Die Autotools setzen aber keine Unixoide Umgebung voraus, sondern eine POSIX-Laufzeitumgebung (+Perl). Da die Windows-Laufzeitumgebung alles andere als POSIX-konform ist, ist es nicht einfach die Autotools unter Windows zu verwenden. Nichtsdestotrotz scheint es zu gehen, vgl. z.B. http://www.coin3d.org/Coin/faq.php#Q1.5

Von anderen Personen wurde mir berichtet, dass sie autoconf/automake unter MinGW verwenden würden, wiederum andere verwenden autoconf/automake unter Cygwin als Entwicklungsumgebung um Win-Binaries zu erzeugen. Wiederum andere verwenden Cross-Entwicklungsumgebungen unter *nix um Binaries für Windows zu erzeugen (Zu diesen gehöre ich). Doch wo ist das Problem? Betrachte Cygwin als doch als Entwicklungsumgebung, genauso wie Du vermutlich Qt und/oder einen C++-Compiler unter Windows bzw. x*10MB KDE/Qt unter Linux installiert hast.

...

Insellösungen haben immer im Augenblick Vorteile, ob Insellösungen aber langfristig tragen oder nur zeitweise Mode-Strömungen sind, weiss keiner. Die wirklichen Probleme entstehen dann, wenn eine Insellösung zur wirklichen Insel wird (Projekt gestoppt, Produktlinie beendet u.ä.).

das Problem hast Du immer, egal, wohin Du blickst. makefiles sind wunderbar, wenn ich aber da eine Meta-Sprache drüberlege kommt es auf die Zielplattformen an, Das scheint mir der grundlegende Unterschied zwischen autoconf/automake und cmake zu sein.

autoconf/automake verwenden eine POSIX-Laufzeitumgebung (+perl) und eben keine "native" Laufzeitumgebung (Kein COMMAND.COM o.ä.). Bei cmake scheint das, wenn ich die FAQ richtig überflogen habe, anders zu sein.

autoconf/automake sind im Unix-Bereich _sehr_ weit verbreitet und die sind auch gut ausgreift keine Frage aber sind u.u. nicht die perfekte Wahl. Perfekt sind autoconf/automake weiss Gott nicht, aber die Resultate, die sie produzieren sind in einem Maß portabel, dass man in manuell geschriebenen Makefiles praktisch nicht realisieren kann - Damit fing es in diesem Thread doch an.

Ralf

Hallo, On Friday 12 March 2004 18:25, Andreas Loesch wrote:

Ralf Corsepius wrote:

...

Perfekt sind autoconf/automake weiss Gott nicht, aber die Resultate, die sie produzieren sind in einem Maß portabel, dass man in manuell geschriebenen Makefiles praktisch nicht realisieren kann - Damit fing es in diesem Thread doch an.

und so schliesst sich der Kreis ;) Du hast an sich recht, aber ich fahre bis jetzt mit den anderen Tools gut eine Portierung wäre immer noch möglich.

Der Nachteil des automake Dreisprungs bei Software, die als Source weitergegeben wird ist, dass Du dann bei Windows entweder eine Unix-Umgebung (cygwin o.ä.) installieren muss oder perl.

Es gibt von Microsoft auf deren Seite irgendwo eine Make-Variante von Microsoft [1], die angeblich zumindest irgendwie kompatibel funktioniert. Ich nehme mal an, dass sie kein Perl verwendet, aber weiß eben nicht, ob sie irgendwie sinnvoll geht. Ferdinand 1: ftp://ftp.microsoft.com/softlib/mslfiles/nmake15.exe

On Friday 12 March 2004 19:04, Ferdinand Ihringer wrote:

Es gibt von Microsoft auf deren Seite irgendwo eine Make-Variante von Microsoft [1], die angeblich zumindest irgendwie kompatibel funktioniert. Ich nehme mal an, dass sie kein Perl verwendet, aber weiß eben nicht, ob sie irgendwie sinnvoll geht.

Ja, aber wie bei jedem Make bringen einen die ganzen Abhängigkeiten um, wenn das Projekt nicht mehr trivial ist - wer weiß schon, welches seiner eigenen Include-Files von welcher Source direkt oder indirekt includiert wird? Das sollte man besser einer Automatik überlassen, die so etwas stumpfsinnig immer wieder automatisch feststellt. Alles andere ist viel zu fehlerträchtig. - alles schon gemacht und selber auf die Nase gefallen. ;-) CU -- Stefan Hundhammer Penguin by conviction. YaST2 Development SuSE Linux AG Nuernberg, Germany