[prev in list] [next in list] [prev in thread] [next in thread]
List: seandroid-list
Subject: Re: union sepolicy files
From: Robert Craig <rpcraig () tycho ! ncsc ! mil>
Date: 2015-03-11 17:53:43
Message-ID: 55008127.7060307 () tycho ! ncsc ! mil
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Good to hear it might work for ya. Yeah, we have something similar like
this in our build tree - not sure it's the best solution but it gets the
job done.
ifeq ($(word 2, $(subst _, ,$(TARGET_PRODUCT))), hammerhead)
On 03/11/2015 01:46 PM, Owain Davies wrote:
> Thanks Robert, that is a good idea. I would still need to do
> myprod_hammerhead myprod_shamu myprod_flounder though If I use a
> consistent name convention myprod_<target_device> then I could use the
> following:
>
> ifneq($(filter myprod_%, $(PRODUCT_NAME) ),)
>
> On 11 March 2015 at 17:23, Robert Craig <rpcraig@tycho.ncsc.mil
> <mailto:rpcraig@tycho.ncsc.mil>> wrote:
>
> If you're worried about including those changes in all the builds
> then maybe put a conditional at the top of the
> vendor/foo/hammerhead/device-partial.mk <http://device-partial.mk>
> file. What if you put the following at the top of the file.
>
> ifeq ($(TARGET_PRODUCT), myhammerhead)
>
>
>
> On 03/11/2015 01:12 PM, Owain Davies wrote:
> > I have some clarification on this now.
> > The TARGET_DEVICE is specified in a Product makefile using
> > PRODUCT_DEVICE.
> > The build system will then look for a BoardConfig.mk file in
> > "build/target/board/$(TARGET_DEVICE)/" and search up to 4
> > directories deep in "vendor" and "device" for a directory named
> > $(TARGET_DEVICE) containing a BoardConfig.mk file. If it finds
> > none that is an error if it find more than one that is also an error.
> >
> > So my proposed directory structure does not work, and I still can
> > find no way to conditionally include the BOARD_SEPOLICY_UNION
> > just for when my product is being built.
> >
> > I can crate a newly named target device (eg. "myhammerhead")
> > which would inherrit the original device config (eg.
> > "hammerhead"), but that breaks all the hardware and devices
> > specific modules which only build for the original TARGET_DEVICE
> > name.
> >
> > Stephen's idea would obviously work, but it would still
> > unconditionally include those changes even if I was not building
> > myprod but building the base aosp build.
> >
> > I guess there is not an easy answer to this.
> >
> >
> >
> >
> > _______________________________________________
> > Seandroid-list mailing list
> > Seandroid-list@tycho.nsa.gov <mailto:Seandroid-list@tycho.nsa.gov>
> > To unsubscribe, send email toSeandroid-list-leave@tycho.nsa.gov \
> > <mailto:Seandroid-list-leave@tycho.nsa.gov>. To get help, send an email \
> > containing "help" toSeandroid-list-request@tycho.nsa.gov \
> > <mailto:Seandroid-list-request@tycho.nsa.gov>.
>
>
[Attachment #5 (text/html)]
<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Good to hear it might work for ya. Yeah, we have something similar
like this in our build tree - not sure it's the best solution but it
gets the job done.<br>
<br>
ifeq ($(word 2, $(subst _, ,$(TARGET_PRODUCT))), hammerhead)<br>
<br>
<br>
<div class="moz-cite-prefix">On 03/11/2015 01:46 PM, Owain Davies
wrote:<br>
</div>
<blockquote
cite="mid:CAJ0FSTM5Rqfm8ZFWCDUkCFA8xuyYi5jJVqDf73rwgZ_PY6Sbjg@mail.gmail.com"
type="cite">
<div dir="ltr">Thanks Robert, that is a good idea. I would still
need to do myprod_hammerhead myprod_shamu myprod_flounder though
If I use a consistent name convention
myprod_<target_device> then I could use the following:
<div><br>
</div>
<div>ifneq($(filter myprod_%, $(PRODUCT_NAME) ),)</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 11 March 2015 at 17:23, Robert Craig
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:rpcraig@tycho.ncsc.mil" \
target="_blank">rpcraig@tycho.ncsc.mil</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> If you're worried
about including those changes in all the builds then maybe
put a conditional at the top of the vendor/foo/hammerhead/<a
moz-do-not-send="true" href="http://device-partial.mk"
target="_blank">device-partial.mk</a> file. What if you
put the following at the top of the file.<br>
<br>
ifeq ($(TARGET_PRODUCT), myhammerhead)
<div>
<div class="h5"><br>
<br>
<br>
<div>On 03/11/2015 01:12 PM, Owain Davies wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<div dir="ltr">I have some clarification on this
now.
<div>The TARGET_DEVICE is specified in a Product
makefile using PRODUCT_DEVICE.</div>
<div>The build system will then look for a
BoardConfig.mk file in
"build/target/board/$(TARGET_DEVICE)/" and
search up to 4 directories deep in "vendor" and
"device" for a directory named $(TARGET_DEVICE)
containing a BoardConfig.mk file. If it finds
none that is an error if it find more than one
that is also an error.</div>
<div><br>
</div>
<div>So my proposed directory structure does not
work, and I still can find no way to
conditionally include the BOARD_SEPOLICY_UNION
just for when my product is being built.</div>
<div><br>
</div>
<div>I can crate a newly named target device (eg.
"myhammerhead") which would inherrit the
original device config (eg. "hammerhead"), but
that breaks all the hardware and devices
specific modules which only build for the
original TARGET_DEVICE name.</div>
<div><br>
</div>
<div>Stephen's idea would obviously work, but it
would still unconditionally include those
changes even if I was not building myprod but
building the base aosp build.</div>
<div><br>
</div>
<div>I guess there is not an easy answer to this.</div>
<div><br>
<div><br>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<span class="">
<pre>_______________________________________________
Seandroid-list mailing list
<a moz-do-not-send="true" href="mailto:Seandroid-list@tycho.nsa.gov" \
target="_blank">Seandroid-list@tycho.nsa.gov</a> To unsubscribe, send email to <a \
moz-do-not-send="true" href="mailto:Seandroid-list-leave@tycho.nsa.gov" \
target="_blank">Seandroid-list-leave@tycho.nsa.gov</a>. To get help, send an email \
containing "help" to <a moz-do-not-send="true" \
href="mailto:Seandroid-list-request@tycho.nsa.gov" \
target="_blank">Seandroid-list-request@tycho.nsa.gov</a>.</pre> </span></blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>
_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
To get help, send an email containing "help" to Seandroid-list-request@tycho.nsa.gov.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic