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. 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. -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
