Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Mike Crowe <mac@mcrowe.com>
To: Khem Raj <raj.khem@gmail.com>,
	Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] cmake-native: Depend on ncurses-native too
Date: Wed, 2 Apr 2014 10:14:04 +0100	[thread overview]
Message-ID: <20140402091404.GA29076@mcrowe.com> (raw)
In-Reply-To: <CAMKF1soedDRPPiJTLnqi9SjGHhLwTrZ3cMx3EJV+TXSDqabOiQ@mail.gmail.com>

On Tuesday 01 April 2014 at 21:59:34 -0700, Khem Raj wrote:
> On Tue, Apr 1, 2014 at 3:11 AM, Mike Crowe <mac@mcrowe.com> wrote:
> > It seems to be possible to disable building the "CursesDialog" component to
> > remove the need for ncurses but I couldn't immediately see how to do that
> > for a bootstrap build.
> >
> > The non-native cmake recipe depends on ncurses even though it passes
> > -DBUILD_CursesDialog=0.
> 
> you need to disable it completely in CMakefile.txt, just that define
> does not suffice you might try something like
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-util/cmake/files/cmake-2.8.10-libform.patch?diff_format=f&view=markup

As far as I can tell (by poisoning curses.h in the sysroot) the non-native
cmake build does successfully avoid using curses by specifying
-DBUILD_CursesDialog=0. I have successfully tested removing the
ncurses dependency from the recipe too.

The cmake-native bootstrap procedure means that it is not possible to get
that parameter through to the ultimate cmake native build. So I came up
with this patch:

--- 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

If I apply this for cmake-native then it also doesn't require curses
(tested with the same poisoning.)

The Gentoo patch may be somewhat safer in the long term because it does a
better job of ensuring that the curses dependency can't come back with
newer cmake versions; it is more likely that the patch would not apply or
the link would fail.

Do you prefer the one line patch above or the Gentoo one?

Thanks.

Mike.


  reply	other threads:[~2014-04-02  9:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-01  9:16 [PATCH] cmake-native: Depend on ncurses-native too Mike Crowe
2014-04-01  9:31 ` Richard Purdie
2014-04-01 10:11   ` Mike Crowe
2014-04-01 10:46     ` Richard Purdie
2014-04-02  4:59     ` Khem Raj
2014-04-02  9:14       ` Mike Crowe [this message]
2014-04-02 15:15         ` Khem Raj
2014-04-02 15:17         ` Khem Raj
2014-04-02 16:04           ` [PATCH 1/2] cmake-native: Stop building ccmake Mike Crowe
2014-04-02 16:04             ` [PATCH 2/2] cmake: Remove dependency on ncurses Mike Crowe
2014-04-03 10:44       ` cmake-native also depends on acl-native (was Re: cmake-native: Depend on ncurses-native too) Mike Crowe
2014-04-06 11:57         ` Richard Purdie
2014-04-02  4:53   ` [PATCH] cmake-native: Depend on ncurses-native too Khem Raj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140402091404.GA29076@mcrowe.com \
    --to=mac@mcrowe.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox