On 12/11/2012 10:07 AM, Joshua Brindle wrote:
> rpcraig wrote:
>> On 12/11/2012 08:14 AM, Joshua Brindle wrote:
>>> rpcraig wrote:
>>>> On 12/11/2012 07:35 AM, Joshua Brindle wrote:
>>>>> I understand that, but it doesn't answer my question :X
>>>>>
>>> <snip>
>>>> Independent of the SEPOLICY vars issue, how are you maintaining it?
>>> I have customer1_maguro.mk and customer2_maguro.mk in the maguro repo.
>>> That lets me have different PRODUCT_PACKAGES and PRODUCT_COPY_FILES
>>> variables. The advantages are:
>>>
>>> 1) only 1 repo to rebase when upstream changes, instead of 1 per
>>> customer.
>>> 2) don't have to constantly go around and fix vendor/* generated files
>>> which explicitly check for PRODUCT=maguro or toro.
>>> 3) don't have to reproduce changes I make to any maguro repo that is
>>> not specific to the product in question.
>>> 4) device repos aren't small, because they often have binary blobs and
>>> git doesn't handle that well, having many more will make syncing and
>>> storing worse.
>>>
>>> At least, that is what I was doing until I was forced to have
>>> different policies.
>>
>> In device/samsung/manta/BoardConfig.mk wouldn't you just define your
>> BOARD_SEPOLICY_* vars after the include for the
>> device/samsung/tuna/BoardConfig.mk file. Thereby overriding the ones set
>> in tuna. Then just use if-else makefile logic to build those SEPOLICY
>> vars specific to your customer needs.
>
> I found this discussion. I suppose I could do that but JBQ warned
> against it:
>
> <http://grokbase.com/t/gg/android-building/126spn6jc2/can-i-set-the-values-of-board-or-target-in-device-mk-or-product-mk-instead-of-boardconfig-mk>
>

Seems like he just warned against setting those values in the device.mk
files, not BoardConfig.mk files.


--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe seandroid-list" without quotes as the message.

Reply via email to