[OE-core] [PATCH] cmake-native: Depend on ncurses-native too

[Richard Purdie]

On Tue, 2014-04-01 at 11:11 +0100, Mike Crowe wrote:
> On Tuesday 01 April 2014 at 10:31:59 +0100, Richard Purdie wrote:
> > On Tue, 2014-04-01 at 10:16 +0100, Mike Crowe wrote:
> > > cmake detects the presence of curses automatically during configure so
> > > cmake-native must also depend on ncurses-native to stop it being removed
> > > from the sysroot during the build.
> > > 
> > > Signed-off-by: Mike Crowe <mac at mcrowe.com>
> > > ---
> > >  meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > 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 08b2c02..8d93b9a 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
> > > @@ -2,7 +2,7 @@ require cmake.inc
> > >  inherit native
> > >  
> > >  # Using cmake's internal libarchive, so some dependencies are needed
> > > -DEPENDS += "bzip2-native zlib-native"
> > > +DEPENDS += "bzip2-native zlib-native ncurses-native"
> > >  
> > >  SRC_URI += "file://cmlibarchive-disable-ext2fs.patch"
> > >  
> > 
> > What does an ncurses enabled cmake give us that is desirable?
> 
> I'm not really sure.
> 
> CMake's bootstrap configure script detects curses and tries to use it which
> causes build failures if curses has gone missing in the meantime.
> 
> In the failure I saw bitbake was building cmake-native and ncurses-native
> in parallel in a tree that had previously been used to build for a
> different machine. This caused curses.h to be present during
> cmake-native.do_configure but go missing before or during
> cmake-native.do_compile.
> 
> 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.

I'd much prefer to disable the need for curses if we can since the more
convoluted the dependency chain, the longer our build times. If we don't
need this, it would be much nicer to disable it, even if we have to
patch it out.

Cheers,

Richard