On Wed, Jul 25, 2018 at 1:06 PM, Dan Willemsen <dwillem...@google.com> wrote: > On Wed, Jul 25, 2018 at 12:35 PM John Stultz <john.stu...@linaro.org> wrote: >> >> On Wed, Jul 25, 2018 at 5:36 AM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >> > On 25 July 2018 at 00:21, John Stultz <john.stu...@linaro.org> wrote: >> >> From: Dan Willemsen <dwillem...@google.com> >> >> >> >> This is a forward port of a patch from the AOSP/master tree: >> >> https://android.googlesource.com/platform/external/mesa3d/+/bd633f11de0c6ac1ed333a28344c74fd9898df9e%5E%21/ >> >> >> >> Which replaces HOST_OUT_release with HOST_OUT >> >> >> > What's wrong with HOST_OUT_release? If it is something that got >> > deprecated, we could: >> > a) add a comment above it (deprecated since Android ...) >> > b) add the HOST_OUT alongside the existing HOST_OUT_release >> >> Seems to be the case since: >> https://android.googlesource.com/platform/build/+/d6ed368fde0609742540b5da6d2e8a2a19b2c0eb%5E%21/ >> >> Dan/Alistair: Any objections to option b? > > You can't add side-by-side, since new lines must be added at the end of the > file (the makefiles keep track of which lines were run by index, not their > contents). But when that variable isn't set, it would try to remove > "/*/EXECUTABLES/... > You could do something like: > > ifdef HOST_OUT_release > ... > else > ... > endif > > But it was already incorrect to use $(HOST_OUT_release) here, $(HOST_OUT) will > be set properly for whether the current build that's being cleaned during > incrementals is using host debug or release builds (it was incredibly uncommon > to use a debug host build, there was never a shortcut to use that, you had to > set an environment variable manually, and it was rarely if ever tested).
Emil: Is this sufficient justification to drop HOST_OUT_release then? > I'll also note that the Android.mk files are not guaranteed to be compatible > between releases, even more so as we're switching away from Make. To this point, this policy (and the switching from make to blueprints) does create a bit of turmoil for external projects that want to preserve compatibility with older Android releases. Particularly as there doesn't seem to be an obvious way to support both makefiles and blueprints in parallel. Obviously at some point external projects need to move drop support for older versions of Android, and options like having separate branches for older-android support seems like a reasonable compromise when there are major conflicts (upstreams don't want to break existing users, but prioritizing keeping latest AOSP working with upstream master branches seems most important to me, as it has a higher potential for improving long term collaboration between the projects). But as we are trying to get upstream projects to pick up changes that make it easier to work with AOSP, AOSP needs to take consideration how to best work with upstream projects as well. thanks -john _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev