Installing GLUEscript: why not to bother -- 2010-04

I've discovered GLUEscript (formerly wxJavaScript) another package based on Spidermonkey that sounds attractive.  True to form (for something based on Spidermonkey) it comes WITHOUT any hint of Installation-instructions.  And it outdoes the others by not even supplying a Makefile!  However, I've found some instructions here:; while they're for a specific distro of Linux they appear to be more generic than the naming indicates, and much of it should work on any Unix-like system. 

Installing Premake and Poco (from source) went smoothly, although compiling Poco took a while...  But then the next step is difficult as there is no one premake.lua file, but rather a premake4.lua file in most every sub-directory; and the src subdirectory also has files named linux.lua, modules4.lua, win.lua.  These latter files contain comments so one may be able to determine what one needs to revise.  Aha, the Premake-3.7 I've just installed won't do, seems I'll need version-4. 

The current version premake-4.2.1 fails to compile on my Fedora Linux system, when it tries to #include <mach-o/dyld.h> a Mac-OSX header-file, which means that something is going seriously wrong.  In src/host/lua-5.1.4/src/loadlib.c, LUA_DL_DLOPEN ought to be defined, and LUA_DL_DYLD ought not to be.  The immediate culprit is src/host/lua-5.1.4/src/luaconf.h, but there's an earlier problem since it means LUA_USE_MACOSX is defined and LUA_USE_LINUX isn't.  This package is broken: nowhere is LUA_USE_LINUX set and yet it is tested; this package can never work on Linux!  Indeed a glance at its Makefile (and Premake4.make) shows it can never work on anything other than OSX.  I got it from which states "the source code package...should build and run pretty much everywhere", then offers further "Building" instructions which consist of broken link, it invites problem-reports with another broken link, it asserts he'll be glad to help and provides a contact-me as yet another broken link!  (I did eventually find a way to contact the author, to tell him about the broken links.)

My next step was to try an older version of GLUEscript,, in the hope that it would work with the older premake that works.  Its src/build.txt has some advice on the troublesome nspr part, but it's not easily comprehended.  The paragraph causing me trouble reads: CODELITE on Linux: remove the nspr project because it has problems for assembly. Run premake with target gnu and run make in the nspr folder.  Aha, CODELITE is an alternative to Gnu-make, and since I'm using Gnu-make I can just ignore that obscure advice. 

I began revising src/linux.lua, but realized it was not going to work.  It contains comments such as "wx_cflags is the result of calling wx-config --cflags", and while I've got wxWidgets I have no wx-config, nor do I have anything at all close to other things I'm expected to have such as /usr/lib/wx/include/gtk2-unicode-release-2.8.  Jeez, using new-fangled tools like premake sure has a whole lot in common with the extremely primitive methods from long ago!  After grabbing a newer wxWidgets, and adding --enable-unicode to the configure, everything went smoothly; I now have a wx-config and seem a lot closer to getting somewhere.  Then I got back to revising src/linux.lua selecting 32-bit code, replacing many instances of "/usr/local" by "/usr"; complete list of revisions here

Running cd src; premake --target gnu seems fine.  Then running make gets:

jsautocfg.h:145:2: error: #error "This file is supposed to be auto-generated on UNIX platforms, but the"
jsautocfg.h:146:2: error: #error "static version for Mac and Windows platforms is being used."
jsautocfg.h:147:2: error: #error "Something's probably wrong with paths/headers/dependencies/Makefiles."
In other words, the included copy of Spidermonkey has been messed up and doesn't compile!  I'm unable to guess at what's meant by paths/headers/dependencies/Makefiles; there's nothing even close to that under src/js; aha, perhaps those slashes are to be read as "OR"s?  In file src/js/jscntxt.h, we read "On Unix-y systems, JS_STACK_GROWTH_DIRECTION is computed on the build host by jscpucfg.c and written into jsautocfg.h. The macro is hardcoded in jscpucfg.h on Windows and Mac systems (for historical reasons pre-dating autoconf usage)" which gives us a hint, however there's no file called jscpucfg.c and no attempt to generate jsautocfg.h. 

Next I considered using my previously compiled copy of Spidermonkey, however since it wasn't made with the THREADSAFE option I'll need to rebuild it, so may as well grab a new version.  The good news: while 2.5-years ago (in 2007-08) Spidermonkey was noteworthy for its complete lack of installation-instructions as I described at the time, it now provides perfectly decent instructions, and beginning with the soon-to-be-released v1.8.1 it will use the customary autoconf and configure tools.  The bad news: version 1.8.1 has been in "release candidate" status since 2009-03, ie: more than a year, and there's been nothing since then, which casts some doubt on the "coming-soon" status.  More bad news: you'll need to have exactly autoconf-2.13, nothing newer will work!  With autoconf's reliance on m4 macros it is less than obvious how to go about installing multiple versions of it (essential since other packages will insist on a newer autoconf), however the instructions at provide the answer.  Incidentally autoconf-2.13 is from 1999.

Starting Over:
Upon taking a look at how I'd gotten into this unsatisfactory state, I decided to take another stab at compiling premake-4.2.1.  In its file Premake4.make: replacing LUA_USE_MACOSX with LUA_USE_LINUX, and adding "-lm -ldl" to LIBS, will make his Makefile work (on a Linux system).  The install consists of: sudo cp bin/release/premake4 /usr/bin.  Whereas the earlier version of premake provided a man-page sadly this one does not; however premake4 --help provides basic usage info. 

Trying the current version of GLUEscript (0.1.01) again:
While revising its linux.lua, one notes that premake has improved in some ways, now having the ability to check multiple locations for the lib and include directories (to handle the "/usr/local" versus "/usr" and similar problems), and that feature has been used to remove some revision-needed cases, although far from all of them -- the author has very limited knowledge about the file-naming used in real-world Linux distributions for the packages he relies upon such as httpd (Apache); for curl_dir and curl_lib he's made no effort to use the new feature; overall the improvement leaves me underwhelmed. 

Running cd src; premake4 gmake (the name has changed and the options have changed dramatically), seems to work.  Then one does cd ../build/gmake/; make (how could anyone think that an improvement), to get exactly the same problem mentioned above; its copy of Spidermonkey is still broken in the same way.  Since I'm content to make something that runs on 32-bit Intel-386-compatible cpus the quick-and-dirty fix, editing src/js/jsautocfg.h to give XP_UNIX the same constants as for _WIN32, should suffice.  Rerunning make now produces:
make[1]: *** No rule to make target ../../lib/, needed by ../../bin/Debug/ Stop.
Jeez, has anyone other than me ever tried to install GLUEscript?  The solution is to edit build/gmake/js.make replacing "/lib/" with "/bin/Debug/".  The same revision is needed in other build/gmake/*make files, although a wholesale change-all won't do since some lib* files are actually being placed under lib, others under bin/Debug; turns out the revision is needed on all "../../lib/" occurences within all build/gmake/*make files.  The next problem:
/usr/bin/ld: cannot find -lPocoSpiderMonkeyd
is due to *make files being executed in the wrong order; the one producing libPocoSpiderMonkeyd hasn't been run when it's needed by the one producing  In other words, SpiderMonkey.make must be done before Core.make. 

Once again I wonder if it makes sense to go on -- the developer is obviously so far from finished that it's hard to imagine anything useful resulting from this exercise.  However having come this far...  I'm still keeping notes although that too makes little sense -- the developer Franky Braem must know he isn't finished, and hopefully also knows how to finish. 
Makefile: a reordering of projects that comes a lot closer to working:
  PROJECTS := nspr js zlib png jpg Common Script SpiderMonkey Core glue glue_data Expat SQLite Tpl MySQL GD MemCached Curl FCGI Net System WX Apache ApacheConnector
glue.make: LIBS line needs "-lnspr"
src/glue_data/module.h: the reference to GLUE/Core/ModuleInterface.h: possibly ../../src/Poco/Script/JavaScript/SpiderMonkey/include/Poco/Script/JavaScript/SpiderMonkey/ModuleInterface.h is intended?
That filename makes me shudder!  Can anything that mind-numbingly complex ever be made to work?  What sort of a mind would concoct such a thing?  At this point, I do give up and say uncle.  Please let me know when GLUESCRIPT becomes usable.  I won't be holding my breath. 

I've decided not to send an email to Franky Braem since I have nothing nice to say...  His page states:
GLUEscript 0.1.01 released
Submitted by webmaster on Thu, 03/25/2010 - 19:08 News
GLUEscript 0.1.01 is released. It solves two bugs: one with the error property of curl.Easy and one concerning the Array and Date object (which was also detected with using curl)

What sort of smoke-and-mirrors is this?  When he's not yet gotten rid of the compile-errors?