[Bug 64103] kdevelop 3.0.0a6 fails to compile (doctreeview/doctreeviewwidget.cpp)

[Nicolai Haehnle]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
     
http://bugs.kde.org/show_bug.cgi?id=64103     




------- Additional Comments From prefect_ at gmx.net  2003-09-13 16:50 -------
Subject: Re:  kdevelop 3.0.0a6 fails to compile (doctreeview/doctreeviewwidget.cpp)

On Saturday 13 September 2003 14:56, you wrote:
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
> http://bugs.kde.org/show_bug.cgi?id=64103
>
>
>
>
> ------- Additional Comments From a.lucas at tu-bs.de  2003-09-13 14:56
> -------
>
> > There's a part of the code that tries to access an (at least in some
> > configurations) non-existing function, and you call that not a bug?
> > Considering that in another programming language, this might actually
> > be a runtime error, it's kind of a stretch to call it "not a bug".
>
> I use KDE 3.1.3 , QT 3.1.2 and autoconf 2.57 just like you do.
> BUT I have automake 1.7.5 and gcc 2.95.3.
> There are developers that have tested gcc 3.2.x and 3.3.x in all their
> flavors and variations so gcc version is not an issue here. But your
> outdated automake version is. Have you used the trick that I recomended
> you in the other mail to bypass the need for an uptodate automake? If
> not, please do it and if the problem presists please update automake to
> 1.6.1 at least.

Again, this doesn't seem to have anything to do with the automake version. I 
checked out the latest CVS anyway, did a make -f Makefile.cvs (with 
automake updated to 1.6.3), and I get exactly the same results.

What it boils down to is this: configure sets -DQT_NO_ASCII_CAST, which 
masks the casting operator in qstring.h
I tracked QT_NO_ASCII_CAST down to admin/acinclude.m4.in, where it is set in 
the default KDE CXXFLAGS. There doesn't seem to be any part of the 
configure script that might undefine QT_NO_ASCII_CAST.

It's weird. Looks like there is no way QT_NO_ASCII_CAST could be unset in 
the configure script. Sure, compilation works on your end, but if 
- -DQT_NO_ASCII_CAST is set for you as well, the Qt headers must be different 
somehow. I can't think of a non-weird explanation for this.

However, grep QT_NO_ASCII_CAST ChangeLog suggests that previous changes have 
been made to support this condition. The rationale is probably that a 
simple cast cannot express which character set you want (plain old ASCII, 
UTF-8, whatever).

[snip potential flamewar ;) - my apologies if my earlier reply sounded too 
harsh]

cu,
Nicolai
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/YzMpsxPozBga0lwRAl+BAKDO0gPhE3+Jr3X7bCTVmOwmA1lOVACePLWm
qbS4bZJwlvsfUSvojlvpLVU=
=BObT
-----END PGP SIGNATURE-----