rpcraig wrote:
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.
The next to last post mentions doing if-else in BoardConfig.mk and JBQ
recommended not to.
--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to majord...@tycho.nsa.gov with
the words "unsubscribe seandroid-list" without quotes as the message.
