On 09/21/15 15:26, Stéphane Veyret wrote: >> EDK2 is not a library. It is a development kit. >> But EDK2 as a "whole" cannot be built. It is a development kit. > > Yes sorry, I don't use the correct vocabulary (actually I did this job > a few months ago and I need to recall what I did exactly ;-) ) > Right… What I meant was that I made an ebuild which installs the > development kit in a Gentoo machine. > >> What do you download? >> "UDK" is downloadable from sourceforge as a package; see eg. >> <http://www.tianocore.org/udk2014/>. "UDK2014 is a stable release of >> portions of the EDK II project." > > Yes, that's exactly what I actually download and install: UDK2014.SP1.P1. > >> But I don't know why Gentoo users would want that >> What is your excuse? :) > > Well, I simply wanted to write my own UEFI boot loader application (as > GRUB, ELILO, rEFInd, etc.) I first started to use gnu-efi which seems > to be more « adapted » to the linux world (meaning using only standard > linux toolchain) but I gave up because it was not maintained enough > for me (stable versions did not have latest developments on UEFI). I > then decided to use EDK2,
Good. :) > but then had 2 choices : either install it > in my home directory or install it as every other program in Gentoo. I > chose the second solution, which should make it easier to manipulate > now (meaning more classical) for Gentoo users. > For example, it should now be possible to compile rEFInd, while Gentoo > automatically installs EDK2 (or UDK2) as a build dependency. > > Is this clearer now? Sorry my english sometimes may not be as good as > it used to be (both for writing and understanding)… :-) It is clear now. You'd like to provide Gentoo users with an EDK2 -- as in, developer environment -- installation, saving them a "git clone". I don't know if the savings would be significant. Maybe if you have several users on the same computer developing modules for edk2 separately... I don't know. As far as I understand, at the moment you can "split off" only BaseTools from the main edk2 tree; that's why we have $WORKSPACE and $EDK_TOOLS_PATH. But, if you are developing modules for (or on top of) edk2, at the moment you have to keep them under $WORKSPACE. Which kinda dictates that most people have a git clone of edk2, with one (or several) feature branches off master, which are then periodically rebased (until the feature branch is applied; or, for proprietary forks, forever). Thus for now you are practically forced to develop your UEFI boot loader under the edk2 root directory (ie. $WORKSPACE). Fork off a git branch, create a new top-level package, with a .dec and a .dsc file. You don't need a .fdf file -- you won't build a flash image, and just for compiling a UEFI_APPLICATION type module, a .dsc suffices (with a subdirectory with an .INF file for the application itself). If you'd like to build / maintain the application *outside* of $WORKSPACE, that is something that has been looked into on the list for quite some time now. Many large vendors would like to use the same feature. I'm unsure about the latest status, but I think you'd be best off awaiting its completion, and packaging edk2 then. > So, do you think this is not the way I should have done it? How do you > see it? I think the goal and the "feature request" are valid, and they've been discussed on the list already. AIUI we don't have a solution yet. I think you should delay the packaging until upstream edk2 supports out-of-tree modules natively. Otherwise you risk build problems that your users can reasonably report to you only, and not on this list. Until then I think it's best to stick with personal git clones, or personal installations of UDK. > What was doing the Debian package you are talking about? That was about OVMF packaging. Initially Debian didn't ship the split files (OVMF_CODE.fd, and the varstore *template* OVMF_VARS.fd), just the unified file (OVMF.fd). The unified file is appropriate for ad-hoc command line testing, but not for long-lived and/or libvirt-managed guests. For the latter you want to be able to upgrade the firmware binary (OVMF_CODE.fd) and the varstore *template* (OVMF_VARS.fd) centrally on a host, without touching the *private* variable stores (with live non-volatile UEFI variables in them) that belong to existent virtual machines. This issue has recently been fixed in Debian though. Thanks Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
