auto-generating header and using it in multiple locations

[William Roberts]

I am currently working on some AOSP patches here: https://android-review.googlesource.com/#/q/topic:fs-config

Generating the header sources works fine within that Android.mk and modules, However, I was wondering, if I wanted to include that header file

in another module in a different project and Android.mk file, how could I do it? Does anyone know the general paradigm on Android for this? Does

it somehow involve calling $(call intermediates-dir-for,...)?

Thanks,

Bill

[Dan Willemsen]

Just adding $(call intermediates-dir-for,...) to another module's LOCAL_C_INCLUDES isn't safe, since a dependency isn't created to ensure the header exists before the other module is built. Ideally, you would use LOCAL_EXPORT_C_INCLUDE_DIRS, but that doesn't currently set up any dependencies with custom generated headers either.

So right now for the other modules, I'd suggest:

LOCAL_C_INCLUDES := $(dir $(my_fs_config_h))

LOCAL_ADDITIONAL_DEPENDENCIES := $(my_fs_config_h)

Or depending on what you're doing, create a static library that wraps the core implementation and this configuration header, then you wouldn't need other modules to use the header file.

- Dan

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.

[William Roberts]

On Mon, Apr 4, 2016 at 2:29 PM, 'Dan Willemsen' via android-platform <android-...@googlegroups.com> wrote:

Just adding $(call intermediates-dir-for,...) to another module's LOCAL_C_INCLUDES isn't safe, since a dependency isn't created to ensure the header exists before the other module is built. Ideally, you would use LOCAL_EXPORT_C_INCLUDE_DIRS, but that doesn't currently set up any dependencies with custom generated headers either.

Yes precisely, you would have to add the dependency somehow, which that part I understand how to do. The main question is, I wasn't sure if their was a way to get the auto-generated path somehow external to the make file. 

https://android-review.googlesource.com/#/c/206472/8/tools/fs_config/Android.mk

If you look at $(gen) I pretty much want to build a variable that points to that from an external makefile, is it possible with the Android build magic?

 

So right now for the other modules, I'd suggest:

LOCAL_C_INCLUDES := $(dir $(my_fs_config_h))

LOCAL_ADDITIONAL_DEPENDENCIES := $(my_fs_config_h)

Or depending on what you're doing, create a static library that wraps the core implementation and this configuration header, then you wouldn't need other modules to use the header file.

- Dan

On Mon, Apr 4, 2016 at 1:28 PM William Roberts <bill.c....@gmail.com> wrote:

I am currently working on some AOSP patches here: https://android-review.googlesource.com/#/q/topic:fs-config

Generating the header sources works fine within that Android.mk and modules, However, I was wondering, if I wanted to include that header file

in another module in a different project and Android.mk file, how could I do it? Does anyone know the general paradigm on Android for this? Does

it somehow involve calling $(call intermediates-dir-for,...)?

Thanks,

Bill

--
You received this message because you are subscribed to the Google Groups "android-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-platfo...@googlegroups.com.
To post to this group, send email to android-...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "android-platform" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-platform/TxH1M4EEAKQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-platfo...@googlegroups.com.

To post to this group, send email to android-...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-platform.
For more options, visit https://groups.google.com/d/optout.

--

Respectfully,

William C Roberts

[Colin Cross]

On Mon, Apr 4, 2016 at 5:02 PM, William Roberts
<bill.c....@gmail.com> wrote:
>
>
> On Mon, Apr 4, 2016 at 2:29 PM, 'Dan Willemsen' via android-platform
> <android-...@googlegroups.com> wrote:
>>
>> Just adding $(call intermediates-dir-for,...) to another module's
>> LOCAL_C_INCLUDES isn't safe, since a dependency isn't created to ensure the
>> header exists before the other module is built. Ideally, you would use
>> LOCAL_EXPORT_C_INCLUDE_DIRS, but that doesn't currently set up any
>> dependencies with custom generated headers either.
>
>
> Yes precisely, you would have to add the dependency somehow, which that part
> I understand how to do. The main question is, I wasn't sure if their was a
> way to get the auto-generated path somehow external to the make file.
>
> https://android-review.googlesource.com/#/c/206472/8/tools/fs_config/Android.mk
>
> If you look at $(gen) I pretty much want to build a variable that points to
> that from an external makefile, is it possible with the Android build magic?

$(call generated-sources-dir-for,...) will do what you want, but I
don't recommend using it. You will end up with an exported API
implemented by autogenerated code, which sounds painful to me.

>> So right now for the other modules, I'd suggest:
>>
>> LOCAL_C_INCLUDES := $(dir $(my_fs_config_h))
>> LOCAL_ADDITIONAL_DEPENDENCIES := $(my_fs_config_h)
>>
>> Or depending on what you're doing, create a static library that wraps the
>> core implementation and this configuration header, then you wouldn't need
>> other modules to use the header file.

This idea seems much better. Have a stable API that can be
maintained, and autogenerate the data that it uses. For now it can be
a header compiled into the library, but it could eventually be a data
file that the library knows how to read so we can get rid of the whole
fs_config.h mess.

[William Roberts]

On Mon, Apr 4, 2016 at 5:10 PM, Colin Cross <ccr...@android.com> wrote:

On Mon, Apr 4, 2016 at 5:02 PM, William Roberts
<bill.c....@gmail.com> wrote:
>
>
> On Mon, Apr 4, 2016 at 2:29 PM, 'Dan Willemsen' via android-platform
> <android-...@googlegroups.com> wrote:
>>
>> Just adding $(call intermediates-dir-for,...) to another module's
>> LOCAL_C_INCLUDES isn't safe, since a dependency isn't created to ensure the
>> header exists before the other module is built. Ideally, you would use
>> LOCAL_EXPORT_C_INCLUDE_DIRS, but that doesn't currently set up any
>> dependencies with custom generated headers either.
>
>
> Yes precisely, you would have to add the dependency somehow, which that part
> I understand how to do. The main question is, I wasn't sure if their was a
> way to get the auto-generated path somehow external to the make file.
>
> https://android-review.googlesource.com/#/c/206472/8/tools/fs_config/Android.mk
>
> If you look at $(gen) I pretty much want to build a variable that points to
> that from an external makefile, is it possible with the Android build magic?

$(call generated-sources-dir-for,...) will do what you want, but I
don't recommend using it.  You will end up with an exported API
implemented by autogenerated code, which sounds painful to me.

Yep, so what do you specify for the arguments? What does the ellipses expand to?

 

>> So right now for the other modules, I'd suggest:
>>
>> LOCAL_C_INCLUDES := $(dir $(my_fs_config_h))
>> LOCAL_ADDITIONAL_DEPENDENCIES := $(my_fs_config_h)
>>
>> Or depending on what you're doing, create a static library that wraps the
>> core implementation and this configuration header, then you wouldn't need
>> other modules to use the header file.

This idea seems much better.  Have a stable API that can be
maintained, and autogenerate the data that it uses.  For now it can be
a header compiled into the library, but it could eventually be a data
file that the library knows how to read so we can get rid of the whole
fs_config.h mess.

Yep that's the eventually future route, something to seperate it out, not sure if

a shared object is ok, or if we should throw a config file into /etc that has this information.

The filesystem config split has been a sore point for attempting to granulrize uid./gid

usage and configuring fs caps. The first round of changes is really only meant to handle

the fs caps usages. But I see how it can be extended to deal with the rest of it.

Probably in a few weeks, when aosp master is more stable (I have been having device and

emulator issues) I can get back to drafting up a way to put this to bed finally.

[Colin Cross]

On Mon, Apr 4, 2016 at 5:50 PM, William Roberts

$(call generated-sources-dir-for,EXECUTABLES,fs_config_generate_$(TARGET_DEVICE),HOST)

[William Roberts]

Thanks, I didn't notice the switch from intermediates-dir-for to generated-sources-dir-for until now. That works.