Qwt vs BCC32
Qwt is a wonderful set of widgets, useful for scientific applications. Since I've got a copy of new C++ GUI Programming with Qt book, I tried to give Qwt a try, using Non-Commercial edition. I've used Borland C++ compiler and faced with some errors, something about exception related with STL. Apparently this was discussed before. The solution was easy, I changed qwt.pro; the line win32:CONFIG += dll should be replaced by win32:CONFIG += dll stl exceptions. The problem has gone now, although I hit by another compile error which was due to semicolon after Q_PROPERTY in qwt_push_button.h. I simply removed that semicolons and my qwt.dll (and the correspoding qwt.lib) came into life. The same fix needed to be applied also to qwtplugin.pro, I just added new line win32:CONFIG += stl exceptions and everything was fine. I copied the new qwtplugin.dll to Qt Designer plugin directory and qwt.dll to Qt bin directory (or alternatively Windows System directory), launced Qt Designer, and those nice Qwt widgets were available, at my fingertip. Time to have fun now!
Another Birth
In the last days I was trying to move KYIM - a simple Yahoo! messenger client - from its home in Sourceforge to the new place in berlios.de. My past experience have shown that CVS service in Sourceforge was quite unstable, and even dog slow.
So I pulled all the files from Souceforge CVS and the did the casual 'cvs import' (I know I'd lost the revision history and friends, but I don't really care for that at the moment). This was performed nicely under my girlfriend's fresh Debian box, until I found out that I couldn't build KYIM CVS, either the Sourceforge or BerliOS version. CVS which has build error is bad, according to my experiences in KOffice. What made even worse was the fact that I have imported this broken version into BerliOS.
Nevermind, I thought. Let's just fix the problem. I found that it was simply an error because somehow 'make' trying hard to build something in autom4te.cache. Seems like the build system is damaged. Googling yielded nothing interesting. Messing around with autoconf and automake also didn't improve the situation. Replacing the admin directory and Makefile.cvs from clean KDE CVS had no effect. Perhaps the autotools in this machine weren't properly installed (yes, my first time using apt-get, synaptic and kynaptic).
Hours after that, I sat in front on my laptop running old Mandrake 9.1. In this system I have built many beasts, especially KDE 3.2 from source (using Konstruct). So I guessed I gave KYIM another try. This shouldn't be another shot in the dark because I knew I could compile many KDE applications already. But in fact, I still hit the same problem over and over again. This drove me crazy, also to the point that tinkering around with the build system probably would bring me nowhere. I am not expert at all in this area, doing so may reduce my sleeping hours even more.
Here comes the trick: I shall give KYIM a second birth. The actual idea was fairly foolish. First I made a very simple program, I have chosen the famous Qt-based Hello world! for this purpose. Once I could build it using KDE build system, I should replace the poor Hello world! program with the real KYIM. The necessary stuff like configure.in.in, admin/, Makefile.cvs, and such goodies can be taken from other KDE projects (arbritrary I took them from Kile). This trick worked flawlessly. The magical sequences of make -f Makefile, ./configure, make complained no more.
Of course, I suspect there is a good explanation of this problem. But either it is really trivial that I can't figure it out or simply I'm too dumb to handle such nasty complexity.
So, next time you face problem with build system, sometimes consider also to give another birth.
main()
This dpointer world will be filled by few exotic coding tricks, which I face day to day, and which start to inject my vein every now and then.