[Buildroot] [PATCH] libcap: Add optional support for libattr capabilities

[Buildroot] [PATCH] libcap: Add optional support for libattr capabilities

[Markos Chandras]

From: Markos Chandras <markos.chandras@imgtec.com>

libcap can optionally link to libattr to support extra
file capabilities. Link to this library and pull it as
dependency if BR2_PACKAGE_ATTR is selected.

Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
---
 package/libcap/libcap.mk |   17 ++++++++++++-----
 1 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/package/libcap/libcap.mk b/package/libcap/libcap.mk
index dcd3a18..c319335 100644
--- a/package/libcap/libcap.mk
+++ b/package/libcap/libcap.mk
@@ -15,18 +15,25 @@ LIBCAP_LICENSE_FILES = License
 LIBCAP_DEPENDENCIES = host-libcap
 LIBCAP_INSTALL_STAGING = YES
 
+ifeq ($(BR2_PACKAGE_ATTR),y)
+	LIBCAP_DEPENDENCIES += host-attr attr
+	HAVE_LIBATTR = yes
+else
+	HAVE_LIBATTR = no
+endif
+
 define LIBCAP_BUILD_CMDS
 	$(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D) \
-		LIBATTR=no BUILD_CC="$(HOSTCC)" BUILD_CFLAGS="$(HOST_CFLAGS)"
+		LIBATTR=$(HAVE_LIBATTR) BUILD_CC="$(HOSTCC)" BUILD_CFLAGS="$(HOST_CFLAGS)"
 endef
 
 define LIBCAP_INSTALL_STAGING_CMDS
-	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) LIBATTR=no DESTDIR=$(STAGING_DIR) \
+	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) LIBATTR=$(HAVE_LIBATTR) DESTDIR=$(STAGING_DIR) \
 		prefix=/usr lib=lib install
 endef
 
 define LIBCAP_INSTALL_TARGET_CMDS
-	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) LIBATTR=no DESTDIR=$(TARGET_DIR) \
+	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) LIBATTR=$(HAVE_LIBATTR) DESTDIR=$(TARGET_DIR) \
 		prefix=/usr lib=lib install
 endef
 
@@ -38,11 +45,11 @@ endef
 LIBCAP_POST_PATCH_HOOKS += LIBCAP_DISABLE_PROGS
 
 define HOST_LIBCAP_BUILD_CMDS
-	$(HOST_MAKE_ENV) $(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D) LIBATTR=no
+	$(HOST_MAKE_ENV) $(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D) LIBATTR=$(HAVE_LIBATTR)
 endef
 
 define HOST_LIBCAP_INSTALL_CMDS
-	$(HOST_MAKE_ENV) $(MAKE) -C $(@D) LIBATTR=no DESTDIR=$(HOST_DIR) \
+	$(HOST_MAKE_ENV) $(MAKE) -C $(@D) LIBATTR=$(HAVE_LIBATTR) DESTDIR=$(HOST_DIR) \
 		prefix=/usr lib=lib install
 endef
 
-- 
1.7.1

[Buildroot] [PATCH] libcap: Add optional support for libattr capabilities

[Thomas Petazzoni]

Dear Markos Chandras,

On Fri, 15 Mar 2013 16:22:38 +0000, Markos Chandras wrote:

> +ifeq ($(BR2_PACKAGE_ATTR),y)
> +	LIBCAP_DEPENDENCIES += host-attr attr

We don't generally tie dependencies of host packages on
BR2_PACKAGE_<foo> options. Is there a specific reason that requires
host-libcap to be built against host-attr?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH] libcap: Add optional support for libattr capabilities

[Markos Chandras]

On 16 March 2013 18:11, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Markos Chandras,
>
> On Fri, 15 Mar 2013 16:22:38 +0000, Markos Chandras wrote:
>
>> +ifeq ($(BR2_PACKAGE_ATTR),y)
>> +     LIBCAP_DEPENDENCIES += host-attr attr
>
> We don't generally tie dependencies of host packages on
> BR2_PACKAGE_<foo> options. Is there a specific reason that requires
> host-libcap to be built against host-attr?
>
Hi Thomas,

No special reason, just making sure the host-libcap is built the same
way as the target one does so it can support the same functionality.
Should I resend this patch but only changing the way the target libcap is built?

-- 
Regards,
Markos Chandras

[Buildroot] [PATCH] libcap: Add optional support for libattr capabilities

[Peter Korsgaard]

>>>>> "Markos" == Markos Chandras <markos.chandras@gmail.com> writes:

 >>> +ifeq ($(BR2_PACKAGE_ATTR),y)
 >>> +     LIBCAP_DEPENDENCIES += host-attr attr
 >> 
 >> We don't generally tie dependencies of host packages on
 >> BR2_PACKAGE_<foo> options. Is there a specific reason that requires
 >> host-libcap to be built against host-attr?
 >> 
 Markos> Hi Thomas,

 Markos> No special reason, just making sure the host-libcap is built
 Markos> the same way as the target one does so it can support the same
 Markos> functionality.  Should I resend this patch but only changing
 Markos> the way the target libcap is built?

I would say so. We don't even currently have a host-attr package, so I'm
not sure how it could work?

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] libcap: Add optional support for libattr capabilities

[Markos Chandras]

On 18 March 2013 20:30, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Markos" == Markos Chandras <markos.chandras@gmail.com> writes:
>
>  >>> +ifeq ($(BR2_PACKAGE_ATTR),y)
>  >>> +     LIBCAP_DEPENDENCIES += host-attr attr
>  >>
>  >> We don't generally tie dependencies of host packages on
>  >> BR2_PACKAGE_<foo> options. Is there a specific reason that requires
>  >> host-libcap to be built against host-attr?
>  >>
>  Markos> Hi Thomas,
>
>  Markos> No special reason, just making sure the host-libcap is built
>  Markos> the same way as the target one does so it can support the same
>  Markos> functionality.  Should I resend this patch but only changing
>  Markos> the way the target libcap is built?
>
> I would say so. We don't even currently have a host-attr package, so I'm
> not sure how it could work?
>
> --
> Bye, Peter Korsgaard

Hi Peter,

Ok I will submit a new patch changing only the target libcap to link
with libattr.

-- 
Regards,
Markos Chandras