public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Bjorge, Erik C" <erik.c.bjorge@intel.com>
To: "afish@apple.com" <afish@apple.com>, Tim Lewis <tim.lewis@insyde.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: RFC: Proposal to halt automatic builds of Windows BaseTools executables
Date: Thu, 8 Mar 2018 19:52:26 +0000	[thread overview]
Message-ID: <7FE3244EBB31F1449E4EC79CFE44E3F4ACA8FE9D@ORSMSX114.amr.corp.intel.com> (raw)
In-Reply-To: <714C59A1-275B-4090-955D-F135B6E70DD1@apple.com>

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



  reply	other threads:[~2018-03-08 19:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-07 17:56 RFC: Proposal to halt automatic builds of Windows BaseTools executables Bjorge, Erik C
2018-03-08  1:21 ` Gao, Liming
2018-03-08 18:05 ` Tim Lewis
2018-03-08 18:37   ` Andrew Fish
2018-03-08 19:52     ` Bjorge, Erik C [this message]
2018-03-08 21:18   ` Laszlo Ersek
2018-03-08 21:36     ` Tim Lewis
2018-03-08 22:19       ` Andrew Fish

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7FE3244EBB31F1449E4EC79CFE44E3F4ACA8FE9D@ORSMSX114.amr.corp.intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox