Syslinux - Jan 2014 - [syslinux:firmware] version: Bump version & Lua

"H. Peter Anvin" <hpa at zytor.com> writes:
> On 12/11/2013 11:52 AM, Geert Stappers wrote:
>
>> Op 2013-12-11 om 02:09 schreef syslinux-bot for Matt Fleming:
>>
>>> Commit-ID:  5e59ac11d6d105591d6da742750ea2f804534d43
>>> Gitweb:    
http://www.syslinux.org/commit/5e59ac11d6d105591d6da742750ea2f804534d43
>>> Author:     Matt Fleming <matt.fleming at intel.com>
>>> AuthorDate: Wed, 11 Dec 2013 10:03:13 +0000
>>> Committer:  Matt Fleming <matt.fleming at intel.com>
>>> CommitDate: Wed, 11 Dec 2013 10:03:38 +0000
>>>
>>> version: Bump version
>>>
>>> We've now entered the 6.03 development cycle.
>>>
>> 
>> I have done a `git pull`, but can't see the new Lua version.
>> 
>> Is Lua 5.2.2 in 6.03?
>
> No, it still needs to be merged.
Shall I rebase it to the current firmware head?

Also, 5.2.3 was released a couple of days ago.  It's a bugfix release.
I made it into a sepearete commit (pushed).

Better default Lua paths (source and binary) would be useful.  Shall I
mirror the Syslinux PATH at initialization, or use some static value?

Also, header dependencies are not tracked, as no .*.d are generated
under the com32/lua directory.  Should they be enabled manually, or
should the MAKEDEPS flags propagate automatically?
-- 
Thanks,
Feri.

On 12/12/2013 12:31 AM, Ferenc Wagner wrote:
> 
> Shall I rebase it to the current firmware head?
> 
> Also, 5.2.3 was released a couple of days ago.  It's a bugfix release.
> I made it into a sepearete commit (pushed).
> 
> Better default Lua paths (source and binary) would be useful.  Shall I
> mirror the Syslinux PATH at initialization, or use some static value?
> 
> Also, header dependencies are not tracked, as no .*.d are generated
> under the com32/lua directory.  Should they be enabled manually, or
> should the MAKEDEPS flags propagate automatically?
> 
All of this sounds like a good idea.  As far as how to deal with
dependencies, it probably depends on which makes integration with
upstream Lua easiest.

	-hpa

"H. Peter Anvin" <hpa at zytor.com> writes:
> On 12/12/2013 12:31 AM, Ferenc Wagner wrote:
> 
>> Also, header dependencies are not tracked, as no .*.d are generated
>> under the com32/lua directory.  Should they be enabled manually, or
>> should the MAKEDEPS flags propagate automatically?
>
> As far as how to deal with dependencies, it probably depends on which
> makes integration with upstream Lua easiest.
We don't use a part of the upstream build system but replace
src/Makefile with our own and recurse into that.  So the contents of the
Makefile do not influence the complexity of integration, I guess.

On the other hand, now that the integration consists of several commits,
we could choose a "best" workflow for future Lua upgrades.  Like
branching off after the pristine import and cherry picking the
integration patches.  Or something else, I don't know what would make
the final merge relatively painless.
-- 
Regards,
Feri.

"H. Peter Anvin" <hpa at zytor.com> writes:
> On 12/12/2013 12:31 AM, Ferenc Wagner wrote:
> 
>> Shall I rebase it to the current firmware head?
>> 
>> Also, 5.2.3 was released a couple of days ago.  It's a bugfix
release.
>> I made it into a sepearete commit (pushed).
>> 
>> Better default Lua paths (source and binary) would be useful.  Shall I
>> mirror the Syslinux PATH at initialization [...] ?
>
> All of this sounds like a good idea.
I implemented them, but the EFI build problems keep getting in the
way...  Shall I push the rebased branch anyway?
-- 
Regards,
Feri.