Re: [DotGNU]Building the Qt# binding generator with cscc

[Adam Treat]

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