Re: [ANN] Lua for Windows v5.1.4.18 Released

["Andrew Wilson" <agrwagrw@...>]

"Is there anything I should know about the
project/compiler/linker/whatever settings to be compatible with LfW?"

Nope, nothing special, that I'm aware of, just use runtime library
that MSVC++ Visual Studio 2005 (MSVCRT8.dll) comes with.

Andrew



On Fri, Sep 12, 2008 at 3:10 PM, Mark Meijer <meijer78@gmail.com> wrote:
> 2008/9/12 Javier Guerra <javier@guerrag.com>:
>> On Fri, Sep 12, 2008 at 8:11 AM, Jerome Vuarand
>> <jerome.vuarand@gmail.com> wrote:
>>> I didn't know you were still maintaining your lua-tcc, the one linked
>>> by Mark above is my "fork" (it's not really a fork but rather a
>>> complete rewrite). Maybe we could merge both projects at some point.
>>
>> fact is i'm not.  i use it (a little), but haven't changed it a bit,
>> because of the stagnancy of TCC.
>>
>> if the new TCC can overcome that 'single environment, from now to the
>> end' [1] problem, it would warrant some redesign or our bindings.
>
> It's been a long while indeed between the current version of TCC and
> the previous one. I have no clue as to what's up with it, what's
> happening in the TCC community, or whether TCC should be considered
> "active" now or not. I'm not a regular user of it and I'm not at all
> involved with it. All I know from the changelog on their site is that
> there have been many fixes of long known bugs (including those that
> were previously fixed in a fork due to lack of updates).
>
> However, I have not encountered anything in the changelog that hints
> at Javier's "single environment" issue being improved at all. So there
> might be no cause for a major update of the bindings to lua, though I
> can't really say. Hopefully it's possible to simply replace the old
> TCC version with the new one and recompile with the bindings as-is,
> without any further fuss. I don't think there have been any
> significant changes in what passes for the TCC API ;)
>
>
> 2008/9/12 KHMan <keinhong@gmail.com>:
>> [...] IMHO, tcc is for people who
>> don't mind hitting a corner case and have the program blow up.
>
> Whether the new version of TCC is enough to alleviate these concerns,
> I honestly don't know. Many odd things have been fixed, but I wouldn't
> know how many more odd things remain (although I believe TCC has now
> completely caught up with, and gone beyond, the fork that fixed a
> bunch of things that some people apparently could not live with).
> Hopefully, any remaining corner cases may be a lot less significant in
> our case, i.e. when using it just for simple portions of "inline C" in
> a Lua app, as opposed to using it for compiling entire C projects as
> if it was a regular compiler (which it admittedly is not).
>
> In any case I think there is a lot to be said for being able to
> compile bits of "inline C" from Lua scripts, and execute them
> in-process. I don't know of any way to do this if not with TCC, so
> that's the main reason I mentioned it here. If there are other/better
> ways, that's fine too.
>
>> So let it be optional, and if LfW still want to package it, be sure to
>> disable it by default and add copious warnings.
> Warnings may or may not be appropriate, I honestly can't say but it's
> fine with me either way. But the way I see it, all modules are
> disabled by default, and enabling any of them requires (no pun
> intended) conscious choice and effort, in the general form of:
> require("blah"). Seems sufficient to me.
>
>
> 2008/9/12 Andrew Wilson <agrwagrw@gmail.com>:
>> [...] And so we can't add a lib until it's
>> been built in Visual Studio 2005. Which as you can tell is quite a bit
>> of  work considering how many c libraries are available for Lua.
>
> For what it's worth, I'll surely see what I can do if/when I happen to
> be fiddling around with any of 'em. Should I manage to produce any
> DLL's, I will certainly share them. I'm afraid I can't promise
> anything more than that, though. Is there anything I should know about
> the project/compiler/linker/whatever settings to be compatible with
> LfW?
>
> Cheers
>