Revert "lzop: remove recipe from oe-core"

This reverts commit dea5e8863792dc7bb3324b543e04da4c94a060aa.

The original commit claims that lzop is unused in OE-core.
That is not correct, the following places still use it and
became unbuildable now:
"
meta/classes-recipe/image_types.bbclass:CONVERSION_CMD:lzo = "lzop -9 ${IMAGE_NAME}.${type}"
meta/classes-recipe/image_types.bbclass:CONVERSION_DEPENDS_lzo = "lzop-native"
meta/classes-recipe/kernel-uboot.bbclass:                       lzop -9 linux.bin
meta/classes-recipe/kernel.bbclass:DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.lzo", "lzop-native", "", d)}"
meta/classes-recipe/kernel.bbclass:                             lzop -df ${B}/usr/${INITRAMFS_IMAGE_NAME}.$img
"

Furthermore, LZO is the best compromise between kernel decompression
time and size on low end ARM systems, that is why it is often used
with e.g.:
FIT_KERNEL_COMP_ALG = "lzo"
FIT_KERNEL_COMP_ALG_EXTENSION = ".lzo"

Reinstate the package to avoid breaking this use case.

Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Ross Burton <ross.burton@arm.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 meta/conf/distro/include/maintainers.inc    |   1 +
 meta/recipes-support/lzop/lzop/acinclude.m4 | 390 ++++++++++++++++++++
 meta/recipes-support/lzop/lzop_1.04.bb      |  27 ++
 3 files changed, 418 insertions(+)
 create mode 100644 meta/recipes-support/lzop/lzop/acinclude.m4
 create mode 100644 meta/recipes-support/lzop/lzop_1.04.bb

I'm not sure I agree. It's totally ok to depend on things that are not
in core, if they're not enabled or tested on the AB by default, and
what layer they're in is well known (meta-oe in this case).

Alex

On Thu, 23 Nov 2023 at 01:46, Marek Vasut <marex@denx.de> wrote:
>
> This reverts commit dea5e8863792dc7bb3324b543e04da4c94a060aa.
>
> The original commit claims that lzop is unused in OE-core.
> That is not correct, the following places still use it and
> became unbuildable now:
> "
> meta/classes-recipe/image_types.bbclass:CONVERSION_CMD:lzo = "lzop -9 ${IMAGE_NAME}.${type}"
> meta/classes-recipe/image_types.bbclass:CONVERSION_DEPENDS_lzo = "lzop-native"
> meta/classes-recipe/kernel-uboot.bbclass:                       lzop -9 linux.bin
> meta/classes-recipe/kernel.bbclass:DEPENDS += "${@bb.utils.contains("INITRAMFS_FSTYPES", "cpio.lzo", "lzop-native", "", d)}"
> meta/classes-recipe/kernel.bbclass:                             lzop -df ${B}/usr/${INITRAMFS_IMAGE_NAME}.$img
> "
>
> Furthermore, LZO is the best compromise between kernel decompression
> time and size on low end ARM systems, that is why it is often used
> with e.g.:
> FIT_KERNEL_COMP_ALG = "lzo"
> FIT_KERNEL_COMP_ALG_EXTENSION = ".lzo"
>
> Reinstate the package to avoid breaking this use case.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> Cc: Ross Burton <ross.burton@arm.com>
> Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  meta/conf/distro/include/maintainers.inc    |   1 +
>  meta/recipes-support/lzop/lzop/acinclude.m4 | 390 ++++++++++++++++++++
>  meta/recipes-support/lzop/lzop_1.04.bb      |  27 ++
>  3 files changed, 418 insertions(+)
>  create mode 100644 meta/recipes-support/lzop/lzop/acinclude.m4
>  create mode 100644 meta/recipes-support/lzop/lzop_1.04.bb
>
> diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc
> index 35f8a72fa4..e95ab59d0d 100644
> --- a/meta/conf/distro/include/maintainers.inc
> +++ b/meta/conf/distro/include/maintainers.inc
> @@ -484,6 +484,7 @@ RECIPE_MAINTAINER:pn-lua = "Alexander Kanavin <alex.kanavin@gmail.com>"
>  RECIPE_MAINTAINER:pn-lz4 = "Denys Dmytriyenko <denis@denix.org>"
>  RECIPE_MAINTAINER:pn-lzo = "Denys Dmytriyenko <denis@denix.org>"
>  RECIPE_MAINTAINER:pn-lzip = "Denys Dmytriyenko <denis@denix.org>"
> +RECIPE_MAINTAINER:pn-lzop = "Denys Dmytriyenko <denis@denix.org>"
>  RECIPE_MAINTAINER:pn-m4 = "Robert Yang <liezhi.yang@windriver.com>"
>  RECIPE_MAINTAINER:pn-m4-native = "Robert Yang <liezhi.yang@windriver.com>"
>  RECIPE_MAINTAINER:pn-make = "Robert Yang <liezhi.yang@windriver.com>"
> diff --git a/meta/recipes-support/lzop/lzop/acinclude.m4 b/meta/recipes-support/lzop/lzop/acinclude.m4
> new file mode 100644
> index 0000000000..0029c19c7d
> --- /dev/null
> +++ b/meta/recipes-support/lzop/lzop/acinclude.m4
> @@ -0,0 +1,390 @@
> +
> +AC_DEFUN([mfx_ACC_CHECK_ENDIAN], [
> +AC_C_BIGENDIAN([AC_DEFINE(ACC_ABI_BIG_ENDIAN,1,[Define to 1 if your machine is big endian.])],[AC_DEFINE(ACC_ABI_LITTLE_ENDIAN,1,[Define to 1 if your machine is little endian.])])
> +])#
> +
> +AC_DEFUN([mfx_ACC_CHECK_HEADERS], [
> +AC_HEADER_TIME
> +AC_CHECK_HEADERS([assert.h ctype.h dirent.h errno.h fcntl.h float.h limits.h malloc.h memory.h setjmp.h signal.h stdarg.h stddef.h stdint.h stdio.h stdlib.h string.h strings.h time.h unistd.h utime.h sys/stat.h sys/time.h sys/types.h sys/wait.h])
> +])#
> +
> +AC_DEFUN([mfx_ACC_CHECK_FUNCS], [
> +AC_CHECK_FUNCS(access alloca atexit atoi atol chmod chown ctime difftime fstat gettimeofday gmtime localtime longjmp lstat memcmp memcpy memmove memset mktime qsort raise setjmp signal snprintf strcasecmp strchr strdup strerror strftime stricmp strncasecmp strnicmp strrchr strstr time umask utime vsnprintf)
> +])#
> +
> +
> +AC_DEFUN([mfx_ACC_CHECK_SIZEOF], [
> +AC_CHECK_SIZEOF(short)
> +AC_CHECK_SIZEOF(int)
> +AC_CHECK_SIZEOF(long)
> +
> +AC_CHECK_SIZEOF(long long)
> +AC_CHECK_SIZEOF(__int16)
> +AC_CHECK_SIZEOF(__int32)
> +AC_CHECK_SIZEOF(__int64)
> +
> +AC_CHECK_SIZEOF(void *)
> +AC_CHECK_SIZEOF(size_t)
> +AC_CHECK_SIZEOF(ptrdiff_t)
> +])#
> +
> +
> +# /***********************************************************************
> +# // Check for ACC_conformance
> +# ************************************************************************/
> +
> +AC_DEFUN([mfx_ACC_ACCCHK], [
> +mfx_tmp=$1
> +mfx_save_CPPFLAGS=$CPPFLAGS
> +dnl in Makefile.in $(INCLUDES) will be before $(CPPFLAGS), so we mimic this here
> +test "X$mfx_tmp" = "X" || CPPFLAGS="$mfx_tmp $CPPFLAGS"
> +
> +AC_MSG_CHECKING([whether your compiler passes the ACC conformance test])
> +
> +AC_LANG_CONFTEST([AC_LANG_PROGRAM(
> +[[#define ACC_CONFIG_NO_HEADER 1
> +#include "acc/acc.h"
> +#include "acc/acc_incd.h"
> +#undef ACCCHK_ASSERT
> +#define ACCCHK_ASSERT(expr)     ACC_COMPILE_TIME_ASSERT_HEADER(expr)
> +#include "acc/acc_chk.ch"
> +#undef ACCCHK_ASSERT
> +static void test_acc_compile_time_assert(void) {
> +#define ACCCHK_ASSERT(expr)     ACC_COMPILE_TIME_ASSERT(expr)
> +#include "acc/acc_chk.ch"
> +#undef ACCCHK_ASSERT
> +}
> +#undef NDEBUG
> +#include <assert.h>
> +static int test_acc_run_time_assert(int r) {
> +#define ACCCHK_ASSERT(expr)     assert(expr);
> +#include "acc/acc_chk.ch"
> +#undef ACCCHK_ASSERT
> +return r;
> +}
> +]], [[
> +test_acc_compile_time_assert();
> +if (test_acc_run_time_assert(1) != 1) return 1;
> +]]
> +)])
> +
> +mfx_tmp=FAILED
> +_AC_COMPILE_IFELSE([], [mfx_tmp=yes])
> +rm -f conftest.$ac_ext conftest.$ac_objext
> +
> +CPPFLAGS=$mfx_save_CPPFLAGS
> +
> +AC_MSG_RESULT([$mfx_tmp])
> +case x$mfx_tmp in
> +  xpassed | xyes) ;;
> +  *)
> +    AC_MSG_NOTICE([])
> +    AC_MSG_NOTICE([Your compiler failed the ACC conformance test - for details see ])
> +    AC_MSG_NOTICE([`config.log'. Please check that log file and consider sending])
> +    AC_MSG_NOTICE([a patch or bug-report to <${PACKAGE_BUGREPORT}>.])
> +    AC_MSG_NOTICE([Thanks for your support.])
> +    AC_MSG_NOTICE([])
> +    AC_MSG_ERROR([ACC conformance test failed. Stop.])
> +dnl    AS_EXIT
> +    ;;
> +esac
> +])# mfx_ACC_ACCCHK
> +
> +
> +# /***********************************************************************
> +# // Check for ACC_conformance
> +# ************************************************************************/
> +
> +AC_DEFUN([mfx_MINIACC_ACCCHK], [
> +mfx_tmp=$1
> +mfx_save_CPPFLAGS=$CPPFLAGS
> +dnl in Makefile.in $(INCLUDES) will be before $(CPPFLAGS), so we mimic this here
> +test "X$mfx_tmp" = "X" || CPPFLAGS="$mfx_tmp $CPPFLAGS"
> +
> +AC_MSG_CHECKING([whether your compiler passes the ACC conformance test])
> +
> +AC_LANG_CONFTEST([AC_LANG_PROGRAM(
> +[[#define ACC_CONFIG_NO_HEADER 1
> +#define ACC_WANT_ACC_INCD_H 1
> +#include $2
> +
> +#define ACC_WANT_ACC_CHK_CH 1
> +#undef ACCCHK_ASSERT
> +#define ACCCHK_ASSERT(expr)     ACC_COMPILE_TIME_ASSERT_HEADER(expr)
> +#include $2
> +
> +#define ACC_WANT_ACC_CHK_CH 1
> +#undef ACCCHK_ASSERT
> +#define ACCCHK_ASSERT(expr)     ACC_COMPILE_TIME_ASSERT(expr)
> +static void test_acc_compile_time_assert(void) {
> +#include $2
> +}
> +
> +#undef NDEBUG
> +#include <assert.h>
> +#define ACC_WANT_ACC_CHK_CH 1
> +#undef ACCCHK_ASSERT
> +#define ACCCHK_ASSERT(expr)  assert(expr);
> +static int test_acc_run_time_assert(int r) {
> +#include $2
> +return r;
> +}
> +]], [[
> +test_acc_compile_time_assert();
> +if (test_acc_run_time_assert(1) != 1) return 1;
> +]]
> +)])
> +
> +mfx_tmp=FAILED
> +_AC_COMPILE_IFELSE([], [mfx_tmp=yes])
> +rm -f conftest.$ac_ext conftest.$ac_objext
> +
> +CPPFLAGS=$mfx_save_CPPFLAGS
> +
> +AC_MSG_RESULT([$mfx_tmp])
> +case x$mfx_tmp in
> +  xpassed | xyes) ;;
> +  *)
> +    AC_MSG_NOTICE([])
> +    AC_MSG_NOTICE([Your compiler failed the ACC conformance test - for details see ])
> +    AC_MSG_NOTICE([`config.log'. Please check that log file and consider sending])
> +    AC_MSG_NOTICE([a patch or bug-report to <${PACKAGE_BUGREPORT}>.])
> +    AC_MSG_NOTICE([Thanks for your support.])
> +    AC_MSG_NOTICE([])
> +    AC_MSG_ERROR([ACC conformance test failed. Stop.])
> +dnl    AS_EXIT
> +    ;;
> +esac
> +])# mfx_MINIACC_ACCCHK
> +
> +
> +
> +# serial 1
> +
> +AC_DEFUN([mfx_PROG_CPPFLAGS], [
> +AC_MSG_CHECKING([whether the C preprocessor needs special flags])
> +
> +AC_LANG_CONFTEST([AC_LANG_PROGRAM(
> +[[#include <limits.h>
> +#if (32767 >= 4294967295ul) || (65535u >= 4294967295ul)
> +#  include "your C preprocessor is broken 1"
> +#elif (0xffffu == 0xfffffffful)
> +#  include "your C preprocessor is broken 2"
> +#elif (32767 >= ULONG_MAX) || (65535u >= ULONG_MAX)
> +#  include "your C preprocessor is broken 3"
> +#endif
> +]], [[ ]]
> +)])
> +
> +mfx_save_CPPFLAGS=$CPPFLAGS
> +mfx_tmp=ERROR
> +for mfx_arg in "" -no-cpp-precomp
> +do
> +  CPPFLAGS="$mfx_arg $mfx_save_CPPFLAGS"
> +  _AC_COMPILE_IFELSE([],
> +[mfx_tmp=$mfx_arg
> +break])
> +done
> +CPPFLAGS=$mfx_save_CPPFLAGS
> +rm -f conftest.$ac_ext conftest.$ac_objext
> +case x$mfx_tmp in
> +  x)
> +    AC_MSG_RESULT([none needed]) ;;
> +  xERROR)
> +    AC_MSG_RESULT([ERROR])
> +    AC_MSG_ERROR([your C preprocessor is broken - for details see config.log])
> +    ;;
> +  *)
> +    AC_MSG_RESULT([$mfx_tmp])
> +    CPPFLAGS="$mfx_tmp $CPPFLAGS"
> +    ;;
> +esac
> +])# mfx_PROG_CPPFLAGS
> +
> +
> +
> +# serial 3
> +
> +AC_DEFUN([mfx_CHECK_HEADER_SANE_LIMITS_H], [
> +AC_CACHE_CHECK([whether limits.h is sane],
> +mfx_cv_header_sane_limits_h,
> +[AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <limits.h>
> +#if (32767 >= 4294967295ul) || (65535u >= 4294967295ul)
> +#  if defined(__APPLE__) && defined(__GNUC__)
> +#    error "your preprocessor is broken - use compiler option -no-cpp-precomp"
> +#  else
> +#    include "your preprocessor is broken"
> +#  endif
> +#endif
> +#define MFX_0xffff          0xffff
> +#define MFX_0xffffffffL     4294967295ul
> +#if !defined(CHAR_BIT) || (CHAR_BIT != 8)
> +#  include "error CHAR_BIT"
> +#endif
> +#if !defined(UCHAR_MAX)
> +#  include "error UCHAR_MAX 1"
> +#endif
> +#if !defined(USHRT_MAX)
> +#  include "error USHRT_MAX 1"
> +#endif
> +#if !defined(UINT_MAX)
> +#  include "error UINT_MAX 1"
> +#endif
> +#if !defined(ULONG_MAX)
> +#  include "error ULONG_MAX 1"
> +#endif
> +#if !defined(SHRT_MAX)
> +#  include "error SHRT_MAX 1"
> +#endif
> +#if !defined(INT_MAX)
> +#  include "error INT_MAX 1"
> +#endif
> +#if !defined(LONG_MAX)
> +#  include "error LONG_MAX 1"
> +#endif
> +#if (UCHAR_MAX < 1)
> +#  include "error UCHAR_MAX 2"
> +#endif
> +#if (USHRT_MAX < 1)
> +#  include "error USHRT_MAX 2"
> +#endif
> +#if (UINT_MAX < 1)
> +#  include "error UINT_MAX 2"
> +#endif
> +#if (ULONG_MAX < 1)
> +#  include "error ULONG_MAX 2"
> +#endif
> +#if (UCHAR_MAX < 0xff)
> +#  include "error UCHAR_MAX 3"
> +#endif
> +#if (USHRT_MAX < MFX_0xffff)
> +#  include "error USHRT_MAX 3"
> +#endif
> +#if (UINT_MAX < MFX_0xffff)
> +#  include "error UINT_MAX 3"
> +#endif
> +#if (ULONG_MAX < MFX_0xffffffffL)
> +#  include "error ULONG_MAX 3"
> +#endif
> +#if (USHRT_MAX > UINT_MAX)
> +#  include "error USHRT_MAX vs UINT_MAX"
> +#endif
> +#if (UINT_MAX > ULONG_MAX)
> +#  include "error UINT_MAX vs ULONG_MAX"
> +#endif
> +]], [[
> +#if (USHRT_MAX == MFX_0xffff)
> +{ typedef char a_short2a[1 - 2 * !(sizeof(short) == 2)]; }
> +#elif (USHRT_MAX >= MFX_0xffff)
> +{ typedef char a_short2b[1 - 2 * !(sizeof(short) > 2)]; }
> +#endif
> +#if (UINT_MAX == MFX_0xffff)
> +{ typedef char a_int2a[1 - 2 * !(sizeof(int) == 2)]; }
> +#elif (UINT_MAX >= MFX_0xffff)
> +{ typedef char a_int2b[1 - 2 * !(sizeof(int) > 2)]; }
> +#endif
> +#if (ULONG_MAX == MFX_0xffff)
> +{ typedef char a_long2a[1 - 2 * !(sizeof(long) == 2)]; }
> +#elif (ULONG_MAX >= MFX_0xffff)
> +{ typedef char a_long2b[1 - 2 * !(sizeof(long) > 2)]; }
> +#endif
> +#if (USHRT_MAX == MFX_0xffffffffL)
> +{ typedef char a_short4a[1 - 2 * !(sizeof(short) == 4)]; }
> +#elif (USHRT_MAX >= MFX_0xffffffffL)
> +{ typedef char a_short4b[1 - 2 * !(sizeof(short) > 4)]; }
> +#endif
> +#if (UINT_MAX == MFX_0xffffffffL)
> +{ typedef char a_int4a[1 - 2 * !(sizeof(int) == 4)]; }
> +#elif (UINT_MAX >= MFX_0xffffffffL)
> +{ typedef char a_int4b[1 - 2 * !(sizeof(int) > 4)]; }
> +#endif
> +#if (ULONG_MAX == MFX_0xffffffffL)
> +{ typedef char a_long4a[1 - 2 * !(sizeof(long) == 4)]; }
> +#elif (ULONG_MAX >= MFX_0xffffffffL)
> +{ typedef char a_long4b[1 - 2 * !(sizeof(long) > 4)]; }
> +#endif
> +]])],
> +[mfx_cv_header_sane_limits_h=yes],
> +[mfx_cv_header_sane_limits_h=no])])
> +])
> +
> +# /***********************************************************************
> +# // standard
> +# ************************************************************************/
> +
> +AC_DEFUN([mfx_LZO_CHECK_ENDIAN], [
> +AC_C_BIGENDIAN([AC_DEFINE(LZO_ABI_BIG_ENDIAN,1,[Define to 1 if your machine is big endian.])],[AC_DEFINE(LZO_ABI_LITTLE_ENDIAN,1,[Define to 1 if your machine is little endian.])])
> +])#
> +
> +
> +# /***********************************************************************
> +# //
> +# ************************************************************************/
> +
> +dnl more types which are not yet covered by ACC
> +
> +AC_DEFUN([mfx_CHECK_SIZEOF], [
> +AC_CHECK_SIZEOF(__int32)
> +AC_CHECK_SIZEOF(intmax_t)
> +AC_CHECK_SIZEOF(uintmax_t)
> +AC_CHECK_SIZEOF(intptr_t)
> +AC_CHECK_SIZEOF(uintptr_t)
> +
> +AC_CHECK_SIZEOF(float)
> +AC_CHECK_SIZEOF(double)
> +AC_CHECK_SIZEOF(long double)
> +
> +AC_CHECK_SIZEOF(dev_t)
> +AC_CHECK_SIZEOF(fpos_t)
> +AC_CHECK_SIZEOF(mode_t)
> +AC_CHECK_SIZEOF(off_t)
> +AC_CHECK_SIZEOF(ssize_t)
> +AC_CHECK_SIZEOF(time_t)
> +])#
> +
> +
> +
> +AC_DEFUN([mfx_CHECK_LIB_WINMM], [
> +if test "X$GCC" = Xyes; then
> +case $host_os in
> +cygwin* | mingw* | pw32*)
> +     test "X$LIBS" != "X" && LIBS="$LIBS "
> +     LIBS="${LIBS}-lwinmm" ;;
> +*)
> +     ;;
> +esac
> +fi
> +])#
> +
> +#serial 6
> +
> +dnl From Paul Eggert.
> +
> +# Define ST_MTIM_NSEC to be the nanoseconds member of struct stat's st_mtim,
> +# if it exists.
> +
> +AC_DEFUN([AC_STRUCT_ST_MTIM_NSEC],
> + [AC_CACHE_CHECK([for nanoseconds member of struct stat.st_mtim],
> +   ac_cv_struct_st_mtim_nsec,
> +   [ac_save_CPPFLAGS="$CPPFLAGS"
> +    ac_cv_struct_st_mtim_nsec=no
> +    # tv_nsec -- the usual case
> +    # _tv_nsec -- Solaris 2.6, if
> +    #  (defined _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED == 1
> +    #   && !defined __EXTENSIONS__)
> +    # st__tim.tv_nsec -- UnixWare 2.1.2
> +    for ac_val in tv_nsec _tv_nsec st__tim.tv_nsec; do
> +      CPPFLAGS="$ac_save_CPPFLAGS -DST_MTIM_NSEC=$ac_val"
> +      AC_TRY_COMPILE([#include <sys/types.h>
> +#include <sys/stat.h>], [struct stat s; s.st_mtim.ST_MTIM_NSEC;],
> +        [ac_cv_struct_st_mtim_nsec=$ac_val; break])
> +    done
> +    CPPFLAGS="$ac_save_CPPFLAGS"])
> +
> +  if test $ac_cv_struct_st_mtim_nsec != no; then
> +    AC_DEFINE_UNQUOTED(ST_MTIM_NSEC, $ac_cv_struct_st_mtim_nsec,
> +      [Define to be the nanoseconds member of struct stat's st_mtim,
> +       if it exists.])
> +  fi
> + ]
> +)
> diff --git a/meta/recipes-support/lzop/lzop_1.04.bb b/meta/recipes-support/lzop/lzop_1.04.bb
> new file mode 100644
> index 0000000000..d9b3524b67
> --- /dev/null
> +++ b/meta/recipes-support/lzop/lzop_1.04.bb
> @@ -0,0 +1,27 @@
> +SUMMARY = "Real-time file compressor"
> +DESCRIPTION = "lzop is a compression utility which is designed to be a companion to gzip. \n\
> +It is based on the LZO data compression library and its main advantages over \n\
> +gzip are much higher compression and decompression speed at the cost of some \n\
> +compression ratio. The lzop compression utility was designed with the goals \n\
> +of reliability, speed, portability and with reasonable drop-in compatibility \n\
> +to gzip."
> +HOMEPAGE = "http://www.lzop.org/"
> +DEPENDS += "lzo"
> +
> +LICENSE = "GPL-2.0-or-later"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
> +                    file://src/lzop.c;beginline=5;endline=21;md5=23d767de7754eb24b9e900b025cf7fc8"
> +
> +SRC_URI = "http://www.lzop.org/download/${BP}.tar.gz \
> +           file://acinclude.m4 \
> +          "
> +SRC_URI[md5sum] = "271eb10fde77a0a96b9cbf745e719ddf"
> +SRC_URI[sha256sum] = "7e72b62a8a60aff5200a047eea0773a8fb205caf7acbe1774d95147f305a2f41"
> +
> +inherit autotools
> +
> +do_configure:prepend () {
> +    install -Dm 0644 ${WORKDIR}/acinclude.m4 ${S}/acinclude.m4
> +}
> +
> +BBCLASSEXTEND = "native nativesdk"
> --
> 2.42.0
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#191128): https://lists.openembedded.org/g/openembedded-core/message/191128
> Mute This Topic: https://lists.openembedded.org/mt/102759947/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

On 11/23/23 09:26, Alexander Kanavin wrote:
> I'm not sure I agree. It's totally ok to depend on things that are not
> in core, if they're not enabled or tested on the AB by default, and
> what layer they're in is well known (meta-oe in this case).

The lzop is called in oe-core and I was under the impression that 
oe-core shouldn't depend on anything except bitbake . So either this 
stuff should be moved to meta-oe too (which would be unfortunate growth 
of dependencies) or the lzop should be reinstated . I would obviously be 
in favor of the later.

On Thu, 23 Nov 2023 at 22:07, Marek Vasut <marex@denx.de> wrote:

> The lzop is called in oe-core and I was under the impression that
> oe-core shouldn't depend on anything except bitbake . So either this
> stuff should be moved to meta-oe too (which would be unfortunate growth
> of dependencies) or the lzop should be reinstated . I would obviously be
> in favor of the later.

There are plenty of recipes in oe-core that have optional features
(enabled via PACKAGECONFIG) that depend on recipes that are not in
core. If you enable them, bitbake will say that the needed recipe is
missing and then you need to figure out which layer to add (typically
something in meta-openembedded tree). This is not that different:
optional feature, disabled by default, and the error will be the same:
missing lzop recipe.

Alex

On Fri, Nov 24, 2023 at 8:52 AM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> On Thu, 23 Nov 2023 at 22:07, Marek Vasut <marex@denx.de> wrote:
>
> > The lzop is called in oe-core and I was under the impression that
> > oe-core shouldn't depend on anything except bitbake . So either this
> > stuff should be moved to meta-oe too (which would be unfortunate growth
> > of dependencies) or the lzop should be reinstated . I would obviously be
> > in favor of the later.
>
> There are plenty of recipes in oe-core that have optional features
> (enabled via PACKAGECONFIG) that depend on recipes that are not in
> core. If you enable them, bitbake will say that the needed recipe is
> missing and then you need to figure out which layer to add (typically
> something in meta-openembedded tree). This is not that different:
> optional feature, disabled by default, and the error will be the same:
> missing lzop recipe.
>

I think this case is slightly different as this optional dependency might
be "enabled" by MACHINE config in some BSP layer and BSP layer depending on
meta-oe just to build the kernel (with BSP preferred compression) isn't
great - compared with some DISTRO config enabling some additional
PACKAGECONFIG in some other recipe the DISTRO uses.

At least if Marek agrees to maintain it instead of restoring Denys as
maintainer :).

Cheers,

On 11/24/23 03:18, Martin Jansa wrote:
> On Fri, Nov 24, 2023 at 8:52 AM Alexander Kanavin 
> <alex.kanavin@gmail.com <mailto:alex.kanavin@gmail.com>> wrote:
> 
>     On Thu, 23 Nov 2023 at 22:07, Marek Vasut <marex@denx.de
>     <mailto:marex@denx.de>> wrote:
> 
>      > The lzop is called in oe-core and I was under the impression that
>      > oe-core shouldn't depend on anything except bitbake . So either this
>      > stuff should be moved to meta-oe too (which would be unfortunate
>     growth
>      > of dependencies) or the lzop should be reinstated . I would
>     obviously be
>      > in favor of the later.
> 
>     There are plenty of recipes in oe-core that have optional features
>     (enabled via PACKAGECONFIG) that depend on recipes that are not in
>     core. If you enable them, bitbake will say that the needed recipe is
>     missing and then you need to figure out which layer to add (typically
>     something in meta-openembedded tree). This is not that different:
>     optional feature, disabled by default, and the error will be the same:
>     missing lzop recipe.
> 
> 
> I think this case is slightly different as this optional dependency 
> might be "enabled" by MACHINE config in some BSP layer and BSP layer 
> depending on meta-oe just to build the kernel (with BSP preferred 
> compression) isn't great - compared with some DISTRO config enabling 
> some additional PACKAGECONFIG in some other recipe the DISTRO uses.

It sounds like enabling the option forces the addition of another layer 
to an existing project. I understand the need for that if the 
PACKAGECONFIG added so additional package to the image, but in this case 
the option just needs an additional tool to create stuff needed for 
booting a board

Philip

> 
> At least if Marek agrees to maintain it instead of restoring Denys as 
> maintainer :).
> 
> Cheers,
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#191178): https://lists.openembedded.org/g/openembedded-core/message/191178
> Mute This Topic: https://lists.openembedded.org/mt/102759947/384425
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [philip@balister.org]
> -=-=-=-=-=-=-=-=-=-=-=-
>

On 11/24/23 09:18, Martin Jansa wrote:
> On Fri, Nov 24, 2023 at 8:52 AM Alexander Kanavin <alex.kanavin@gmail.com>
> wrote:
> 
>> On Thu, 23 Nov 2023 at 22:07, Marek Vasut <marex@denx.de> wrote:
>>
>>> The lzop is called in oe-core and I was under the impression that
>>> oe-core shouldn't depend on anything except bitbake . So either this
>>> stuff should be moved to meta-oe too (which would be unfortunate growth
>>> of dependencies) or the lzop should be reinstated . I would obviously be
>>> in favor of the later.
>>
>> There are plenty of recipes in oe-core that have optional features
>> (enabled via PACKAGECONFIG) that depend on recipes that are not in
>> core. If you enable them, bitbake will say that the needed recipe is
>> missing and then you need to figure out which layer to add (typically
>> something in meta-openembedded tree). This is not that different:
>> optional feature, disabled by default, and the error will be the same:
>> missing lzop recipe.
>>
> 
> I think this case is slightly different as this optional dependency might
> be "enabled" by MACHINE config in some BSP layer and BSP layer depending on
> meta-oe just to build the kernel (with BSP preferred compression) isn't
> great - compared with some DISTRO config enabling some additional
> PACKAGECONFIG in some other recipe the DISTRO uses.
> 
> At least if Marek agrees to maintain it instead of restoring Denys as
> maintainer :).

The recipe seems low maintenance anyway and I use it often, so yeah, why 
not.

On Fri, Nov 24, 2023 at 12:18 AM Martin Jansa <martin.jansa@gmail.com> wrote:
>
> On Fri, Nov 24, 2023 at 8:52 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>>
>> On Thu, 23 Nov 2023 at 22:07, Marek Vasut <marex@denx.de> wrote:
>>
>> > The lzop is called in oe-core and I was under the impression that
>> > oe-core shouldn't depend on anything except bitbake . So either this
>> > stuff should be moved to meta-oe too (which would be unfortunate growth
>> > of dependencies) or the lzop should be reinstated . I would obviously be
>> > in favor of the later.
>>
>> There are plenty of recipes in oe-core that have optional features
>> (enabled via PACKAGECONFIG) that depend on recipes that are not in
>> core. If you enable them, bitbake will say that the needed recipe is
>> missing and then you need to figure out which layer to add (typically
>> something in meta-openembedded tree). This is not that different:
>> optional feature, disabled by default, and the error will be the same:
>> missing lzop recipe.
>
>
> I think this case is slightly different as this optional dependency might be "enabled" by MACHINE config in some BSP layer and BSP layer depending on meta-oe just to build the kernel (with BSP preferred compression) isn't great - compared with some DISTRO config enabling some additional PACKAGECONFIG in some other recipe the DISTRO uses.
>

do we have some data on how many machines are needing this ? if not
then I think we can say that
its not actively needed and few machines if any needing this can house
the recipe in the BSP layer
core support is still in core so that's good.

> At least if Marek agrees to maintain it instead of restoring Denys as maintainer :).

That's good although it will be nicer to see a wider use case to keep
it in core.

>
> Cheers,
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#191178): https://lists.openembedded.org/g/openembedded-core/message/191178
> Mute This Topic: https://lists.openembedded.org/mt/102759947/1997914
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

On 11/24/23 23:28, Khem Raj wrote:
> On Fri, Nov 24, 2023 at 12:18 AM Martin Jansa <martin.jansa@gmail.com> wrote:
>>
>> On Fri, Nov 24, 2023 at 8:52 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>>>
>>> On Thu, 23 Nov 2023 at 22:07, Marek Vasut <marex@denx.de> wrote:
>>>
>>>> The lzop is called in oe-core and I was under the impression that
>>>> oe-core shouldn't depend on anything except bitbake . So either this
>>>> stuff should be moved to meta-oe too (which would be unfortunate growth
>>>> of dependencies) or the lzop should be reinstated . I would obviously be
>>>> in favor of the later.
>>>
>>> There are plenty of recipes in oe-core that have optional features
>>> (enabled via PACKAGECONFIG) that depend on recipes that are not in
>>> core. If you enable them, bitbake will say that the needed recipe is
>>> missing and then you need to figure out which layer to add (typically
>>> something in meta-openembedded tree). This is not that different:
>>> optional feature, disabled by default, and the error will be the same:
>>> missing lzop recipe.
>>
>>
>> I think this case is slightly different as this optional dependency might be "enabled" by MACHINE config in some BSP layer and BSP layer depending on meta-oe just to build the kernel (with BSP preferred compression) isn't great - compared with some DISTRO config enabling some additional PACKAGECONFIG in some other recipe the DISTRO uses.
>>
> 
> do we have some data on how many machines are needing this ? if not
> then I think we can say that
> its not actively needed and few machines if any needing this can house
> the recipe in the BSP layer
> core support is still in core so that's good.
> 
>> At least if Marek agrees to maintain it instead of restoring Denys as maintainer :).
> 
> That's good although it will be nicer to see a wider use case to keep
> it in core.

I can think of at least two SoM vendors that actively use this.
I don't think that's "a few machines if any".