[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: luaconf.h patch for the Borland/CodeGear compiler
- From: "Eero Pajarre" <epajarre@...>
- Date: Thu, 15 May 2008 11:02:33 +0300
On Wed, May 14, 2008 at 3:20 PM, Terry Bayne <firstname.lastname@example.org> wrote:
> I also use the Borland compilers often for just this reason: creation of standalone executables. It makes distribution and installation a snap. While I do agree that shared DLLs save resources, the headaches caused by the versioning of DLLs I can live without.
I think it is possible to set Microsoft compilers to produce similar
results (assuming you don't
need to dynamically load lua modules.) I have compiled my static lua
wxLua (with wxWidgets) this way. The end result is a 6.5 Megabyte
monster (wxWidgets is
not too small..), but it does have quite a lot of functionality, and
does not require dll installation.
I ended up doing it this way, as the latter Microsoft compilers
started to require more complex
dll installation (not just placing the dll in the same directory as
the executable). And after
this a compiler update also updated the dll version so that new .exe
did not work with
the older dll.
> And sometimes it just makes sense. While doing some work with the Blackdog and K9 devices (an embedded linux server with a built in biometric reader for authentication), I had a need for a standalone executable, which at device boot time would be copied from the device to the host PC (and of course removed when the device was unplugged). Not having to also arrange for the copy and deletion of a bunch of support DLLs made this much simpler. The program itself acted as a SOAP server so that the device could send commands (usually Lua scripts to be executed on the host) to the host PC.
I am also doing something like this (network communication etc),
although the target devices has
my wxLua stuff "permanently installed". I also use the same wxLua
executable (just changing the Lua script)
as my installation driver program for the "server system".