From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] RFC for Edk2-ToolEnv To: Rebecca Cran ,devel@edk2.groups.io From: "Sean" X-Originating-IP: 50.47.106.228 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Tue, 14 May 2019 00:37:52 -0700 References: <6c39d4ce-2ec6-3ffc-6f0f-b2a1adf3c1d0@bluestop.org> In-Reply-To: <6c39d4ce-2ec6-3ffc-6f0f-b2a1adf3c1d0@bluestop.org> Message-ID: <24134.1557819472326069609@groups.io> Content-Type: multipart/alternative; boundary="Pi170mVRnctXRgEih3lD" --Pi170mVRnctXRgEih3lD Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Rebecca, If you know of anything I am interested as I don't like building and suppo= rting something unnecessary. This tooling isn't trying to reinvent anything but is really focused on pr= oviding reusable/sharable functionality that can then be pieced together by= a platform to produce the required output.=C2=A0 Today in edk2 you see she= ll script files (bash/bat) and a lot of redefinition of variables and assum= ptions.=C2=A0 This is made much worse in complex closed src code bases, com= plicated pre and post build requirements, and even then managing the path a= nd locations to tools and scripts is a fragile mess.=C2=A0 In practice this= environment has made our build process much more reliable, lower cost to m= aintain, and immune to necessary churn at all levels of the code tree.=C2= =A0 It also has allowed our products to get significant code reuse so we l= ower the cost of ongoing maintenance and new feature introduction. Looking forward to gathering more input from the community as we all don't= need to build similar things. Thanks Sean --Pi170mVRnctXRgEih3lD Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Rebecca,

If you know of anything I am interested as I don't like= building and supporting something unnecessary.  

This tool= ing isn't trying to reinvent anything but is really focused on providing re= usable/sharable functionality that can then be pieced together by a platfor= m to produce the required output.  Today in edk2 you see shell script = files (bash/bat) and a lot of redefinition of variables and assumptions.&nb= sp; This is made much worse in complex closed src code bases, complicated p= re and post build requirements, and even then managing the path and locatio= ns to tools and scripts is a fragile mess.  In practice this environme= nt has made our build process much more reliable, lower cost to maintain, a= nd immune to necessary churn at all levels of the code tree.  It also = has allowed our products to get significant code reuse so we lower the cost= of ongoing maintenance and new feature introduction.  

Loo= king forward to gathering more input from the community as we all don't nee= d to build similar things.  

Thanks
Sean --Pi170mVRnctXRgEih3lD--