<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 10, 2014 at 7:45 AM, Mike Crowe <span dir="ltr"><<a href="mailto:mac@mcrowe.com" target="_blank">mac@mcrowe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Tuesday 08 April 2014 at 09:37:32 -0700, Chris Larson wrote:<br>
> On Tue, Apr 8, 2014 at 6:51 AM, Mike Crowe <<a href="mailto:mac@mcrowe.com">mac@mcrowe.com</a>> wrote:<br>
><br>
> > The cmake recipe doesn't depend on libacl yet cmake will detect libacl.h<br>
> > and use it by default. This risks build failures if libacl.h is unstaged<br>
> > during the build and it also means that the build cmake will sometimes<br>
> > support ACLs and sometimes not.<br>
> ><br>
><br>
> Is this not also a concern for the non-native recipe? And wouldn't it be<br>
> better yet to use PACKAGECONFIG, rather than hardcoding the disable of acl<br>
> support?<br>
<br>
</div>libacl is used by cmake's internal libarchive implementation. The<br>
cmake-native recipe makes use of that but the non-native cmake recipe<br>
depends on the real libarchive so cmake doesn't use libacl itself.<br></blockquote><div><br></div><div>Ah, understood. Nevermind then, it's likely not worthwhile to switch it to PACKAGECONFIG, but I wanted to confirm. Thanks!</div>
</div>-- <br>Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics
</div></div>