On Fri, 5 Apr 2019 at 02:31, Khem Raj <raj.k...@gmail.com> wrote:
>
>
>
> On Wed, Apr 3, 2019 at 9:36 PM Nathan Rossi <nat...@nathanrossi.com> wrote:
>>
>> On Thu, 4 Apr 2019 at 13:48, Khem Raj <raj.k...@gmail.com> wrote:
>> >
>> > 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.
>>
>> Just to clarify, are you suggesting that making a ccmake-native recipe
>> would be fine? Or that requiring the PACKAGECONFIG setup would be
>> acceptable/preferred?
>
>
> I don’t have enough of data to lean on either way
> Are we adding this to every cmake using recipes benefit or is it only a
> handful
At the moment there is no intention to enable the ccmake bbclass in
any general or board sense. Mainly leaving it as a per recipe opt in
for recipes where user configuration is desired.
Thanks,
Nathan
>>
>>
>>
>> Thanks,
>> Nathan
>>
>> >
>> > > 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
