Quote:
Originally Posted by geekmaster
Don't the kindles already have lua?  |
Some of it.
Buildroot can generate many of the add-ons for the Lua language.
In both cases, Lua-5.1.
Lua-5.2 was released last December but as of yet, very few Lua-5.1 packages have been ported to Lua-5.2.
Buildroot
2012.08-rc1 2012.08-rc2 is released for testing now, will become the official release (2012.08) by the end of the month.
Edit: That info was only good for two hours before the next -rc was released.
The Buildroot project is now merging (in branch buildroot-next) the things that will be included in Buildroot 2012.11 release.
Of more interest for 2012.11 than the six years worth of independently written Lua-5.1 packages to be ported is the ability of Buildroot to generate a native toolchain for the target machine.
Right now, it is still an "Open Question" on the BR M.L.
As it stands now:
Only when using the BR internally generated toolchain can BR generate a native target toolchain.
BR can only generate a uClibc based toolchain internally.
To generate (e)glibc based programs, BR must use one of the external toolchain options (crosstool-ng, user provided, etc).
BR, even when building its own, internally generated, toolchain has been a bit (no pun intended) flaky about doing a true "Canadian Cross" (google that) toolchain and more than a bit of bit-rot has accumulated.
None of the active developers are employed in an industry that requires the production of a native toolchain on the target.
So the open question is:
Should the bit-rotted ability of creating a native toolchain be pulled out of Buildroot or should it be fixed and extended to do true "Canadian Cross" toolchain builds?
Having someone volunteer to do the support of fixing what is there would sway the decision to be made for 2012.11.
Any reader here with an opinion and/or time on their hands to do the work should join the open BR mailing list and add to the discussion of this open question.
One of the things on the project's development plan is to replace BR's toolchain generation with an integration of crosstool-ng.
That integration has been done over the past year, so it is now time to settle this open question.
Since crosstool-ng never did, nor was intended to do, Canadian Cross toolchain builds. . .
Making it the only **internal** toolchain generator now (to complete the development plan's goal) would also mean dropping any ability to generate a native toolchain for the target.
My position on this open question is to be found on the BR mailing list.