OK. Let me paraphrase what I think you said in order to determine if I
understand the issues.
Goal:
Create a Linux distribution package (RPM, etc.) that, upon
installation, builds various UEFI modules
and installs them into the /boot partition, thus extending, updating,
or replacing UEFI boot files, drivers, or utilities.
Questions:
Would a setup like is done for Linux kernel modules work? The package
you install references a previously
installed "kernel_dev" package that has the necessary headers and
libraries. The whole kernel source tree
is not necessary but drivers, etc., can be built. (replace "kernel"
with "edk2" or "uefi" in solution)
Is the "Boot Manager" that you are developing a UEFI application like
elilo and grub are? (as opposed to
a Linux application manipulating the UEFI boot environment)
Restate:
So you, as a developer or software manufacturer, wish to be able to distribute
bits of UEFI firmware to be installed
from Linux into the EFI System partition (usually mounted as /boot or as a
child of /boot). To ensure platform
compatibility, the firmware would be built on the target system as part of the
installation process. It is unreasonable
to include the entire EDK II or UDK2010 source tree as part of the package. It
is desirable that the EDK II or UDK2010
source tree not be required; just necessary headers. The native Linux build
tools must be used to build the firmware.
It would be acceptable to also use tools installed as part of the "uefi-dev"
package that also provided the headers.
Am I correct or have I missed something?
A clear description of the problem and bounds of the solution set are necessary
first steps to solving the problem.
I would like to help you provide a strong argument for change or enhancement of
the current tools.
Daryl McDaniel
-----Original Message-----
From: Rod Smith [mailto:rodsm...@rodsbooks.com]
Sent: Friday, February 22, 2013 7:22 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Projects outside the edk directory structure
On 02/22/2013 01:22 PM, Mcdaniel, Daryl wrote:
> IMHO, the easiest way to build a package or module that is not in the
> WORKSPACE tree is to use symbolic links and the standard EDK II build
> system. Create a symbolic link to your package in the root of
> $WORKSPACE or a link to your module within the using package.
As I wrote when this topic came up three weeks ago, the approach you
suggest won't work when your goal is to create a program that's
compatible with inclusion in a Linux distribution. The issue is one of
the assumptions that the package systems (RPM, Debian packages, ebuilds,
etc.) make about where files go and what permissions they have. Placing
the source files for a specific package (rEFInd, in my case) within a
library's source directory (TianoCore's) simply cannot be guaranteed in
the build system -- at least, not as far as I know for the package
systems with which I'm familiar. Even dropping the files elsewhere and
creating symbolic links would be unreliable at best because of
permissions issues -- creating a symbolic link requires write access
within the TianoCore tree, but packages can be built by ordinary users
who might not have such access. Thus, a build process that does not
touch the library tree is a pre-requisite for building in a way that's
compatible with building as a Linux package. The only way I can think of
to build an EFI program in-tree with TianoCore using RPM is to include
the entire TianoCore tree as a patch to the main program, and that's
just plain ridiculous.
Of course, this specific reason doesn't apply to every project. If
you're writing an EFI driver for a hardware device and have no reason to
distribute it with Linux, you probably don't care about building Linux
packages, and that's fine. I, OTOH, was developing a boot manager that I
wanted to be easy to distribute with Linux, so using a Linux-friendly
build process was high on my list of priorities. Daniel Cardin, who
started this thread, hasn't said why he wants to build outside of the
TianoCore tree, or even what platform he's using, so it's hard to say
what approach would work best for him.
--
Rod Smith
rodsm...@rodsbooks.com
http://www.rodsbooks.com
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
