Summary:

I tried a simple and naive inclusion of the eLua source.  This was not successful.  More effort will be required.

Deets:

Encouraged with how trivially simple it was to integrate the canonical 5.3.4 source into my project, I tossed all that and attempted the same with the eLua source.  More precisely, I included the eLua's copy of the canonical Lua source in the same way.  This didn't work at all, there were other needed modules from elsewhere in the source tree.  That's not a complete surprise.

I took a look at the diff of the eLua 5.1.4 source and the canonical 5.1.4 source, and there are extensive modifications (presumably mostly embodying the so-called Lua Tiny RAM ('LTR') patch)  So I decided to defer studying that patch to see how to mod 5.3 for now.  I'll just settle for 5.1.x to get that running.

Remember how I was saying that I was hoping to not have to get into learning another build system, and just include the source directly?  Well, I can kiss that dream goodbye for several reasons:

1. There's generated code.  So I've got to understand the build system to understand what is being generated and put where.  So far at least it seems only to be generating some headers out of... stuff!  But I have to find all that stuff, wherever it is, and get it into my build system (i.e. 'System Workbench for STM32').  This is time-consuming and quite boring.
   
2. There's generated include and source paths.  It's a personal peev of mine when #include "xxx" means 'xxx is somewhere, you'll have to find it and add the path to your includes' as opposed to 'xxx includes an explicit relative path to this file' so I don't have to do that, and I don't have to reverse-engineer the build system to figure out where it is and where it is set.
   
   Anyway, maybe I'll bit the bullet and try to run the build system a little at least to make it emit the generated files, and carry on from that point.  The build system won't work to completion, of course, because the compiler toolchain is not visible to it.
   
3. The build system is 'scons', as per project documentation, which is based on python.  This is yet another 'make' replacement, apparently in the cmake tradition of puking out toolchain native project files based on some configuration.  I really am not in the mood to install python just to drive a build system.  Also, the documentation refers to some configuration that is contained in 'SConstruct', but I cannot find this file.  After rummaging through the source tree, I think I figured out why...
   
4. The build system is Lua, as per reality.  At some point, the developers may have come to a similar viewpoint regarding the python dependency, and they created their own (I think) build system based on Lua scripts.  I might have been nice to have updated the project documentation to that effect (e.g. on the page http://www.eluaproject.net/doc/v0.9/en_building.html[Building eLua]!)

OK, I like to kvetch.  Here's another one:  so, I build my Lua.  Then I install the package manager, LuaRocks.  So, I have to rebuild my Lua, and move it to some apparently conventional tree structure, then I install the package manager, LuaRocks.  OK, so I have to install Visual Studio and rebuild my Lua, and install it to an apparently conventional tree structure, then I install the package manager, LuaRocks.  OK, so I have to put a bunch of command-line overrides on the install.bat to LuaRocks, because for some reason it wants to deploy it's 'rocks' into c:\, and it's necessary to have the Visual Studio build environment setup before invoking the installer, and you need to tell it 'don't try to figure out what Visual Studio is installed, you won't do it right, anyway'.  Sweet Jesus!  But at length I have a presumably usable Lua, and I got it's rocks off 'luafilesystem', 'lpack', and 'md5'.

Now, from the cleverly named 'build_elua.lua' and handy comments within, I am able to try to invoke it.

Fail.  I have to fiddle with some environment variables, and have to non-intuitively (though perhaps obvious to an experienced Lua user), be sure to put two consecutive semicolons at the end of LUA_PATH, since that apparently means 'oh, also look for modules in the baked-in default locations'.  And then...

Fail.  "lua: .\utils\build.lua:3: attempt to call a nil value (global 'module')"  I am not sure what this is; I'm going to have to reverse engineer the build scripts.  I have a suspicion that this might be a garden-variety 5.1 vs 5.3 issue, though.  Yes, in retrospect, perhaps I should have built and installed 10-year-old version of Lua on the build system, instead of the current version, what with the old version also being the source for the build targets themselves.

Sigh.  Well, at least Lua proper is easy to build.  And I am now an expert getting the Lua Rocks off the Internets.  But this has been a whole day's work, and that does not make me happy.  But these are the vagaries of working with other people's code, and I'm sure the system has some charms I simply have failed to appreciate at this point....

Next:

More build system masochism.