Patchwork [2/2] cmake: Avoid accidentally including libacl.h

login
register
mail settings
Submitter Mike Crowe
Date April 8, 2014, 1:51 p.m.
Message ID <1396965083-15863-2-git-send-email-mac@mcrowe.com>
Download mbox | patch
Permalink /patch/70279/
State New
Headers show

Comments

Mike Crowe - April 8, 2014, 1:51 p.m.
The cmake recipe doesn't depend on libacl yet cmake will detect libacl.h
and use it by default. This risks build failures if libacl.h is unstaged
during the build and it also means that the build cmake will sometimes
support ACLs and sometimes not.

This can be avoided by setting ENABLE_ACL=0 but until the fix for
http://cmake.org/Bug/view.php?id=14866 is released we also need to set
HAVE_ACL_LIBACL_H=0.

Signed-off-by: Mike Crowe <mac@mcrowe.com>
---
 meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb | 1 +
 1 file changed, 1 insertion(+)
Chris Larson - April 8, 2014, 4:37 p.m.
On Tue, Apr 8, 2014 at 6:51 AM, Mike Crowe <mac@mcrowe.com> wrote:

> The cmake recipe doesn't depend on libacl yet cmake will detect libacl.h
> and use it by default. This risks build failures if libacl.h is unstaged
> during the build and it also means that the build cmake will sometimes
> support ACLs and sometimes not.
>

Is this not also a concern for the non-native recipe? And wouldn't it be
better yet to use PACKAGECONFIG, rather than hardcoding the disable of acl
support?
Mike Crowe - April 10, 2014, 2:45 p.m.
On Tuesday 08 April 2014 at 09:37:32 -0700, Chris Larson wrote:
> On Tue, Apr 8, 2014 at 6:51 AM, Mike Crowe <mac@mcrowe.com> wrote:
> 
> > The cmake recipe doesn't depend on libacl yet cmake will detect libacl.h
> > and use it by default. This risks build failures if libacl.h is unstaged
> > during the build and it also means that the build cmake will sometimes
> > support ACLs and sometimes not.
> >
> 
> Is this not also a concern for the non-native recipe? And wouldn't it be
> better yet to use PACKAGECONFIG, rather than hardcoding the disable of acl
> support?

libacl is used by cmake's internal libarchive implementation. The
cmake-native recipe makes use of that but the non-native cmake recipe
depends on the real libarchive so cmake doesn't use libacl itself.

If DISTRO_FEATURES makes sense for native packages then I can try and work
out how to use PACKAGECONFIG for this.

It looks like the cmake-native not setting the CMAKE_USE_SYSTEM_LIBRARIES
option stops cmake searching around for libarchive, curl, etc. and causing
problems with those libraries too.

I'm afraid that I know very little about cmake - I was just trying to fix
some build problems we were seeing with it. Someone with more cmake
knowledge may well know of a better way to solve this.

Thanks.

Mike.
Chris Larson - April 10, 2014, 2:50 p.m.
On Thu, Apr 10, 2014 at 7:45 AM, Mike Crowe <mac@mcrowe.com> wrote:

> On Tuesday 08 April 2014 at 09:37:32 -0700, Chris Larson wrote:
> > On Tue, Apr 8, 2014 at 6:51 AM, Mike Crowe <mac@mcrowe.com> wrote:
> >
> > > The cmake recipe doesn't depend on libacl yet cmake will detect
> libacl.h
> > > and use it by default. This risks build failures if libacl.h is
> unstaged
> > > during the build and it also means that the build cmake will sometimes
> > > support ACLs and sometimes not.
> > >
> >
> > Is this not also a concern for the non-native recipe? And wouldn't it be
> > better yet to use PACKAGECONFIG, rather than hardcoding the disable of
> acl
> > support?
>
> libacl is used by cmake's internal libarchive implementation. The
> cmake-native recipe makes use of that but the non-native cmake recipe
> depends on the real libarchive so cmake doesn't use libacl itself.
>

Ah, understood. Nevermind then, it's likely not worthwhile to switch it to
PACKAGECONFIG, but I wanted to confirm. Thanks!

Patch

diff --git a/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb b/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb
index 638c074..cd6b1d8 100644
--- a/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb
+++ b/meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb
@@ -14,4 +14,5 @@  SRC_URI[sha256sum] = "8c6574e9afabcb9fc66f463bb1f2f051958d86c85c37fccf067eb1a44a
 # Disable ccmake since we don't depend on ncurses
 CMAKE_EXTRACONF = "\
     -DBUILD_CursesDialog=0 \
+    -DENABLE_ACL=0 -DHAVE_ACL_LIBACL_H=0 \
 "