GNOME Bugzilla – Bug 321108
Qtools not Being Optimized
Last modified: 2009-08-15 18:40:50 UTC
Version details: 1.4.5-20051109 Distribution/Version: 2.6.12 Every time we go through a normal compilation of doxygen, qtools does not compile with optimize mode (-O2). I am still figuring out where in the configure script this error occurs. gmake[3]: Entering directory `/usr/src/redhat/BUILD/doxygen-1.4.5_20051109/qtools' g++ -c -pipe -DQT_NO_CODECS -DQT_LITE_UNICODE -Wall -W -fno-exceptions -g -I.././qtools -o ../objects/qbuffer.o .././qtools/qbuffer.cpp g++ -c -pipe -DQT_NO_CODECS -DQT_LITE_UNICODE -Wall -W -fno-exceptions -g -I.././qtools -o ../objects/qcollection.o .././qtools/qcollection.cpp g++ -c -pipe -DQT_NO_CODECS -DQT_LITE_UNICODE -Wall -W -fno-exceptions -g -I.././qtools -o ../objects/scstring.o .././qtools/scstring.cpp (and so on)
I don't see the problem (on MACOSX). It depends on the platform specific tmake.conf that is chosen to generate the makefile. Note that I had the same problem when trying your patch, only after a "make distclean" and a new "./configure" the correct tmake.conf was chosen and the options where correct...
Then why are we marking this bug as "needs info" when you can see that the problem does exist? Sounds like it's time to switch over to the GNU autotools, and I think many doxygen users would agreee :)
Hold on! I see the problem *only* when using *your* changes, so I don't have prove it existed before. Unless that prove does exist, I think that breaking the old mechanism is not a the proper argument for introducing another one. I hope you agree with that ;-) So even I'm not opposed to the introduction of GNU autotools, I do would like to have good arguments for making the switch, so we don't later on regret it.
I am marking this bug "resolved: invalid". I could not reproduce it with the unmodified sources of doxygen 1.4.5-20051109, so it had to be caused by my "modified" makefile and configure script changes.