On Thu, May 5, 2016 at 1:28 PM, Michael Shal <ms...@mozilla.com> wrote:
> Are there particular issues with option 1 that we're trying to avoid? In
> other words, have we had problems in the confvars.sh world that we need to
> address? (Aside from converting .sh -> .py).
>
I found when doing conversions that having things in multiple places is
somewhat inconvenient, so this came up as a way to make it easier to figure
out everything about a particular flag in a single place. But the feedback
so far is pointing out that it's more important to see flags relevant to a
particular project in one place, so we can go with that. And like gps
pointed out, a tool to collate flags across project will be simple to
implement on top of this.
>
Although there are aspects of option 2) that I like, I could also see
> something like toolkit/moz.configure becoming hard to follow where you'd
> have browser-specific sections and android-specific sections all
> interspersed with each other. So I would vote for option 1 at the moment,
> unless there's a more concrete example of a problem we'd avoid with 2.
>
> -Mike
>
> On Tue, May 3, 2016 at 4:45 PM, Christopher Manchester <
> chmanches...@gmail.com> wrote:
>
>> We're moving some things currently defined in various confvars.sh files
>> to Python configure (moz.configure), and have reached a point where
>> feedback would be helpful, as we are replacing a relatively longstanding
>> thing, and many are likely to interact with these options in the future.
>>
>> The competing proposals are:
>>
>> 1. Define options in a central location, and set them with imply_option
>> in a project-specific moz.configure. For example:
>>
>> in toolkit/moz.configure:
>>
>> +project_option('MOZ_MOBILE_FOO',
>> + help="Build foo if required")
>>
>> in mobile/android/moz.configure and any others that need it:
>>
>> +imply_option('MOZ_MOBILE_FOO', True)
>>
>> 2. Define options in a central location, and allow setting them with a
>> templated function (imply_option in a project specific moz.configure might
>> still be permitted, which would be useful for projects outside of the
>> tree). Same example:
>>
>> in toolkit/moz.configure:
>>
>> +project_option('MOZ_MOBILE_FOO',
>> + help="Build foo if required",
>> + condition=enabled_for("mobile/android", "b2g"))
>>
>> Just one point in favor of each: option 1 is quite close to what we have
>> today, while 2 puts more information about a flag in a single location,
>> which might make things easier to understand.
>>
>> Chris
>>
>>
>> _______________________________________________
>> dev-builds mailing list
>> dev-builds@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-builds
>>
>>
>
> _______________________________________________
> dev-builds mailing list
> dev-builds@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-builds
>
>
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
