Bug 64103 - kdevelop 3.0.0a6 fails to compile (doctreeview/doctreeviewwidget.cpp)
Summary: kdevelop 3.0.0a6 fails to compile (doctreeview/doctreeviewwidget.cpp)
Status: RESOLVED NOT A BUG
Alias: None
Product: kdevelop
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KDevelop Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-09-12 00:14 UTC by Nicolai Haehnle
Modified: 2003-09-13 14:56 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolai Haehnle 2003-09-12 00:14:08 UTC
Version:            (using KDE KDE 3.1.3)
Installed from:    Compiled From Sources
Compiler:          gcc-3.3..2 
OS:          Linux

In doctreeview/doctreeviewwidget.cpp, line 766, QString is implicitly cast to (const char*):

            if ( (f = fopen(d.filePath(*it), "r")) != 0)

However, there's no appropriate casting operator available (I think that depends on the version of Qt or something; the fact remains that there are configurations without such an operator).
Comment 1 Amilcar do Carmo Lucas 2003-09-12 20:24:59 UTC
This in not a bug! 
This is a compilation error. 
 
Please: 
-Report bugs to the bug database (here) 
-Report compilation erros to the mailing list (not here) 
 
PS: How about providing you QT, autoconf and automake versions? 
Comment 2 Amilcar do Carmo Lucas 2003-09-13 14:56:25 UTC
> 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. 
 
 
 
> Well duh. 
I really needed that I code for you for free and you still complain about it! 
I really, really needed that! 
 
 
 
Comment 3 Nicolai Haehnle 2003-09-13 16:50:58 UTC
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@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-----