Syslinux - Sep 2015 - [PATCH 0/4] efi: Makefile improvement

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

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
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>

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.

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
> > _______________________________________________
> > Syslinux mailing list
> > Submissions to Syslinux at zytor.com
> > Unsubscribe or set options at:
> > http://www.zytor.com/mailman/listinfo/syslinux
> >
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>

>>>
 > 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
 <<<

1) Gnu-efi sources are about 139 KB then I do not think it would be much of a
problem
having more than one submodule version under the Syslinux building tree. Also
the non-used
versions could be easily removed when invoking "#make spotless".

2) Cloning from the net shouldn't be that bad considering the involved
sizes, plus it is done
only once for every version.

3) Testing versions not registered as submodule yet could be easily done
w/o touching the makefiles just by i.e. overwriting the content of the last
version submodule
directory with the sources being tested.

4) I think this approach makes very easy testing different gnu-efi versions;
today doing this
is a real PITA.

Just my 2 cents.

Best,
Patrick

> >>>
>  > 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
>  <<<
> 
> 1) Gnu-efi sources are about 139 KB then I do not think it would be much of
a problem
> having more than one submodule version under the Syslinux building tree.
Also the non-used
> versions could be easily removed when invoking "#make spotless".
> 
> 2) Cloning from the net shouldn't be that bad considering the involved
sizes, plus it is done
> only once for every version.
> 
> 3) Testing versions not registered as submodule yet could be easily done
> w/o touching the makefiles just by i.e. overwriting the content of the last
version submodule
> directory with the sources being tested.
> 
> 4) I think this approach makes very easy testing different gnu-efi
versions; today doing this
> is a real PITA.
> 
> Just my 2 cents.
> 
> Best,
> Patrick
 
With all due respect, I have the feeling we might be putting too much 
effort / resources on the gnu-efi code used in Syslinux. I wouldn't 
even call this "my opinion", but if you would, then please add
"in my
very very very humble opinion".

Although I don't like the fact that we are currently based on an old 
(2014FEB) commit of the gnu-efi code:
 sf.net/p/gnu-efi/code/ci/ab54e2b40e914d0ca01dc3d44c8d4eb8517bf999

and although I also don't like the relative difficulty to change to 
another gnu-efi commit (emphasize on "commit", not
"version"), I would
tend to think that adding / replicating gnu-efi code is not much of a 
gain, while it would take already-limited resources.

I have read posts (here in the Syslinux Mailing List, and elsewhere) 
about this matter, such as not being able to use the gnu-efi code 
already installed on the system, or a different version/commit, or to 
avoid using git and to use some other format (such as a tar archive)... 
If we were to consider such comments / situations, adding an additional 
git repo or additional sub-directories would seem even worse under some 
perspective.

Considering that The Syslinux Project recommends, generally speaking, 
using official binaries, and considering also that reproducing certain 
behaviors would be more difficult if we were to be using different 
bases for the gnu-efi code, perhaps we should not be "easing" the 
possibility of changing such code (i.e. the gnu-efi commit on which 
Syslinux builds upon).

I would like to see, after "6.04-pre1" (whenever it would be 
appropriate and when the changelog deserves it) an update of the 
gnu-efi commit we are based on. Then we could see a "6.04-pre2", so we
can test any potential difference. Alternatively, a separated branch in 
git, updated in parallel to the master branch, with a newer gnu-efi 
commit as base (instead of using the old one from 2014FEB), for tests 
and comparisons, could be perhaps an option.

Regards,
Ady. 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>