The EDK was the previous build system. That is why the current one is called edk2.
On Mar 19, 2014, at 11:39 PM, Evgeny Yakovlev <insorei...@gmail.com> wrote: > Hello, > > We are developing a big commercial endpoint security system and recently > we've been doing a lot of UEFI development using EDK2. So far we've had some > problems with it that i want to share. > > The biggest issue we've had is the way we use EDK2 build system. > > Let's take a specific module for example - UEFI encrypted disk driver. To > build it with EDK2 we have an INF file for it and we do an NTFS junction into > EDK2 workspace to run build.exe. So far so good, but this module has a lot of > code in source files with data structure definitions and algorithms that is > shared with other modules, most of them not even pre-os. These shared sources > are not physically located inside the same folder as UEFI-only code. So when > we do an NTFS junction we can't reference those source in an INF file for the > driver since those will be outside EDK2 workspace and EDK2 doesn't like it. > So we either have to junction other stuff in or use "proxy" source files. > > It would've been so much easier if EDK2 allowed external references to > sources. As far as i know EDK2 build scripts go to great lengths to actually > deliberately catch out-of-tree references to sources, INF files, DSC file, > even include paths in compiler flags. Can anyone shed some light on _why_ is > it not allowed? > The EDK build system allowed modules to point to any random location for includes. The EDK source base also suffered from mixing public and private data in header files. What ended up happening was driver A would point its includes at driver Bs private includes and create a side effect. So changing drivers B implementation details could break driver A, and even moving driver B could break driver A. So in the edk2 we tried to make a strong distinction between public and private include paths. Thus packages declare the public include paths. I think the packages don’t let you point outside the workspace to prevent possible problems. This viewpoint is biased towards writing EFI drivers from EFI packages. If you are pulling in other source bases it does not work very well as you point out. With the current state of things you have two choices. 1) Remove the out of workspace check from the Python tools, I seem to remember this was not that hard to do. You can then create a package that points into your other code base. 2) Use compiler files directly. The DSC and INF files support [BuildOptions] settings and you can set a /I or -I or what ever. You can scope per toolchain family and specific toolchain as needed. Thanks, Andrew Fish > Evgeny. > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech_______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
