[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DotGNU]Building the Qt# binding generator with cscc
From: |
Adam Treat |
Subject: |
Re: [DotGNU]Building the Qt# binding generator with cscc |
Date: |
Wed, 6 Nov 2002 18:36:51 -0500 |
User-agent: |
KMail/1.4.7 |
On Wednesday 06 November 2002 06:28 pm, Rhys Weatherley wrote:
> Adam Treat wrote:
> > On Wednesday 06 November 2002 03:20 pm, Adam Treat wrote:
> > > Ok, so another big step in support for Qt# is the binding generator.
> > > This is the result when I try and make the generator using cscc.
> >
> > Here is the result when I tell cscc to link against Mono's System.Xml :
>
> It may still be compiling against pnetlib's. In your previous
> message, I didn't see "-lSystem.Xml" on the command-line, which
> would explain why you got so many "X is not declared" messages.
> In cscc, "mscorlib.dll" is the only assembly that is included
> implicitly.
>
> In this one, "-lSystem.Xml" was present, but it isn't that easy.
> If both Mono and pnet are installed on the same system, then cscc
> is "smart" enough to use pnet's assemblies by preference, even if
> Mono's is on the link path first. Try copying Mono's "System.Xml"
> to "/usr/local/lib/cscc/lib" to replace pnet's, and then retry.
>
> Cheers,
>
> Rhys.
Ok, I made a backup of pnet's System.Xml and put mono's in
/usr/local/lib/cscc/lib and here is what I get:
address@hidden:~/dev/qtsharp/src/generator$ /usr/local/bin/cscc -o
./generator.exe -l System.Xml -O2 ./Converter.cs ./Generator.cs ./ParseAPI.cs
./Parser.cs ./Printer.cs ./QAncestor.cs ./QCtor.cs ./QDCtor.cs ./QEnum.cs
./QItem.cs ./QMember.cs ./QMethod.cs ./QParam.cs ./QType.cs ./QTypeMap.cs
unresolved type: [System]System.ComponentModel.DefaultValueAttribute
unresolved type: [System]System.CodeDom.CodeAttributeDeclarationCollection
unresolved type: [System]System.CodeDom.CodeNamespace
unresolved type: [System]System.CodeDom.CodeCompileUnit
unresolved type: [mscorlib]System.Reflection.AssemblyTitleAttribute
unresolved type: [mscorlib]System.Reflection.AssemblyDescriptionAttribute
unresolved type: [mscorlib]System.Reflection.AssemblyConfigurationAttribute
unresolved type: [mscorlib]System.Reflection.AssemblyCompanyAttribute
unresolved type: [mscorlib]System.Reflection.AssemblyProductAttribute
unresolved type: [mscorlib]System.Reflection.AssemblyCopyrightAttribute
unresolved type: [mscorlib]System.Reflection.AssemblyTrademarkAttribute
unresolved type: [mscorlib]System.Reflection.AssemblyCultureAttribute
unresolved type: [mscorlib]System.Reflection.AssemblyDelaySignAttribute
unresolved type: [mscorlib]System.Reflection.AssemblyKeyFileAttribute
unresolved type: [mscorlib]System.Reflection.AssemblyKeyNameAttribute
/usr/local/lib/cscc/lib/System.Xml.dll: unresolved external references
Looks like Mono's dll has some dependencies on corlib. I am going to try and
splice in some of Mono's source into pnet's System.Xml and see how far I get.
Question: what is the long term solution to this? Should we concentrate on
making a pnet version of System.Xml or use code from Mono where possible?
Another question: how do I get cvs commit access?
Update on some of the issues I'm seeing with cscc/qt# ... I can get ilrun to
execute a cscc generated scribblewindow, but only after commenting out some
of the menuing code. Not sure what the problem is, but I'll keep you
updated. I'll try and a get a backtrace on the segv upon exiting of all Qt#
apps for ya.
Rhys, with all this talk about Ruby and Treecc has got me real excited over
the possiblity of running a Qt#/Ruby application? (I'm woefully ignorant of
treecc) but is this a possiblitity in the future? From what I can gather
from your excellent docs, cscc will need a Ruby plugin. I am hoping that Qt#
might provide the impetus for the KDE developers to adopt Qt# as a multiple
language binding strategy (currently the kdebindings package is a horrible
mess). IMHO, having a Ruby -> IL compiler would really help (or Python &&
Perl for that matter). What do you think?
Adam