[PATCH BlueZ] build: Fix make distcheck for input plugin

[PATCH BlueZ] build: Fix make distcheck for input plugin

[Anderson Lizardo]

suspend.c is a symlink generated at build time, therefore it should be
created on build directory. Additionally, it is necessary to add
-I$(srcdir)/profiles/input to CPPFLAGS so suspend.h can be found (the
compiler does not follow symlinks prior to resolving #include
directives).
---
 Makefile.am |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index d49e8a0..c398e74 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -366,6 +366,10 @@ if MCAP
 AM_CPPFLAGS += -I$(builddir)/health
 endif
 
+if HOGPLUGIN
+AM_CPPFLAGS += -I$(srcdir)/profiles/input
+endif
+
 unit_objects =
 
 if TEST
@@ -405,7 +409,7 @@ profiles/sap/sap.c: profiles/sap/@SAP_DRIVER@
 	$(AM_V_GEN)$(LN_S) $(abs_top_srcdir)/$< $@
 
 profiles/input/suspend.c: profiles/input/@HOG_SUSPEND_DRIVER@
-	$(AM_V_GEN)$(LN_S) $(abs_top_srcdir)/$< $@
+	$(AM_V_GEN)$(LN_S) $(abs_top_builddir)/$< $@
 
 scripts/%.rules:
 	$(AM_V_GEN)cp $(subst 97-,,$@) $@
-- 
1.7.9.5

Re: [PATCH BlueZ] build: Fix make distcheck for input plugin

[Johan Hedberg]

Hi Lizardo,

On Mon, Nov 12, 2012, Anderson Lizardo wrote:
> suspend.c is a symlink generated at build time, therefore it should be
> created on build directory. Additionally, it is necessary to add
> -I$(srcdir)/profiles/input to CPPFLAGS so suspend.h can be found (the
> compiler does not follow symlinks prior to resolving #include
> directives).
> ---
>  Makefile.am |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Applied. Thanks.

Johan

Re: [PATCH BlueZ] build: Fix make distcheck for input plugin

[Lucas De Marchi]

On Mon, Nov 12, 2012 at 7:03 PM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> suspend.c is a symlink generated at build time, therefore it should be
> created on build directory. Additionally, it is necessary to add
> -I$(srcdir)/profiles/input to CPPFLAGS so suspend.h can be found (the
> compiler does not follow symlinks prior to resolving #include
> directives).
> ---
>  Makefile.am |    6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index d49e8a0..c398e74 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -366,6 +366,10 @@ if MCAP
>  AM_CPPFLAGS += -I$(builddir)/health
>  endif
>
> +if HOGPLUGIN
> +AM_CPPFLAGS += -I$(srcdir)/profiles/input
> +endif

Humn... maybe we need to review these CPPFLAGS for plugins. Appending
it to AM_CPPFLAGS means that every single source file has
"-I$(srcdir)/profiles/input". Even those sources not at all related to
HOGPLUGIN.

However the only way I can think to fix it is by creating convenience
libs since autofoo doesn't support CPPFLAGS per source file.


Lucas De Marchi

Re: [PATCH BlueZ] build: Fix make distcheck for input plugin

[Anderson Lizardo]

Hi Lucas,

On Tue, Nov 13, 2012 at 8:21 AM, Lucas De Marchi
<lucas.demarchi@profusion.mobi> wrote:
> On Mon, Nov 12, 2012 at 7:03 PM, Anderson Lizardo
> <anderson.lizardo@openbossa.org> wrote:
>> suspend.c is a symlink generated at build time, therefore it should be
>> created on build directory. Additionally, it is necessary to add
>> -I$(srcdir)/profiles/input to CPPFLAGS so suspend.h can be found (the
>> compiler does not follow symlinks prior to resolving #include
>> directives).
>> ---
>>  Makefile.am |    6 +++++-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index d49e8a0..c398e74 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -366,6 +366,10 @@ if MCAP
>>  AM_CPPFLAGS += -I$(builddir)/health
>>  endif
>>
>> +if HOGPLUGIN
>> +AM_CPPFLAGS += -I$(srcdir)/profiles/input
>> +endif
>
> Humn... maybe we need to review these CPPFLAGS for plugins. Appending
> it to AM_CPPFLAGS means that every single source file has
> "-I$(srcdir)/profiles/input". Even those sources not at all related to
> HOGPLUGIN.
>
> However the only way I can think to fix it is by creating convenience
> libs since autofoo doesn't support CPPFLAGS per source file.

I agree it is not the best solution. Actually, I think we can overcome
the problem completely by getting rid of symlinks for "drivers" (like
sap-{u8500,dummy}.c, suspend-dummy.c,
telephony-{dummy,maemo5,maemo6,ofono}.c) and having everything
built-in and enabled/disabled based on which D-Bus services are
running on the system (or, if not possible, by using config options).
This would also help with spotting build breakages, since all BlueZ
code could be compiled by a single "./bootstrap-configure && make"
call.

This was suggested by Marcel sometime ago on the mailing list, but no
one has come up with actually implementing this.

This commit for now will fix make distcheck breakage, and in my tests
it did not break anything else.

I will propose a TODO entry for this, so someone can work on it.

Best Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

Re: [PATCH BlueZ] build: Fix make distcheck for input plugin

[Lucas De Marchi]

On Tue, Nov 13, 2012 at 10:52 AM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> Hi Lucas,
>
> On Tue, Nov 13, 2012 at 8:21 AM, Lucas De Marchi
> <lucas.demarchi@profusion.mobi> wrote:
>> On Mon, Nov 12, 2012 at 7:03 PM, Anderson Lizardo
>> <anderson.lizardo@openbossa.org> wrote:
>>> suspend.c is a symlink generated at build time, therefore it should be
>>> created on build directory. Additionally, it is necessary to add
>>> -I$(srcdir)/profiles/input to CPPFLAGS so suspend.h can be found (the
>>> compiler does not follow symlinks prior to resolving #include
>>> directives).
>>> ---
>>>  Makefile.am |    6 +++++-
>>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Makefile.am b/Makefile.am
>>> index d49e8a0..c398e74 100644
>>> --- a/Makefile.am
>>> +++ b/Makefile.am
>>> @@ -366,6 +366,10 @@ if MCAP
>>>  AM_CPPFLAGS += -I$(builddir)/health
>>>  endif
>>>
>>> +if HOGPLUGIN
>>> +AM_CPPFLAGS += -I$(srcdir)/profiles/input
>>> +endif
>>
>> Humn... maybe we need to review these CPPFLAGS for plugins. Appending
>> it to AM_CPPFLAGS means that every single source file has
>> "-I$(srcdir)/profiles/input". Even those sources not at all related to
>> HOGPLUGIN.
>>
>> However the only way I can think to fix it is by creating convenience
>> libs since autofoo doesn't support CPPFLAGS per source file.
>
> I agree it is not the best solution. Actually, I think we can overcome
> the problem completely by getting rid of symlinks for "drivers" (like
> sap-{u8500,dummy}.c, suspend-dummy.c,
> telephony-{dummy,maemo5,maemo6,ofono}.c) and having everything
> built-in and enabled/disabled based on which D-Bus services are
> running on the system (or, if not possible, by using config options).

what do you mean by "running on the system"?

Lucas De Marchi

Re: [PATCH BlueZ] build: Fix make distcheck for input plugin

[Szymon Janc]

Hi,

> > Humn... maybe we need to review these CPPFLAGS for plugins. Appending
> > it to AM_CPPFLAGS means that every single source file has
> > "-I$(srcdir)/profiles/input". Even those sources not at all related to
> > HOGPLUGIN.
> >
> > However the only way I can think to fix it is by creating convenience
> > libs since autofoo doesn't support CPPFLAGS per source file.
> 
> I agree it is not the best solution. Actually, I think we can overcome
> the problem completely by getting rid of symlinks for "drivers" (like
> sap-{u8500,dummy}.c, suspend-dummy.c,
> telephony-{dummy,maemo5,maemo6,ofono}.c) and having everything
> built-in and enabled/disabled based on which D-Bus services are
> running on the system (or, if not possible, by using config options).
> This would also help with spotting build breakages, since all BlueZ
> code could be compiled by a single "./bootstrap-configure && make"
> call.

All code is compiled, it is just not linked.

-- 
BR
Szymon Janc

Re: [PATCH BlueZ] build: Fix make distcheck for input plugin

[Anderson Lizardo]

Hi Lucas,

On Tue, Nov 13, 2012 at 8:55 AM, Lucas De Marchi
<lucas.demarchi@profusion.mobi> wrote:
>> I agree it is not the best solution. Actually, I think we can overcome
>> the problem completely by getting rid of symlinks for "drivers" (like
>> sap-{u8500,dummy}.c, suspend-dummy.c,
>> telephony-{dummy,maemo5,maemo6,ofono}.c) and having everything
>> built-in and enabled/disabled based on which D-Bus services are
>> running on the system (or, if not possible, by using config options).
>
> what do you mean by "running on the system"?

In situations where it is appropriate, we have a
g_dbus_add_service_watch() which will trigger the support code
specific for that service, instead of relying on enabling the service
support at compile time. In practice the support code will be always
compiled.

For situations where the driver code is not related to any D-Bus
service, a config option (in e.g. /etc/bluetooth/<profile>.conf) could
enable/disable the support. The main benefit here is that there will
be no "dead code" that never gets compiled because bootstrap-configure
is not able to enable all drivers.

Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

Re: [PATCH BlueZ] build: Fix make distcheck for input plugin

[Anderson Lizardo]

Hi Szymon,

On Tue, Nov 13, 2012 at 8:57 AM, Szymon Janc <szymon.janc@tieto.com> wrote:
>> I agree it is not the best solution. Actually, I think we can overcome
>> the problem completely by getting rid of symlinks for "drivers" (like
>> sap-{u8500,dummy}.c, suspend-dummy.c,
>> telephony-{dummy,maemo5,maemo6,ofono}.c) and having everything
>> built-in and enabled/disabled based on which D-Bus services are
>> running on the system (or, if not possible, by using config options).
>> This would also help with spotting build breakages, since all BlueZ
>> code could be compiled by a single "./bootstrap-configure && make"
>> call.
>
> All code is compiled, it is just not linked.

Sorry, I meant "linked" instead of "compiled" on my explanation. See
the original thread where this was first brought up:

http://thread.gmane.org/gmane.linux.bluez.kernel/30175/focus=30190

It is easier for testing code if it can be enabled/disabled at
runtime, instead of rebuilding with different configure options.

Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil