On 8/3/15, 3:11 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala" <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote:
>On Mon, Aug 3, 2015 at 7:17 AM, Alex Harui <aha...@adobe.com> wrote: > >> >> >> On 8/3/15, 1:28 AM, "omup...@gmail.com on behalf of OmPrakash Muppirala" >> <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote: >> >> > >> >One thing I couldn't figure out was should we remove the requirement to >> >have a separate GOOG_HOME folder. Or should we get rid of the whole >> >GOOG_HOME thing completely? >> >> Thanks for working on this. IMO, we should keep GOOG_HOME. It occurred >> to me as I was looking at your changes that maybe we shouldn't download >> GCL if GOOG_HOME is set. GOOG_HOME allows you to keep the GCL files >> outside the tree of files for the repo and switch between versions of >>GCL >> if you need to, and dictate usage of a particular version. With these >> changes, every time I run a build I will get the latest which may not be >> what I want when I’m just making quick changes to something like >>core.swc. >> > >So, lets say GOOG_HOME exists and we skip download. When the release >package is made, do we copy the files from GOOG_HOME? Maybe, or download it direct to temp, or download it, copy it, delete it. > > >> >> It also occurred to me that maybe we should fork GCL because even if we >> bundle GCL, if folks build from sources they will get a different GCL. >> >> >But, today that happens in the Installer anyways. The end user will get >whatever the latest GCL binary package contains. >I don't know if forking is a good idea, because we will need to monitor >for >critical, security etc. releases of GCL and merge them in. Not sure if it >is worth the effort. Well, I thought a reason for bundling was to lock us to a version so we wouldn’t give folks the latest. Not sure there is any great answer. We lock all of our other dependencies to a version and don’t spend a lot of energy watching for security updates. I don’t have a strong opinion right now. -Alex
