RE: [PATCH] Testing support for C++, without loader support, and for Windows

[Roger Leigh <rleigh@...>]

> -----Original Message-----
> From: bil til <biltil52@gmail.com>
>
> But such effort is not required, not a MUST... . (or what is your exact
> motivation to do such adaptions?)

(1) To validate that the Lua build is working correctly on Windows.  Doing so uncovered one defect in the defaults, as mentioned.  Ensuring correct failure behaviour is important to test and validate.
(2) To validate that the tests continue to pass when loader support is disabled
(3) To validate that the tests continue to pass when built with a C++ compiler

All three modes of operation are supported by the Lua codebase.  None of them are supported by the testsuite.  This patch adds the support to the testsuite to support them properly.

> You can implement such C code also directly in C++ if you want, in
> Microcontroller programming e. g. the Interrupt functions also quite typically
> are added as C code, where you then typically would just invoke some static
> C++ class function, to attach the interrupt to some class.
> 
> So generally it is no problem to add the C code to C++ software, just you have
> to use this "extern "C"{...};" constructs in the header files (see lua.hpp file).

Right.  But this is not related to the above.  How to correctly use Lua as a client library is entirely separate from validating that the *Lua build itself* is correctly conforming.

Related to the use of C++, while Lua does support building with C++ and throwing exceptions on error, the name mangling breaks module loading with dlopen and LoadLibrary.  This is one aspect of the testsuite which needs additional work--the interim strategy in my initial patch was to simply disable the module loading tests for this configuration, until the test modules are adapted to export unmangled symbols properly.


Kind regards,
Roger