On Wed, Apr 3, 2019 at 8:28 PM Nathan Rossi <nat...@nathanrossi.com> wrote: > > On Thu, 4 Apr 2019 at 03:02, Khem Raj <raj.k...@gmail.com> wrote: > > > > On Wed, Apr 3, 2019 at 2:26 AM Bach, Pascal <pascal.b...@siemens.com> wrote: > > > > > > > > > > > Enable the building of the curses based ui for cmake. This depends on > > > > ncurses. > > > > > > I think this is acceptable. It might also be useful for people wanting to > > > use ccmake inside an SDK. > > Just to be clear, this change only affects cmake-native, the recipe > for target/nativesdk is unchanged. Although interestingly the cmake > (target/nativesdk) recipe already depends on ncurses (despite > disabling ccmake). > > > > > > > > Adding dependencies do serialize builds and might have penalty on > > build time, better is to turn this into a packageconfig > > option and keep it disabled by default. > > I can rework this patch to make it a PACKAGECONFIG option. However the > reason for enabling ccmake by default is due to the addition of the > ccmake bbclass in this series, which relies on having ccmake available > in the native sysroot. Having to override PACKAGECONFIG to use the > ccmake class seemed broken (since it is not particularly a distro > config). > > I could not find a good example of this sort of requirement for > configuration for any other bbclass except for maybe > gobject-introspection (which relies on qemu-native configured > correctly to have linux-user for the target). > > Another approach I considered to have this working without requiring > the user to setup PACKAGECONFIG would be to have a "ccmake-native" > recipe which built the ccmake binary. But this seemed like it would be > extra maintenance burden compared to this patch which has minimal > build time overhead. >
this seems fine, if the number of recipes needing this bbclass are far less than one the needing cmake bbclass. > Regards, > Nathan > > > > > > > Signed-off-by: Nathan Rossi <nat...@nathanrossi.com> > > > > --- > > > > This patch suggests enabling this in the cmake-native recipe, however > > > > this > > > > might be undesirable for bootstrapping reasons. Whilst ccmake is not > > > > used > > > > normally the added dependency on ncurses is likely required for other > > > > parts > > > > of the build so impact on build ordering and time should be relatively > > > > minimal. > > > > > > > > Changes in v2: > > > > - None > > > > --- > > > > meta/recipes-devtools/cmake/cmake-native_3.14.0.bb | 5 ++--- > > > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb > > > > b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb > > > > index fedcf3d4bd..b2952ee5f5 100644 > > > > --- a/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb > > > > +++ b/meta/recipes-devtools/cmake/cmake-native_3.14.0.bb > > > > @@ -1,7 +1,7 @@ > > > > require cmake.inc > > > > inherit native > > > > > > > > -DEPENDS += "bzip2-replacement-native expat-native xz-native zlib-native > > > > curl-native" > > > > +DEPENDS += "bzip2-replacement-native expat-native xz-native zlib-native > > > > curl-native ncurses-native" > > > > > > > > SRC_URI += "file://OEToolchainConfig.cmake \ > > > > file://environment.d-cmake.sh \ @@ -13,10 +13,9 @@ SRC_URI > > > > += > > > > "file://OEToolchainConfig.cmake \ B = "${WORKDIR}/build" > > > > do_configure[cleandirs] = "${B}" > > > > > > > > -# Disable ccmake since we don't depend on ncurses CMAKE_EXTRACONF = > > > > "\ > > > > -DCMAKE_LIBRARY_PATH=${STAGING_LIBDIR_NATIVE} \ > > > > - -DBUILD_CursesDialog=0 \ > > > > + -DBUILD_CursesDialog=1 \ > > > > -DCMAKE_USE_SYSTEM_LIBRARIES=1 \ > > > > -DCMAKE_USE_SYSTEM_LIBRARY_JSONCPP=0 \ > > > > -DCMAKE_USE_SYSTEM_LIBRARY_LIBARCHIVE=0 \ > > > > --- > > > > 2.20.1 > > > > -- > > > > _______________________________________________ > > > > Openembedded-core mailing list > > > > Openembedded-core@lists.openembedded.org > > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > -- > > > _______________________________________________ > > > Openembedded-core mailing list > > > Openembedded-core@lists.openembedded.org > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core