[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: compiling trunk - KoView/QPointer, Kross/Python
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2006-12-19 18:55:46
Message-ID: 200612191955.46380.mail () dipe ! org
[Download RAW message or body]

Raphael Langerhorst wrote:
> Am Dienstag, 19. Dezember 2006 13:33 schrieb Sebastian Sauer:
>> > [100%] Building CXX object
>> > libs/kross/python/CMakeFiles/krosspython.dir/pythonextension.o
>> > /home/raphael/devel/KDE/trunk/koffice/libs/kross/python/pythonextension.c
>> >pp: In
>> >    member function `virtual Py::Object
>> >    Kross::PythonExtension::getattr(const char*)':
>> > /home/raphael/devel/KDE/trunk/koffice/libs/kross/python/pythonextension.c
>> >pp:203: error: parse
>> >    error before `.' token
>> >
>> > This is with NetBSD 3 (GCC 3.3.3) and Python 2.3.5 as well as latest
>> > qt-copy, kdelibs, etc. - on amd64
>>
>> That looks interessting. So, it is not possible to do something like
>> QString().arg(n) where n is a char* ?
> 
> I think you can. Qt would make a QString of the given char and use this as
> parameter to arg() (AFAICS) - char* is an acceptable parameter to the
> QString constructor so its internally constructing one and passes that to
> arg().
> 
> The above verbosity was meant to track down the actual call that doesn't
> work (in gcc error+line output), but in fact everything up there worked
> fine except that "string_data" was an unknown type (whatever). So my
> assumption is that the argument to Py::AttributeError is not a normal
> argument.

The ctor looks like;
AttributeError (const std::string& reason)

but imho that can't be the issue since it works for all other cases where it's 
used. Or does it break also at the other lines if you just comment the 
207+etc. lines out?
 
> If I use above code, I get the following output:
> 
> /home/raphael/devel/KDE/trunk/koffice/libs/kross/python/pythonextension.cpp:208:
> error: conflicting
>    types for `Py::AttributeError string_data'
> /home/raphael/devel/KDE/trunk/koffice/libs/kross/python/pythonextension.cpp:207:
> error: previous
>    declaration as `char*string_data'

hmmm... that sounds very wired.
 
> line 207 is: char* string_data = ba.data();
> line 208 is: Py::AttributeError( string_data );
> 
> so.... hmm... thinking about it I'm concluding that the parameter to
> Py::AttributeError is meant to be the variable name of the created
> AttributeError python object. Is this possible?

nope. Also there are not templates used. May it be possible, that it's needed 
to explicit link against STL ?

> In which case it is nonsense to put the error description there, right?
> What role has the variable name of such a python object? Ultimately: what
> should be the parameter to Py::AttributeError and similar things ?

It's just the error-string that is displayed.
 
> Does no one else have this compile error?

Could this be another buildsystem-prob just like we had just some days ago 
with the -ldl / ${CMAKE_DL_LIBS} in python/CMakeLists.txt ? It may an idea to 
try to remove the additional ${CMAKE_DL_LIBS}...

-- 
Sebastian Sauer aka dipesh[sebsauer]
http://www.dipe.org/public_key.asc
Fingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221
Coder in http://www.koffice.org && http://www.kmldonkey.org
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]