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

[Mike Crowe <mac@mcrowe.com>]

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.