[PATCH 1/2] cmake: Improve method for not building ccmake

[PATCH 1/2] cmake: Improve method for not building ccmake

[Mike Crowe]

In commit 4bee0a93ed985b38c6b4eb605d8e16f5d7c82d51 I introduced an
unnecessary patch to do something that can easily be done without
patching.

The argument to disable building ccmake can be passed to configure provided
it is preceded by "--".

Signed-off-by: Mike Crowe <mac@mcrowe.com>
---
 meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb    |  6 +++++-
 meta/recipes-devtools/cmake/cmake.inc                   |  5 ++++-
 .../cmake/cmake/disable-bootstrap-cursesdialog.patch    | 17 -----------------
 3 files changed, 9 insertions(+), 19 deletions(-)
 delete mode 100644 meta/recipes-devtools/cmake/cmake/disable-bootstrap-cursesdialog.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 d032cb9..638c074 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
@@ -6,8 +6,12 @@ DEPENDS += "bzip2-native zlib-native"
 
 SRC_URI += "\
     file://cmlibarchive-disable-ext2fs.patch \
-    file://disable-bootstrap-cursesdialog.patch \
 "
 
 SRC_URI[md5sum] = "17c6513483d23590cbce6957ec6d1e66"
 SRC_URI[sha256sum] = "8c6574e9afabcb9fc66f463bb1f2f051958d86c85c37fccf067eb1a44a120e5e"
+
+# Disable ccmake since we don't depend on ncurses
+CMAKE_EXTRACONF = "\
+    -DBUILD_CursesDialog=0 \
+"
diff --git a/meta/recipes-devtools/cmake/cmake.inc b/meta/recipes-devtools/cmake/cmake.inc
index a0fcf49..8592a23 100644
--- a/meta/recipes-devtools/cmake/cmake.inc
+++ b/meta/recipes-devtools/cmake/cmake.inc
@@ -43,6 +43,9 @@ do_configure_prepend() {
 	sed -i 's/^find_package(Qt5Widgets QUIET)/#find_package(Qt5Widgets QUIET)/g' ${S}/Source/QtDialog/CMakeLists.txt
 }
 
+# Extra flags to pass to cmake invoked by bootstrap
+CMAKE_EXTRACONF = ""
+
 do_configure () {
-	./configure --prefix=${prefix}
+	./configure --prefix=${prefix} -- ${CMAKE_EXTRACONF}
 }
diff --git a/meta/recipes-devtools/cmake/cmake/disable-bootstrap-cursesdialog.patch b/meta/recipes-devtools/cmake/cmake/disable-bootstrap-cursesdialog.patch
deleted file mode 100644
index 9d378fb..0000000
--- a/meta/recipes-devtools/cmake/cmake/disable-bootstrap-cursesdialog.patch
+++ /dev/null
@@ -1,17 +0,0 @@
-Disable building CursesDialog so that cmake-native doesn't have to
-depend on ncurses-native.
-
-Upstream-status: Inappropriate [disable feature]
-
-Signed-off-by: Mike Crowe <mac@mcrowe.com>
-
---- cmake-2.8.12.2/bootstrap~	2014-01-16 17:15:09.000000000 +0000
-+++ cmake-2.8.12.2/bootstrap	2014-04-01 21:27:23.841996822 +0100
-@@ -1578,6 +1578,7 @@ export MAKE
- 
- # Run bootstrap CMake to configure real CMake
- cmake_options="-DCMAKE_BOOTSTRAP=1"
-+cmake_options="${cmake_options} -DBUILD_CursesDialog=0"
- if [ -n "${cmake_verbose}" ]; then
-   cmake_options="${cmake_options} -DCMAKE_VERBOSE_MAKEFILE=1"
- fi
-- 
1.9.1

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

[Mike Crowe]

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(+)

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 \
 "
-- 
1.9.1

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

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

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?
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 1025 bytes --]

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

[Mike Crowe]

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.

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

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

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!
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 1664 bytes --]