RFC: Proposal to halt automatic builds of Windows BaseTools executables

RFC: Proposal to halt automatic builds of Windows BaseTools executables

[Bjorge, Erik C]

I would like to propose that the automatic builds of Windows BaseTools executables be halted.  This implies there will no longer be updates to the edk2-BaseTools-win32 repository.

With this change, developers using Windows must install Python 2.7.x and configure their environment to build C tools  and run python scripts from sources.  This matches the development experience for non-Windows environments.

Please respond with comments by 03/23/2018.

Thanks,
-Erik

Re: RFC: Proposal to halt automatic builds of Windows BaseTools executables

[Gao, Liming]

Hi, all

  Here is wiki https://github.com/tianocore/tianocore.github.io/wiki/Windows-systems#compile-tools on Compile BaseTools in windows. 

Thanks
Liming
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Bjorge, Erik C
> Sent: Thursday, March 8, 2018 1:57 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] RFC: Proposal to halt automatic builds of Windows BaseTools executables
> 
> I would like to propose that the automatic builds of Windows BaseTools executables be halted.  This implies there will no longer be
> updates to the edk2-BaseTools-win32 repository.
> 
> With this change, developers using Windows must install Python 2.7.x and configure their environment to build C tools  and run
> python scripts from sources.  This matches the development experience for non-Windows environments.
> 
> Please respond with comments by 03/23/2018.
> 
> Thanks,
> -Erik
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: RFC: Proposal to halt automatic builds of Windows BaseTools executables

[Tim Lewis]

Erik --

What is the justification? Moving from more immediately usable to less
immediately usable doesn't seem, on the surface, to be  a good direction.
Why not go the other direction and pre-build the binaries for the other
environments?

Thanks,

Tim

-----Original Message-----
From: edk2-devel <edk2-devel-bounces@lists.01.org> On Behalf Of Bjorge, Erik
C
Sent: Wednesday, March 7, 2018 9:57 AM
To: edk2-devel@lists.01.org
Subject: [edk2] RFC: Proposal to halt automatic builds of Windows BaseTools
executables

I would like to propose that the automatic builds of Windows BaseTools
executables be halted.  This implies there will no longer be updates to the
edk2-BaseTools-win32 repository.

With this change, developers using Windows must install Python 2.7.x and
configure their environment to build C tools  and run python scripts from
sources.  This matches the development experience for non-Windows
environments.

Please respond with comments by 03/23/2018.

Thanks,
-Erik

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: RFC: Proposal to halt automatic builds of Windows BaseTools executables

[Andrew Fish]

> On Mar 8, 2018, at 10:05 AM, Tim Lewis <tim.lewis@insyde.com> wrote:
> 
> Erik --
> 
> What is the justification? Moving from more immediately usable to less
> immediately usable doesn't seem, on the surface, to be  a good direction.
> Why not go the other direction and pre-build the binaries for the other
> environments?
> 

Tim,

I'm not a big fan of the prebuilt tools. In a production environment it is usually preferable to have source and to NOT check in binaries. Given the other environments have Python by default I don't see the value of pre-building the tools on Unix systems? 

I think the ease of use issue is really a different issue (other than having to install Python).  Most projects you start from the root and type make (nmake). A top level makefile would abstract the building of the tools and the need to setup environment variables. 

Why can't I pull a git repo and do:
$ make OvmfPkgX64

I grant it may be hard to automagically pick the compiler but you can do things like:
$ make OvmfPkgX64 BUILD_FLAGS="-n 1 -t XCODE"

As long as build.py acts like a compiler and the last version of a given flag wins this should be easy to do. 

Thanks,

Andrew Fish

> Thanks,
> 
> Tim
> 
> -----Original Message-----
> From: edk2-devel <edk2-devel-bounces@lists.01.org> On Behalf Of Bjorge, Erik
> C
> Sent: Wednesday, March 7, 2018 9:57 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] RFC: Proposal to halt automatic builds of Windows BaseTools
> executables
> 
> I would like to propose that the automatic builds of Windows BaseTools
> executables be halted.  This implies there will no longer be updates to the
> edk2-BaseTools-win32 repository.
> 
> With this change, developers using Windows must install Python 2.7.x and
> configure their environment to build C tools  and run python scripts from
> sources.  This matches the development experience for non-Windows
> environments.
> 
> Please respond with comments by 03/23/2018.
> 
> Thanks,
> -Erik
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: RFC: Proposal to halt automatic builds of Windows BaseTools executables

[Bjorge, Erik C]

Tim,

I see this as more immediately usable.  I now only have to pull and monitor a single repo that already has all the source for the build tools.  I can also easily checkout a release branch and build the matching tools for that version of UDK.  It also simplifies debugging and development of tools.  I also like the fact that I can update python to include the latest security patches as needed.

To help with the process on Windows edksetup.bat has the ability to build the tools using the Rebuild and ForceRebuild options.

Thanks,
-Erik
 
-----Original Message-----
From: afish@apple.com [mailto:afish@apple.com] 
Sent: Thursday, March 8, 2018 10:37 AM
To: Tim Lewis <tim.lewis@insyde.com>
Cc: Bjorge, Erik C <erik.c.bjorge@intel.com>; edk2-devel@lists.01.org
Subject: Re: [edk2] RFC: Proposal to halt automatic builds of Windows BaseTools executables


> On Mar 8, 2018, at 10:05 AM, Tim Lewis <tim.lewis@insyde.com> wrote:
> 
> Erik --
> 
> What is the justification? Moving from more immediately usable to less 
> immediately usable doesn't seem, on the surface, to be  a good direction.
> Why not go the other direction and pre-build the binaries for the 
> other environments?
> 

Tim,

I'm not a big fan of the prebuilt tools. In a production environment it is usually preferable to have source and to NOT check in binaries. Given the other environments have Python by default I don't see the value of pre-building the tools on Unix systems? 

I think the ease of use issue is really a different issue (other than having to install Python).  Most projects you start from the root and type make (nmake). A top level makefile would abstract the building of the tools and the need to setup environment variables. 

Why can't I pull a git repo and do:
$ make OvmfPkgX64

I grant it may be hard to automagically pick the compiler but you can do things like:
$ make OvmfPkgX64 BUILD_FLAGS="-n 1 -t XCODE"

As long as build.py acts like a compiler and the last version of a given flag wins this should be easy to do. 

Thanks,

Andrew Fish

> Thanks,
> 
> Tim
> 
> -----Original Message-----
> From: edk2-devel <edk2-devel-bounces@lists.01.org> On Behalf Of 
> Bjorge, Erik C
> Sent: Wednesday, March 7, 2018 9:57 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] RFC: Proposal to halt automatic builds of Windows 
> BaseTools executables
> 
> I would like to propose that the automatic builds of Windows BaseTools 
> executables be halted.  This implies there will no longer be updates 
> to the
> edk2-BaseTools-win32 repository.
> 
> With this change, developers using Windows must install Python 2.7.x 
> and configure their environment to build C tools  and run python 
> scripts from sources.  This matches the development experience for 
> non-Windows environments.
> 
> Please respond with comments by 03/23/2018.
> 
> Thanks,
> -Erik
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: RFC: Proposal to halt automatic builds of Windows BaseTools executables

[Laszlo Ersek]

On 03/08/18 19:05, Tim Lewis wrote:
> Erik --
> 
> What is the justification? Moving from more immediately usable to less
> immediately usable doesn't seem, on the surface, to be  a good direction.
> Why not go the other direction and pre-build the binaries for the other
> environments?

I'd just like to offer one data point for the last question: most open
source developers *really* dislike running any native binaries that were
built by neither (a) themselves nor (b) the provider of their OS
distribution.

To give you an example for (b), Fedora provides the "edk2-tools" package
(built from the "edk2" source package), and "edk2-tools" definitely
installs native binaries:

https://koji.fedoraproject.org/koji/rpminfo?rpmID=13354362

The difference is that these binaries were built in a build environment
that matches the rest of Fedora [*] and is generally trusted by Fedora
users.

[*] For example, binaries could be instrumented for security purposes
system-wide; some buffer overflows in a native (C) application could be
caught automatically as a result.

Thanks,
Laszlo

Re: RFC: Proposal to halt automatic builds of Windows BaseTools executables

[Tim Lewis]

Laszlo, Erik --

I understand this dislike from some open source developers. I respect that and am glad that EDK2 provides a way to accommodate this preference. But "most" is a strong term. I would venture to say that a good number (and probably the majority) of the people using EDK2-derived code and tools are fine with the current situation.

The only reason I would have Python on most of my company's dev systems would be for EDK2. Since (a) the current system is working and (b) since the possibility for rebuild is available for those who want it, it doesn't weigh heavily enough IMO to change the current situation. 

Regards,

Tim

-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com> 
Sent: Thursday, March 8, 2018 1:19 PM
To: Tim Lewis <tim.lewis@insyde.com>; 'Bjorge, Erik C' <erik.c.bjorge@intel.com>; edk2-devel@lists.01.org
Subject: Re: [edk2] RFC: Proposal to halt automatic builds of Windows BaseTools executables

On 03/08/18 19:05, Tim Lewis wrote:
> Erik --
> 
> What is the justification? Moving from more immediately usable to less 
> immediately usable doesn't seem, on the surface, to be  a good direction.
> Why not go the other direction and pre-build the binaries for the 
> other environments?

I'd just like to offer one data point for the last question: most open source developers *really* dislike running any native binaries that were built by neither (a) themselves nor (b) the provider of their OS distribution.

To give you an example for (b), Fedora provides the "edk2-tools" package (built from the "edk2" source package), and "edk2-tools" definitely installs native binaries:

https://koji.fedoraproject.org/koji/rpminfo?rpmID=13354362

The difference is that these binaries were built in a build environment that matches the rest of Fedora [*] and is generally trusted by Fedora users.

[*] For example, binaries could be instrumented for security purposes system-wide; some buffer overflows in a native (C) application could be caught automatically as a result.

Thanks,
Laszlo

Re: RFC: Proposal to halt automatic builds of Windows BaseTools executables

[Andrew Fish]

Tim,

It is not just an open source thing. In our world we can't build on the production servers with arbitrary binaries in the tree. We have to file paper work to get an exemption, and given we can build the tools in our source base the answer would always be don't check in the binary.

I would assume that a given EFI team at company X could always build and check-in tools binaries as part of their source control repo. But it would be good if that was easy and documented.

I'd also point out worse case this is all open source so another project could always provide tools snapshots....

Thanks,

Andrew Fish

> On Mar 8, 2018, at 1:36 PM, Tim Lewis <tim.lewis@insyde.com> wrote:
> 
> Laszlo, Erik --
> 
> I understand this dislike from some open source developers. I respect that and am glad that EDK2 provides a way to accommodate this preference. But "most" is a strong term. I would venture to say that a good number (and probably the majority) of the people using EDK2-derived code and tools are fine with the current situation.
> 
> The only reason I would have Python on most of my company's dev systems would be for EDK2. Since (a) the current system is working and (b) since the possibility for rebuild is available for those who want it, it doesn't weigh heavily enough IMO to change the current situation. 
> 
> Regards,
> 
> Tim
> 
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com> 
> Sent: Thursday, March 8, 2018 1:19 PM
> To: Tim Lewis <tim.lewis@insyde.com>; 'Bjorge, Erik C' <erik.c.bjorge@intel.com>; edk2-devel@lists.01.org
> Subject: Re: [edk2] RFC: Proposal to halt automatic builds of Windows BaseTools executables
> 
> On 03/08/18 19:05, Tim Lewis wrote:
>> Erik --
>> 
>> What is the justification? Moving from more immediately usable to less 
>> immediately usable doesn't seem, on the surface, to be  a good direction.
>> Why not go the other direction and pre-build the binaries for the 
>> other environments?
> 
> I'd just like to offer one data point for the last question: most open source developers *really* dislike running any native binaries that were built by neither (a) themselves nor (b) the provider of their OS distribution.
> 
> To give you an example for (b), Fedora provides the "edk2-tools" package (built from the "edk2" source package), and "edk2-tools" definitely installs native binaries:
> 
> https://koji.fedoraproject.org/koji/rpminfo?rpmID=13354362
> 
> The difference is that these binaries were built in a build environment that matches the rest of Fedora [*] and is generally trusted by Fedora users.
> 
> [*] For example, binaries could be instrumented for security purposes system-wide; some buffer overflows in a native (C) application could be caught automatically as a result.
> 
> Thanks,
> Laszlo
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel