Hello,
Here are some observations I've encountered trying to utilize edk2 for
certain builds. Part of the problem seems to be with implicit
assumptions in how edk2 is used. I'm trying to build things using edk2
from a clean enviroment on an automated builder. i.e. there isn't a
workspace that exists on one persons computer for the lifetime of
development.
1. BaseTools can't build in parallel. The tests are racey which result
in test failures. Because of this one has to build these in serial
instead of in parallel.
======================================================================
FAIL: testHelp (TianoCompress.Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/build/zoombini/tmp/portage/sys-boot/fsp-cnl-9999/work/fsp-cnl-9999/Edk2/BaseTools/Tests/TianoCompress.py",
line 34, in testHelp
self.assertTrue(result == 0)
AssertionError: False is not true
======================================================================
FAIL: testRandomDataCycles (TianoCompress.Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/build/zoombini/tmp/portage/sys-boot/fsp-cnl-9999/work/fsp-cnl-9999/Edk2/BaseTools/Tests/TianoCompress.py",
line 65, in testRandomDataCycles
self.compressionTestCycle(data)
File
"/build/zoombini/tmp/portage/sys-boot/fsp-cnl-9999/work/fsp-cnl-9999/Edk2/BaseTools/Tests/TianoCompress.py",
line 44, in compressionTestCycle
self.assertTrue(result == 0)
AssertionError: False is not true
In addition, it seems compilation even breaks trying to build a parser:
VfrSyntax.cpp:53:1: error: expected class-name before '{' token
{^M
^
VfrSyntax.cpp: In constructor 'CVfrDLGLexer::CVfrDLGLexer(DLGFileInput*)':
VfrSyntax.cpp:55:36: error: class 'CVfrDLGLexer' does not have any
field named 'VfrLexer'
CVfrDLGLexer (DLGFileInput *F) : VfrLexer (F) {};^M
^
This just slows down builds needing to things serially.
2. It appears the BaseTools uses the ARCH environment variable. I'm
not sure of the origins, but ARCH seems like a complete misnomer for
the *host* you are trying to build tools on -- not the target. Trying
to incorporate edk2 builds into a portage environment effectively
breaks because of this as ARCH refers to target architecture -- not
host builder's ARCH.
3. This more of an observation, but the tools definition seems to make
quite the leap on how consistent compilers are of a certain version.
e.g. GCC 4.9 can be built with all kinds of default options that edk2
implicitly assumes are set based on some distribution's default flags?
And in order to extend toolchain support one needs to create a series
of entries associated with a certain family. Barrier to entry is
pretty high in teasing out where to put things in the ~8000 line
tools_def.template.
Thanks for the consideration.
-Aaron
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
