Progress on LuaInterface/

47 views
Skip to first unread message

steve donovan

unread,
Mar 21, 2011, 10:31:44 AM3/21/11
to luafor...@googlegroups.com
Well, I've managed to get a build that will do the job. It still
involves the MS compiler for the bootstrap, since I can't get
LuaInterfaceLoader.cpp to build using GCC (appears that you would need
the SDK headers anyway). But, it's straightforward to built it against
LD's liblua51.dll, without any dreaded msvc100 dependency.

(Somebody with a more thorough grip of COM might persuade GCC to do
this, e.g. through ClrCreateManagedInstance)

The time-consuming task was understanding why the C# loader worked and
the C++ loaded didn't. The problem went away when I used the .NET
2.0.x csc compiler instead of the default .NET 4.0 version - targeting
.NET 2.0 should be good enough. If people need it, they can get the
assemblies from the upstream project.

Needless to say, this is going to be an entertaining project to
CMake-ify. It's a mixed-language project, the C++ is different and
the C# compiler is not the one provided by the Windows SDK.

steve d.

Peter Drahoš

unread,
Mar 21, 2011, 10:45:36 AM3/21/11
to luafor...@googlegroups.com, steve donovan
On Mon, Mar 21, 2011 at 3:31 PM, steve donovan <steve.j...@gmail.com> wrote:
The time-consuming task was understanding why the C# loader worked and
the C++ loaded didn't.  The problem went away when I used the .NET
2.0.x csc compiler instead of the default .NET 4.0 version - targeting
.NET 2.0 should be good enough.  If people need it, they can get the
assemblies from the upstream project.
This is great news. I considered this to be the most problematic module. 

Needless to say, this is going to be an entertaining project to
CMake-ify.  It's a mixed-language project, the C++ is different and
the C# compiler is not the one provided by the Windows SDK.
Worst case scenario we can call a batch file that builds it. But I dont see a problem using "add_custom_command" to build the mentioned file. Dependency on other compilers than MinGW should be avoided but if it builds from source its much better than using binary blobs someone else made. 

pd.

steve donovan

unread,
Mar 21, 2011, 12:20:49 PM3/21/11
to Peter Drahoš, luafor...@googlegroups.com
On Mon, Mar 21, 2011 at 4:45 PM, Peter Drahoš <dra...@gmail.com> wrote:
> a problem using "add_custom_command" to build the mentioned file. Dependency
> on other compilers than MinGW should be avoided but if it builds from source
> its much better than using binary blobs someone else made.

Exactly, no more odd custom build jobs!

I'm going to continue to see if gcc can do this. It's a slightly
esoteric subject, so Google does not directly produce solutions - it's
a case where one actually needs to understand how the CLR and COM
interact.

steve d.

David Manura

unread,
Mar 24, 2011, 10:50:42 AM3/24/11
to luafor...@googlegroups.com, steve donovan, Peter Drahoš
On Thu, Mar 24, 2011 at 4:11 AM, steve donovan
<steve.j...@gmail.com> wrote:
> For instance,
> LuaInterfaceLoader.cpp uses the MS-ism #import to pull in the COM
> interfaces for AppDomain, etc.  I could not find an explicit .idl file
> that defines these, which would be a necessary step for a mingw/etc
> build.

OLE/COM Object Viewer for Interface _AppDomain shows

TypeLib={BED7F4EA-1A96-11D2-8F08-00A0C9A6186D}
2.0=mscorlib.dll
win32=C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorlib.tlb
win64=C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorlib.tlb
BED7F4EA-1A96-11D2-8F08-00A0C9A6186D
2.4=mscorlib.dll
win32=C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.tlb
win64=C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorlib.tlb

If you File>View TypeLib... on one of those tlb files, it shows the
equivalent IDL.

[
odl,
uuid(05F696DC-2B29-3663-AD8B-C4389CF2A713),
version(1.0),
oleautomation,
custom(0F21F359-AB84-41E8-9A78-36D110E6D2F9, "System._AppDomain")

]
interface _AppDomain : IUnknown {
HRESULT _stdcall GetTypeInfoCount([out] unsigned long* pcTInfo);
HRESULT _stdcall GetTypeInfo(
[in] unsigned long iTInfo,
[in] unsigned long lcid,
[in] long ppTInfo);
....

But do you really need full the _AppDomain interface + type library,
or will IUnknown suffice? LuaInterfaceLoader.cpp looks quite simple.
I'm not familiar with the luainterface code though.

steve donovan

unread,
Mar 24, 2011, 12:26:49 PM3/24/11
to David Manura, luafor...@googlegroups.com
On Thu, Mar 24, 2011 at 4:50 PM, David Manura <dm....@math2.org> wrote:
> But do you really need full the _AppDomain interface + type library,
> or will IUnknown suffice?  LuaInterfaceLoader.cpp looks quite simple.
> I'm not familiar with the luainterface code though.

Thanks for the tips, David: my COM knowledge is somewhere between
rusty and rudimentary.

The rest of the project is pretty straightforward C# that uses
p/invoke to call the Lua DLL.

It would be very good to break the MS dependency because having a
project which has a dependency on a half-gig SDK is wasteful and
inelegant.

steve d.

Peter Drahoš

unread,
Aug 11, 2011, 3:15:03 PM8/11/11
to luafor...@googlegroups.com, Steve Donovan
Steve,
has there been any progress on this. Could you provide the final
binaries (without MS deps) that I can include. Source or how-to is
preferred of course.

pd

Reply all
Reply to author
Forward
0 new messages