lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


2008/9/3 Ross Berteig <Ross@cheshireeng.com>:
> Unfortunately, once you get into an open system where it is expected
> that other components just plug in, then everything that loads within
> a single process must comply with the same standards.

I'm assuming that standard for LuaRocks on Windows is MSVCRT80.DLL,
for the provided interpreter (LuaBinaries) as well as any precompiled
dll's in the default repository (is this true?). However:

> the off-the-shelf MinGW with -lmsvcrt80 gets you applications and
> DLLs that are *mostly* free of dependency on MSVCRT.DLL. Getting
> them completely free requires more effort.

What I understand from this, is that any rocks I install (compile)
using MinGW will either depend on an old VC6 runtime (MSVCRT.DLL), or
on *both* the old and the new one (MSVCRT80.DLL), depending on whether
or not by whatever magic the -lmsvcrt80 option is used. And if I use
Visual Studio, many rocks will not compile at all. So.... stop me if
I'm missing something, but basically my choices are:

1: Use Visual Studio and not a lot of rocks (i.e. forget about
LuaRocks and, where needed, "manually" port the modules I use to VS).

2: Use MinGW and two different C runtimes.

3: Go the cygwin route and effectively turn my development environment
(as well as whatever environment my projects should run on) into unix,
and (presumably) don't use LuaBinaries. This is assuming it solves the
problems of both options 1 and 2, though I don't know that it actually
does.

4? Realizing that LuaRocks has only recently hit version 1.0, wait for
some future version (of LuaRocks and/or some policy for inclusion of
rocks in the default repository) to somehow solve this? (what are my
chances here...?)

Just trying to gauge the situation.

Cheers