TianoCore Community Design Meeting Minutes

["Ni, Ray" <ray.ni@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 3444 bytes --]

Hi everyone,

In the first design meeting, Matthew and Sean from Microsoft presented the Mu tools.

Below are some notes Mike and I captured from the meeting.

Please reply to this mail for any questions and comments.



Matthew Carlson / Sean Brogan - Microsoft - Project Mu Tools https://edk2.groups.io/g/devel/files/Designs/2019/0418/2019-04-18%20Microsoft%20-%20Build%20Tools%20-%20Design%20Review%20.pdf

------------------------------------

EDKII tool

- uses batch/scripts with build command

- does not provide a consistent recipe for doing platforms



Background

- Mu is to organize code to support building products.

- Boot strapping refers to setting up initial build environment for building a product or platform.

- Splitting the code: A platform only needs to see the code the platform uses to build.



Mu tools use Python

- Install modules/tools with pip.

- Makes modules/tools available globally.

- Simplified python sources - import statements and version management.

- Allows python source to move within repo or between repos without source changes.



3 layers of pip modules from top to bottom:

- Mu-build (support CI)

- Mu-environment (support platform build)

- Mu-python-library (common code)



pip modules are already released in python3 pip storage.

- Will do release on demand.

- Expect to work in Win and Linux.

- Will try on MAC.



Build a platform through PlatformBuild.py

- Starts with ~1% of platform code

- Dependencies resolving phase pulls additional platform code

   * Multiple GIT repos are needed by platform. The dep resolving phase simplifies the code setup. "setup" phase is isolated and can be skipped or replaced with other similar tools.



Plugin Manager

- Only accept python plugins

- If tool is an exe, then a python wrapper is required.

- This plugin manager is not standard.  It is part of the mu tool extensions.



Question: Checkpoint and reproducibility

- Check pointing allows multiple builds with each build starting with same state

- Check pointing limited to system env and sys env variables.

- Must clean up platforms to not generate output files in source dirs.



Developer experience

- Can switch from one platform env to another easily.

- Devs working on common code and test across multiple platforms by switching platform env



Example of override - will send pointer

- #Override : 00000001 | MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf | c02f12780a5b035346be539c80ccd0e5 | 2018-10-05T21-43-51

- https://github.com/Microsoft/mu_plus/blob/release/201903/MsGraphicsPkg/DisplayEngineDxe/DisplayEngineDxe.inf

- Files go here?  https://edk2.groups.io/g/devel/files/Designs/2019/0418



VS2017 - VSWhere

- VS2017 supports multiple versions being installed

- Selects most recent version by default

- Platform can select a specific version.

- Gap in EDK II tools_def.txt today.  Requires different tool chain tag for each version of VS2017



Documentation

- Links in presentation

- RFC will be sent out in middle of May

- More coming



Question: CI tests- are they build only?

- They can do build and run tests.  Can also do pre-checks based on plugins



IMX is an example platform build that anyone can pull and try (https://github.com/ms-iot/MU_PLATFORM_NXP)



Thanks,

Ray



[-- Attachment #2: Type: text/html, Size: 8937 bytes --]