[syslinux] [PATCH 0/4] efi: Makefile improvement

[Gene Cumm]

On Wed, Sep 16, 2015 at 10:55 AM, Erwan Velu via Syslinux
<syslinux at zytor.com> wrote:
> On mageia I'm using the following patch
> https://svnweb.mageia.org/packages/cauldron/syslinux/current/SOURCES/syslinux-nogit.patch?revision=600959&view=markup
>
>
> If it does solve your issue to, I could try pushing it into the repo.

Commit ID 0f8cbe04 was 8 months ago.  Thank you for your contribution.

-- 
-Gene

> 2015-09-16 8:44 GMT+02:00 Thomas Letan via Syslinux <syslinux at zytor.com>:
>
>> Hi.
>>
>> Sometimes, it may happen that we do not want to clone a repo (here the
>> submodule) and just use the version installed in the system. I have
>> myself one use case.
>>
>> Unfortunately, it is not possible to do that with syslinux AFAIK
>>
>> Thomas
>>
>> Le 15/09/2015 19:52, Celelibi via Syslinux a écrit :
>> > 2015-09-15 13:57 UTC+02:00, Patrick Masotta <masottaus at yahoo.com>:
>> >>>>>
>> >>  > What's the default strategy for checking out new gnu-efi sources?
>> >>  > We should have a way to set the version we want to work with
>> >>  > and only update when we want to do so.
>> >>
>> >>  That's true. All I did in these patches was to inline those shell
>> >>  scripts in the Makefiles, including the 'git submodule update --init'.
>> >>  So I didn't change any behavior in that regard. When you make directly
>> >>  or indirectly the targets efi32 or efi64, the submodule is checked out
>> >>  at the revision registered for the current syslinux commit.
>> >>
>> >>  Currently, if you want to checkout another revision of the submodule,
>> >>  you can checkout it, and 'git add' it (no need to make a commit) so
>> >>  that 'git submodule update --init' won't lose the revision you
>> carefully
>> >> checked out.
>> >>
>> >>  But it's true, there's something about it. Having the Makefiles depend
>> >>  on git is not a good idea as it doesn't allow to build from a sources
>> >>  tarball.
>> >>
>> >>  Another anoying thing is that 'git checkout' doesn't even try to
>> >>  checkout the submodule at the registered revision, which is a bit
>> >>  annoying. It's like you checkout a revision of syslinux and there's
>> >>  one file that never gets updated.
>> >>
>> >>  So I don't know what the right policy should be. What do you think
>> >>  about it? Ideally, there should be a config option so that 'git
>> >>  checkout' to also perform a 'git submodule update'. But I
>> >>  can't see any such thing.
>> >>
>> >>
>> >>  Celelibi
>> >>  <<<
>> >>
>> >>
>> >> How about
>> >> 1) Laying every needed versions of gnu-efi under its own directory where
>> >> its name could be just the version.
>> >> 2) Defining the gnu-efi version to use in a Makefile variable; if the
>> source
>> >> is not present then
>> >> the Makefile triggers the corresponding "check out" with git.
>> >>
>> >> The original tarball will contain (not check out needed )the source of
>> the
>> >> gnu-efi version used for the
>> >> corresponding build. But just changing a Makefile variable we would be
>> able
>> >> to build against the different
>> >> gnu-efi versions with 0 hassle.
>> >>
>> >> What do you guys think? Could this be done?
>> >
>> > Not sure I like the idea of accumulating the versions of gnu-efi.
>> > That'd make one submodule per version that has been used at some point
>> > in history.
>> > And when you work on it and want to just test several of versions of
>> > gnu-efi (that are not yet registered as submodule), that'd be annoying
>> > to have to patch the makefile and add a new submodule everytime. The
>> > submodule repository would have to be cloned from the network, which
>> > can be long.
>> >
>> > For the problem of the tarball sources, we could only perform the "git
>> > submodule update --init" if this is a git repository.
>> >
>> >
>> > Celelibi