2015-09-14 14:15 UTC+02:00, Patrick Masotta <masottaus at yahoo.com>:>>>> > These few patches contain a few improvement about the > Makefiles for EFI. Mainly, to rebuild the files when needed, and only when > needed. The three shell scripts efi/{check,build,clean}-gnu-efi.sh > disappeared and > are now integrated as makefile recipes. > <<< > > 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
>>>> 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? Best, Patrick
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