On Thu, Apr 10, 2014 at 7:45 AM, Mike Crowe <[email protected]> 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 <[email protected]> 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! -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
