Skip to contentSkip to conversation

libwebsockets: rely on cmake.bbclass to put cmake package files in dev package

PATCH In review Andre McCurdy 5 participants 28 messages May 18, 2018 – May 24, 2018

lore
Share & tools
lore
#0 lore raw

PATCH 1/17 libwebsockets: rely on cmake.bbclass to put cmake package files in dev package

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb | 1 -
 1 file changed, 1 deletion(-)
meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb +0 -1
index 9354799..6b9c545 100644
@@ -24,5 +24,4 @@ PACKAGECONFIG[testapps] = "-DLWS_WITHOUT_TESTAPPS=OFF,-DLWS_WITHOUT_TESTAPPS=ON,
 
 PACKAGES =+ "${PN}-testapps"
 
-FILES_${PN}-dev += "${libdir}/cmake"
 FILES_${PN}-testapps += "${datadir}/libwebsockets-test-server/*"
Signature · 1 line
1.9.1
#1 lore raw

PATCH 2/17 openobex: rely on cmake.bbclass to put cmake package files in dev package

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-connectivity/obex/openobex_1.7.2.bb | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
meta-oe/recipes-connectivity/obex/openobex_1.7.2.bb +6 -6
index 2db48f3..f93c447 100644
@@ -2,24 +2,24 @@ DESCRIPTION = "The Openobex project is an open source implementation of the \
 Object Exchange (OBEX) protocol."
 HOMEPAGE = "http://openobex.triq.net"
 SECTION = "libs"
-DEPENDS = "virtual/libusb0"
-DEPENDS_append_class-target = " ${@bb.utils.contains('DISTRO_FEATURES','bluez5','bluez5','bluez4',d)}"
-
 LICENSE = "GPLv2 & LGPLv2.1"
 LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a \
                     file://COPYING.LIB;md5=a6f89e2100d9b6cdffcea4f398e37343 \
 "
 
+DEPENDS = "virtual/libusb0"
+DEPENDS_append_class-target = " ${@bb.utils.contains('DISTRO_FEATURES','bluez5','bluez5','bluez4',d)}"
+
 SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}/${PV}/${BP}-Source.tar.gz \
 "
 
 SRC_URI[md5sum] = "f6e0b6cb7dcfd731460a7e9a91429a3a"
 SRC_URI[sha256sum] = "158860aaea52f0fce0c8e4b64550daaae06df2689e05834697b7e8c7d73dd4fc"
 
-inherit cmake pkgconfig
-
 S = "${WORKDIR}/${BP}-Source"
 
+inherit cmake pkgconfig
+
 EXTRA_OECONF = " -DCMAKE_SKIP_RPATH=ON "
 EXTRA_OECMAKE += "-DBUILD_DOCUMENTATION=OFF"
 
@@ -32,7 +32,7 @@ do_install_append () {
 PACKAGES =+ "openobex-apps"
 FILES_${PN}-apps = "${bindir}/*"
 FILES_${PN} += "${libdir}/lib*.so.*"
-FILES_${PN}-dev += "${bindir}/openobex-config ${libdir}/cmake"
+FILES_${PN}-dev += "${bindir}/openobex-config"
 DEBIAN_NOAUTONAME_${PN}-apps = "1"
 
 BBCLASSEXTEND = "native"
Signature · 1 line
1.9.1
#2 lore raw

PATCH 3/17 rocksdb: rely on cmake.bbclass to put cmake package files in dev package

In reply to Andre McCurdy

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-dbs/rocksdb/rocksdb_git.bb | 2 --
 1 file changed, 2 deletions(-)
meta-oe/recipes-dbs/rocksdb/rocksdb_git.bb +0 -2
index 1e6cbae..16fc180 100644
@@ -28,5 +28,3 @@ EXTRA_OECMAKE = "\
     -DWITH_TESTS=OFF \
     -DWITH_TOOLS=OFF \
 "
-
-FILES_${PN}-dev += "${libdir}/cmake"
Signature · 1 line
1.9.1
#3 lore raw

PATCH 4/17 capnproto: rely on cmake.bbclass to put cmake package files in dev package

In reply to Andre McCurdy

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-devtools/capnproto/capnproto_0.6.1.bb | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)
meta-oe/recipes-devtools/capnproto/capnproto_0.6.1.bb +4 -6
index ffbe73f..b448a11 100644
@@ -2,25 +2,23 @@ SUMMARY = "Cap'n Proto serialization/RPC system"
 DESCRIPTION = "Cap’n Proto is an insanely fast data interchange format and capability-based RPC system. "
 HOMEPAGE = "https://github.com/sandstorm-io/capnproto"
 SECTION = "console/tools"
-
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://../LICENSE;md5=0a5b5b742baf10cc1c158579eba7fb1d"
 
 SRCREV = "c949a18da5f041a36cc218c5c4b79c7705999b4f"
 SRC_URI = "git://github.com/sandstorm-io/capnproto.git;branch=release-${PV}"
 
-EXTRA_OECMAKE += "\
-    -DBUILD_TESTING=OFF \
-"
+S = "${WORKDIR}/git/c++"
 
 inherit cmake
 
-S = "${WORKDIR}/git/c++"
+EXTRA_OECMAKE += "\
+    -DBUILD_TESTING=OFF \
+"
 
 PACKAGE_BEFORE_PN = "${PN}-compiler"
 RDEPENDS_${PN}-dev += "${PN}-compiler"
 
-FILES_${PN}-dev += "${libdir}/cmake"
 FILES_${PN}-compiler = "${bindir}"
 
 BBCLASSEXTEND = "native nativesdk"
Signature · 1 line
1.9.1
#4 lore raw

PATCH 5/17 grpc: rely on cmake.bbclass to put cmake package files in dev package

In reply to Andre McCurdy

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-devtools/grpc/grpc_1.8.5.bb | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)
meta-oe/recipes-devtools/grpc/grpc_1.8.5.bb +1 -4
index 0883ec1..4b6028d 100644
@@ -4,12 +4,11 @@ Provides gRPC libraries for multiple languages written on top of shared C core l
 HOMEPAGE = "https://github.com/grpc/grpc"
 SECTION = "libs"
 LICENSE = "Apache-2"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
 
 DEPENDS = "gflags c-ares protobuf protobuf-native protobuf-c protobuf-c-native openssl"
 DEPENDS_append_class-target = " gtest grpc-native "
 
-LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
-
 SRC_URI = "https://github.com/grpc/grpc/archive/v${PV}.tar.gz \
            file://0001-CMakeLists.txt-Fix-libraries-installation-for-Linux.patch \
            file://0004-CMakeLists.txt-Find-c-ares-in-target-sysroot-alone.patch \
@@ -31,6 +30,4 @@ EXTRA_OECMAKE = " \
     -DBUILD_SHARED_LIBS=ON \
     "
 
-FILES_${PN}-dev += "${libdir}/cmake"
-
 BBCLASSEXTEND = "native"
Signature · 1 line
1.9.1
#5 lore raw

PATCH 6/17 json-spirit: rely on cmake.bbclass to put cmake package files in dev package

In reply to Andre McCurdy

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-devtools/json-spirit/json-spirit_4.08.bb | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)
meta-oe/recipes-devtools/json-spirit/json-spirit_4.08.bb +2 -4
index c7c1ad1..d6e42c8 100644
@@ -9,6 +9,8 @@ PRIORITY = "optional"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=278ef6183dec4aae1524fccc4b0113c9"
 
+DEPENDS = "boost"
+
 SRC_URI = "file://json_spirit_v${PV}.zip \
            file://0001-Adjust-the-cmake-files.patch \
            file://0001-Link-to-libatomic.patch \
@@ -16,10 +18,6 @@ SRC_URI = "file://json_spirit_v${PV}.zip \
 
 S = "${WORKDIR}/json_spirit_v${PV}"
 
-DEPENDS = "boost"
-
 inherit cmake
 
-FILES_${PN}-dev += "${datadir}/cmake/Modules/FindLibJsonSpirit.cmake"
-
 BBCLASSEXTEND = "nativesdk"
Signature · 1 line
1.9.1
#6 lore raw

PATCH 7/17 librcf: rely on cmake.bbclass to put cmake package files in dev package

In reply to Andre McCurdy

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-devtools/librcf/librcf_2.2.0.0.bb | 1 -
 1 file changed, 1 deletion(-)
meta-oe/recipes-devtools/librcf/librcf_2.2.0.0.bb +0 -1
index 267c0e7..dcd47a4 100644
@@ -47,7 +47,6 @@ PACKAGECONFIG[demos] = "-DLIBRCF_BUILD_DEMOS=ON,-DLIBRCF_BUILD_DEMOS=OFF,"
 PACKAGES =+ "${@bb.utils.contains('PACKAGECONFIG', 'demos', '${PN}-demos', '', d)}"
 
 FILES_${PN}-demos = "${bindir}/*"
-FILES_${PN}-dev += "${datadir}/cmake/Modules/FindLibRcf.cmake"
 
 BBCLASSEXTEND = "nativesdk"
 
Signature · 1 line
1.9.1
#7 lore raw

PATCH 8/17 msgpack-c: rely on cmake.bbclass to put cmake package files in dev package

In reply to Andre McCurdy

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-devtools/msgpack/msgpack-c_2.1.5.bb | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
meta-oe/recipes-devtools/msgpack/msgpack-c_2.1.5.bb +1 -3
index 02c0cd2..5077ade 100644
@@ -15,8 +15,6 @@ SRC_URI = "git://github.com/msgpack/msgpack-c \
            file://0001-Fix-Werror-class-memaccess.patch \
            "
 
-inherit cmake pkgconfig
-
 S = "${WORKDIR}/git"
 
-FILES_${PN}-dev += "${libdir}/cmake/msgpack/*.cmake"
+inherit cmake pkgconfig
Signature · 1 line
1.9.1
#8 lore raw

PATCH 9/17 rapidjson: rely on cmake.bbclass to put cmake package files in dev package

In reply to Andre McCurdy

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-devtools/rapidjson/rapidjson_git.bb | 1 -
 1 file changed, 1 deletion(-)
meta-oe/recipes-devtools/rapidjson/rapidjson_git.bb +0 -1
index 8ab35d2..069385d 100644
@@ -20,7 +20,6 @@ EXTRA_OECMAKE += "-DRAPIDJSON_BUILD_DOC=OFF -DRAPIDJSON_BUILD_TESTS=OFF -DRAPIDJ
 
 # RapidJSON is a header-only C++ library, so the main package will be empty.
 
-FILES_${PN}-dev += "${libdir}/cmake"
 RDEPENDS_${PN}-dev = ""
 
 BBCLASSEXTEND = "native nativesdk"
Signature · 1 line
1.9.1
#9 lore raw

PATCH 10/17 glm: rely on cmake.bbclass to put cmake package files in dev package

In reply to Andre McCurdy

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-graphics/glm/glm_0.9.9-a2.bb | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)
meta-oe/recipes-graphics/glm/glm_0.9.9-a2.bb +1 -3
index 4e2ee23..7f16708 100644
@@ -4,9 +4,7 @@ mathematics library for graphics software based on the OpenGL \
 Shading Language (GLSL) specifications."
 HOMEPAGE = "https://glm.g-truc.net"
 BUGTRACKER = "https://github.com/g-truc/glm/issues"
-
 SECTION = "libs"
-
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://readme.md;beginline=21;endline=22;md5=3075b5727d36f29edccf97b93e72b790"
 
@@ -16,13 +14,13 @@ SRC_URI = " \
     file://0002-glm-install-headers-only.patch \
 "
 SRCREV = "fcbedf5058ef8613dd02aac62ef00d55dcfeadd7"
+
 S = "${WORKDIR}/git"
 
 inherit cmake
 
 EXTRA_OECMAKE = "-DGLM_ENABLE_EXPERIMENTAL=ON"
 
-FILES_${PN}-dev += "${libdir}/cmake"
 RDEPENDS_${PN}-dev = ""
 
 BBCLASSEXTEND = "native"
Signature · 1 line
1.9.1
#10 lore raw

PATCH 11/17 openjpeg: rely on cmake.bbclass to put cmake package files in dev package

In reply to Andre McCurdy

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-graphics/openjpeg/openjpeg_2.2.0.bb | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)
meta-oe/recipes-graphics/openjpeg/openjpeg_2.2.0.bb +2 -5
index 4ef1c40..22b75d9 100644
@@ -1,9 +1,10 @@
 DESCRIPTION = "OpenJPEG library is an open-source JPEG 2000 codec"
 HOMEPAGE = "http://www.openjpeg.org"
-
 LICENSE = "BSD"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=c648878b4840d7babaade1303e7f108c"
 
+DEPENDS = "libpng tiff lcms zlib"
+
 SRC_URI = "https://github.com/uclouvain/${BPN}/archive/v${PV}.tar.gz;downloadfilename=${BP}.tar.gz \
            file://0001-bmp_read_info_header-reject-bmp-files-with-biBitCoun.patch \
           "
@@ -12,10 +13,6 @@ SRC_URI[sha256sum] = "6fddbce5a618e910e03ad00d66e7fcd09cc6ee307ce69932666d54c73b
 
 inherit cmake
 
-DEPENDS = "libpng tiff lcms zlib"
-
 # standard path for *.cmake
 EXTRA_OECMAKE += "-DOPENJPEG_INSTALL_PACKAGE_DIR=${baselib}/cmake \
                   -DOPENJPEG_INSTALL_LIB_DIR:PATH=${libdir}"
-
-FILES_${PN}-dev += "${libdir}/cmake/*.cmake"
Signature · 1 line
1.9.1
#11 lore raw

PATCH 12/17 ceres-solver: rely on cmake.bbclass to put cmake package files in dev package

In reply to Andre McCurdy

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-support/ceres-solver/ceres-solver_1.14.bb | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)
meta-oe/recipes-support/ceres-solver/ceres-solver_1.14.bb +2 -5
index 29917c8..ad7c8f2 100644
@@ -1,20 +1,17 @@
 DESCRIPTION = "Ceres Solver is an open source C++ library for modeling and solving large, complicated optimization problems."
 AUTHOR = "Sameer Agarwal and Keir Mierle and Others"
 HOMEPAGE = "http://ceres-solver.org/"
-
 LICENSE = "BSD-3-Clause"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=35e00f0c4c96a0820a03e0b31e6416be"
 
+DEPENDS = "libeigen glog"
+
 SRC_URI = "git://github.com/ceres-solver/ceres-solver.git"
 SRCREV = "facb199f3eda902360f9e1d5271372b7e54febe1"
 
 S = "${WORKDIR}/git"
 
-DEPENDS = "libeigen glog"
-
 inherit cmake
 
 # Only a static library and headers are created
 ALLOW_EMPTY_${PN} = "1"
-
-FILES_${PN}-dev += "${libdir}/cmake/*"
Signature · 1 line
1.9.1
#12 lore raw

PATCH 13/17 gflags: rely on cmake.bbclass to put cmake package files in dev package

In reply to Andre McCurdy

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-support/gflags/gflags_2.2.0.bb | 4 ----
 1 file changed, 4 deletions(-)
meta-oe/recipes-support/gflags/gflags_2.2.0.bb +0 -4
index 28b652a..834a9f9 100644
@@ -1,7 +1,5 @@
 DESCRIPTION = "The gflags package contains a C++ library that implements commandline flags processing. It includes built-in support for standard types such as string and the ability to define flags in the source file in which they are used"
-
 HOMEPAGE = "https://github.com/gflags/gflags"
-
 LICENSE = "BSD-3-Clause"
 LIC_FILES_CHKSUM = "file://COPYING.txt;md5=c80d1a3b623f72bb85a4c75b556551df"
 
@@ -10,8 +8,6 @@ SRCREV = "f8a0efe03aa69b3336d8e228b37d4ccb17324b88"
 
 S = "${WORKDIR}/git"
 
-FILES_${PN}-dev += "${libdir}/cmake"
-
 inherit cmake
 
 EXTRA_OECMAKE="-DBUILD_SHARED_LIBS=ON -DREGISTER_INSTALL_PREFIX=OFF -DLIB_INSTALL_DIR=${baselib}"
Signature · 1 line
1.9.1
#13 lore raw

PATCH 14/17 libftdi: rely on cmake.bbclass to put cmake package files in dev package

In reply to Andre McCurdy

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-support/libftdi/libftdi_1.4.bb | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)
meta-oe/recipes-support/libftdi/libftdi_1.4.bb +2 -5
index 6bea165..d28b7a3 100644
@@ -3,7 +3,6 @@ FT232BM/245BM, FT2232C/D and FT232/245R using libusb,\
 including the popular bitbang mode."
 HOMEPAGE = "http://www.intra2net.com/en/developer/libftdi/"
 SECTION = "libs"
-
 LICENSE = "LGPLv2.1 & GPLv2"
 LIC_FILES_CHKSUM= "\
     file://COPYING.GPL;md5=751419260aa954499f7abaabaa882bbe \
@@ -19,13 +18,11 @@ SRC_URI[sha256sum] = "ec36fb49080f834690c24008328a5ef42d3cf584ef4060f3a35aa4681c
 
 S = "${WORKDIR}/${BPN}1-${PV}"
 
+inherit cmake binconfig pkgconfig
+
 PACKAGECONFIG ??= ""
 PACKAGECONFIG[cpp-wrapper] = "-DFTDI_BUILD_CPP=on -DFTDIPP=on,-DFTDI_BUILD_CPP=off -DFTDIPP=off,boost"
 
-inherit cmake binconfig pkgconfig
-
 EXTRA_OECMAKE = "-DLIB_SUFFIX=${@d.getVar('baselib').replace('lib', '')}"
 
-FILES_${PN}-dev += "${libdir}/cmake"
-
 BBCLASSEXTEND = "native"
Signature · 1 line
1.9.1
#14 lore raw

PATCH 15/17 libssh: rely on cmake.bbclass to put cmake package files in dev package

In reply to Andre McCurdy

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-support/libssh/libssh_0.7.3.bb | 16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)
meta-oe/recipes-support/libssh/libssh_0.7.3.bb +7 -9
index 79e7dc5..6e060f7 100644
@@ -1,16 +1,20 @@
 SUMMARY = "Multiplatform C library implementing the SSHv2 and SSHv1 protocol"
 HOMEPAGE = "http://www.libssh.org"
 SECTION = "libs"
-
-DEPENDS = "zlib openssl libgcrypt"
-
 LICENSE = "LGPLv2.1"
 LIC_FILES_CHKSUM = "file://COPYING;md5=388a4fb1dea8ceae0be78ba9b01fc139"
 
+DEPENDS = "zlib openssl libgcrypt"
+
 SRC_URI = "git://git.libssh.org/projects/libssh.git;branch=v0-7"
 SRCREV = "cdf7690e038230623cbbf6b024ece62f41efa98d"
 S = "${WORKDIR}/git"
 
+inherit cmake
+
+PACKAGECONFIG ??=""
+PACKAGECONFIG[gssapi] = "-DWITH_GSSAPI=1,-DWITH_GSSAPI=0,krb5"
+
 EXTRA_OECMAKE = " \
     -DWITH_GCRYPT=1 \
     -DWITH_PCAP=1 \
@@ -19,16 +23,10 @@ EXTRA_OECMAKE = " \
     -DLIB_SUFFIX=${@d.getVar('baselib').replace('lib', '')} \
     "
 
-PACKAGECONFIG ??=""
-PACKAGECONFIG[gssapi] = "-DWITH_GSSAPI=1, -DWITH_GSSAPI=0, krb5, "
-
-inherit cmake
-
 do_configure_prepend () {
     # Disable building of examples
     sed -i -e '/add_subdirectory(examples)/s/^/#DONOTWANT/' ${S}/CMakeLists.txt \
         || bbfatal "Failed to disable examples"
 }
 
-FILES_${PN}-dev += "${libdir}/cmake"
 TOOLCHAIN = "gcc"
Signature · 1 line
1.9.1
#15 lore raw

PATCH 16/17 libtinyxml2: rely on cmake.bbclass to put cmake package files in dev package

In reply to Andre McCurdy

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-support/libtinyxml2/libtinyxml2_5.0.1.bb | 2 --
 1 file changed, 2 deletions(-)
meta-oe/recipes-support/libtinyxml2/libtinyxml2_5.0.1.bb +0 -2
index 8b5ab44..c763a6c 100644
@@ -12,6 +12,4 @@ S = "${WORKDIR}/git"
 
 inherit cmake
 
-FILES_${PN}-dev += "${libdir}/cmake/"
-
 BBCLASSEXTEND = "native"
Signature · 1 line
1.9.1
#16 lore raw

PATCH 17/17 poco: rely on cmake.bbclass to put cmake package files in dev package

In reply to Andre McCurdy

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
 meta-oe/recipes-support/poco/poco_1.8.0.1.bb | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
meta-oe/recipes-support/poco/poco_1.8.0.1.bb +4 -4
index 160b4d3..b4a0eb1 100644
@@ -8,10 +8,6 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=4267f48fc738f50380cbeeb76f95cebc"
 # These dependencies are required by Foundation
 DEPENDS = "libpcre zlib"
 
-inherit cmake ptest
-
-BBCLASSEXTEND = "native"
-
 SRCREV = "af527ab21fca5ab2659285408aec9920ed7c7b17"
 SRC_URI = " \
     git://github.com/pocoproject/poco.git \
@@ -20,6 +16,8 @@ SRC_URI = " \
 
 S = "${WORKDIR}/git"
 
+inherit cmake ptest
+
 EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=RelWithDebInfo -DPOCO_UNBUNDLED=ON \
                   -DZLIB_LIBRARY_RELEASE:STRING=z -DPCRE_LIBRARY:STRING=pcre \
                  ${@bb.utils.contains('PTEST_ENABLED', '1', '-DENABLE_TESTS=ON ', '', d)}"
@@ -104,3 +102,5 @@ do_install_ptest () {
        find "${D}${PTEST_PATH}" -executable -exec chrpath -d {} \;
        echo "${POCO_TESTRUNNERS}" > "${D}${PTEST_PATH}/testrunners"
 }
+
+BBCLASSEXTEND = "native"
Signature · 1 line
1.9.1
#17 lore raw
In reply to Andre McCurdy

Hi Andre

This series is fine, except that it has some formatting changes mixed with cmake related changes. It would be preferable to have them as separate pulls. I reckon that both types of changes are good.

Quoted 22 lines · Andre McCurdy

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

   http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93
---
  meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb | 1 -
  1 file changed, 1 deletion(-)
meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb +0 -1
index 9354799..6b9c545 100644
@@ -24,5 +24,4 @@ PACKAGECONFIG[testapps] = "-DLWS_WITHOUT_TESTAPPS=OFF,-DLWS_WITHOUT_TESTAPPS=ON,
 
  PACKAGES =+ "${PN}-testapps"
 
-FILES_${PN}-dev += "${libdir}/cmake"
  FILES_${PN}-testapps += "${datadir}/libwebsockets-test-server/*"
#18 lore raw
Quoted 5 lines · Khem Raj

Hi Andre

This series is fine, except that it has some formatting changes mixed with cmake related changes. It would be preferable to have them as separate pulls. I reckon that both types of changes are good.

The formatting cleanups are all minor and probably not worth submitting on their own.

Quoted 27 lines · Andre McCurdy
Quoted 25 lines

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
  meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb | 1 -
  1 file changed, 1 deletion(-)

diff --git a/meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb b/meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb index 9354799..6b9c545 100644

meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb +0 -0
@@ -24,5 +24,4 @@ PACKAGECONFIG[testapps] =
 "-DLWS_WITHOUT_TESTAPPS=OFF,-DLWS_WITHOUT_TESTAPPS=ON,
    PACKAGES =+ "${PN}-testapps"
  -FILES_${PN}-dev += "${libdir}/cmake"
  FILES_${PN}-testapps += "${datadir}/libwebsockets-test-server/*"
#19 lore raw
Quoted 10 lines · Andre McCurdy
Quoted 5 lines · Khem Raj

Hi Andre

This series is fine, except that it has some formatting changes mixed with cmake related changes. It would be preferable to have them as separate pulls. I reckon that both types of changes are good.

The formatting cleanups are all minor and probably not worth submitting on their own.

OK thats fine, drop then in v2

Quoted 27 lines
Quoted 27 lines · Andre McCurdy
Quoted 25 lines

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
  meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb | 1 -
  1 file changed, 1 deletion(-)

diff --git a/meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb b/meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb index 9354799..6b9c545 100644

meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb +0 -0
@@ -24,5 +24,4 @@ PACKAGECONFIG[testapps] =
 "-DLWS_WITHOUT_TESTAPPS=OFF,-DLWS_WITHOUT_TESTAPPS=ON,
    PACKAGES =+ "${PN}-testapps"
  -FILES_${PN}-dev += "${libdir}/cmake"
  FILES_${PN}-testapps += "${datadir}/libwebsockets-test-server/*"
#20 lore raw
Quoted 8 lines · Khem Raj
Quoted 7 lines · Andre McCurdy
Quoted 5 lines · Khem Raj

Hi Andre

This series is fine, except that it has some formatting changes mixed with cmake related changes. It would be preferable to have them as separate pulls. I reckon that both types of changes are good.

Quoted 5 lines
Quoted 3 lines

The formatting cleanups are all minor and probably not worth submitting on their own.

OK thats fine, drop then in v2

They are not worth reworking the patch set to create a v2 either :-)

Quoted 27 lines
Quoted 27 lines
Quoted 27 lines · Andre McCurdy
Quoted 25 lines

The cmake.bbclass in oe-core now ensures that ${libdir}/cmake and ${datadir}/cmake end up in the dev package, so recipes no longer need to provide custom packaging rules to handles these files.

http://git.openembedded.org/openembedded-core/commit/?id=d91dc4666683a96e9d03cbbd21b8a546f9069c93

---
  meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb | 1 -
  1 file changed, 1 deletion(-)

diff --git a/meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb b/meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb index 9354799..6b9c545 100644

meta-oe/recipes-connectivity/libwebsockets/libwebsockets_2.1.0.bb +0 -0
@@ -24,5 +24,4 @@ PACKAGECONFIG[testapps] =
 "-DLWS_WITHOUT_TESTAPPS=OFF,-DLWS_WITHOUT_TESTAPPS=ON,
    PACKAGES =+ "${PN}-testapps"
  -FILES_${PN}-dev += "${libdir}/cmake"
  FILES_${PN}-testapps += "${datadir}/libwebsockets-test-server/*"
#21 lore raw
Quoted 11 lines · Andre McCurdy
Quoted 1 line · Khem Raj

On Fri, May 18, 2018 at 12:07 PM, Andre McCurdy <[email protected]>

Quoted 4 lines · wrote:
Quoted 4 lines · Khem Raj
Quoted 3 lines

Hi Andre

This series is fine, except that it has some formatting changes mixed

with

Quoted 3 lines
Quoted 3 lines
Quoted 2 lines

cmake related changes. It would be preferable to have them as separate pulls. I reckon that both types of changes are good.

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

The formatting cleanups are all minor and probably not worth submitting on their own.

OK thats fine, drop then in v2

They are not worth reworking the patch set to create a v2 either :-)

It would be wonderful if we could agree on formatting; if we could, I'd certainly help by taking on some of the reformatting task.

Unfortunately, all such past attempts of which I'm aware never got anywhere, and if I remember correctly, the Yocto folks and the OE folks each have their own ideas of what is "correct".

In any case, if these won't get in as is, if Andre doesn't want to spin a v2 without the formatting changes, and everyone is okay with it, I could spin a v2 without the formatting changes.

#22 lore raw
Quoted 18 lines · Trevor Woerner

On Fri, May 18, 2018 at 6:28 PM, Andre McCurdy <[email protected] <mailto:[email protected]>> wrote:

On Fri, May 18, 2018 at 2:01 PM, Khem Raj <[email protected] <mailto:[email protected]>> wrote:
> On Fri, May 18, 2018 at 12:07 PM, Andre McCurdy <[email protected] <mailto:[email protected]>> wrote:
>> On Thu, May 17, 2018 at 6:56 PM, Khem Raj <[email protected] <mailto:[email protected]>> wrote:
>>> Hi Andre
>>>
>>> This series is fine, except that it has some formatting changes mixed with
>>> cmake related changes. It would be preferable to have them as separate
>>> pulls. I reckon that both types of changes are good.
>>
>> The formatting cleanups are all minor and probably not worth
>> submitting on their own.
>>
>
> OK thats fine, drop then in v2

Quoted 8 lines

They are not worth reworking the patch set to create a v2 either :-)

It would be wonderful if we could agree on formatting; if we could, I'd certainly help by taking on some of the reformatting task.

Unfortunately, all such past attempts of which I'm aware never got anywhere, and if I remember correctly, the Yocto folks and the OE folks each have their own ideas of what is "correct".

In any case, if these won't get in as is, if Andre doesn't want to spin a v2 without the formatting changes, and everyone is okay with it, I could spin a v2 without the formatting changes.

Please do.

#23 lore raw
Quoted 46 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Khem Raj
Sent: den 19 maj 2018 06:53
To: Trevor Woerner <[email protected]>; Andre McCurdy <[email protected]>
Cc: openembeded-devel <[email protected]>
Subject: Re: [oe] [meta-oe][PATCH 01/17] libwebsockets: rely on cmake.bbclass to put cmake package files in dev package

Quoted 6 lines · Trevor Woerner

On Fri, May 18, 2018 at 6:28 PM, Andre McCurdy <[email protected] <mailto:[email protected]>> wrote:

    On Fri, May 18, 2018 at 2:01 PM, Khem Raj <[email protected]
    <mailto:[email protected]>> wrote:
    > On Fri, May 18, 2018 at 12:07 PM, Andre McCurdy
Quoted 1 line · <[email protected] <mailto:[email protected]>> wrote:
Quoted 1 line
Quoted 1 line

On Thu, May 17, 2018 at 6:56 PM, Khem Raj <[email protected]

Quoted 3 lines · <mailto:[email protected]>> wrote:
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines

Hi Andre

This series is fine, except that it has some formatting

changes mixed with

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

cmake related changes. It would be preferable to have them as

separate

Quoted 9 lines
Quoted 7 lines
Quoted 5 lines
Quoted 1 line

pulls. I reckon that both types of changes are good.

The formatting cleanups are all minor and probably not worth submitting on their own.

OK thats fine, drop then in v2

They are not worth reworking the patch set to create a v2 either

:-)

Quoted 3 lines

It would be wonderful if we could agree on formatting; if we could,

I'd

Quoted 4 lines

certainly help by taking on some of the reformatting task.

Unfortunately, all such past attempts of which I'm aware never got anywhere, and if I remember correctly, the Yocto folks and the OE

folks

Quoted 8 lines
Quoted 3 lines

each have their own ideas of what is "correct".

In any case, if these won't get in as is, if Andre doesn't want to

spin

Quoted 2 lines

a v2 without the formatting changes, and everyone is okay with it, I could spin a v2 without the formatting changes.

Please do.

If you do, I think you should spin the patches for the clean ups as well. At least I agree with (most) of them, and on a whole they definitely improve the recipes.

And I also agree with Andre, that in general it is too much trouble to generate clean up patches in their own, which is why it might be better to allow some clean ups together with actual changes. Otherwise they will not happen, which in the long run deteriorate the overall state of the recipes.

//Peter

#24 lore raw
Quoted 10 lines · Peter Kjellerstedt

If you do, I think you should spin the patches for the clean ups as well. At least I agree with (most) of them, and on a whole they definitely improve the recipes.

And I also agree with Andre, that in general it is too much trouble to generate clean up patches in their own, which is why it might be better to allow some clean ups together with actual changes. Otherwise they will not happen, which in the long run deteriorate the overall state of the recipes.

I'm happy to slowly go through the recipes and make formatting changes. What is the accepted canonical order of variables and segments in a recipe file? Oh, and did we agree on tabs, or spaces?

/me ducks...

#25 lore raw

meta-openembedded has oe-stylize.py, which is helpful for arranging things in the preferred order.

Cheers,
A.

Quoted 25 lines · On Sat, 19 May 2018, 20:35 Trevor Woerner, <[email protected]> wrote:
Quoted 10 lines · Peter Kjellerstedt

If you do, I think you should spin the patches for the clean ups as well. At least I agree with (most) of them, and on a whole they definitely improve the recipes.

And I also agree with Andre, that in general it is too much trouble to generate clean up patches in their own, which is why it might be better to allow some clean ups together with actual changes. Otherwise they will not happen, which in the long run deteriorate the overall state of the recipes.

I'm happy to slowly go through the recipes and make formatting changes. What is the accepted canonical order of variables and segments in a recipe file? Oh, and did we agree on tabs, or spaces?

/me ducks...
--
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

#26 lore raw
In reply to Trevor Woerner
Quoted 7 lines · Trevor Woerner
Quoted 5 lines · Peter Kjellerstedt

If you do, I think you should spin the patches for the clean ups as well. At least I agree with (most) of them, and on a whole they definitely improve the recipes.

Quoted 8 lines
Quoted 5 lines

And I also agree with Andre, that in general it is too much trouble to generate clean up patches in their own, which is why it might be better to allow some clean ups together with actual changes. Otherwise they will not happen, which in the long run deteriorate the overall state of the recipes.

I'm happy to slowly go through the recipes and make formatting changes. What is the accepted canonical order of variables and segments in a recipe file?

The OE style guide states that it should be considered the canonical reference (rather than for example contrib/oe-stylize.py):

http://www.openembedded.org/wiki/Styleguide

If you stick to non-controversial changes such as ordering of variables then I think it's a pretty good set of guidelines.

It hasn't been updated to give ordering for PACKAGECONFIG or BBCLASSEXTEND but the conventions for those (based on recipes in oe-core) seem to be:

- PACKAGECONFIG lines go between "inherit ..." and EXTRA_OECONF
- BBCLASSEXTEND goes at the end of the recipe

Quoted 1 line

Oh, and did we agree on tabs, or spaces?

No, probably never will :-)

Best approach would be to not mess with indent - unless you find a line indented with spaces between two lines indented with tabs (or vice versa).

#27 lore raw
Quoted 6 lines · Andre McCurdy

It hasn't been updated to give ordering for PACKAGECONFIG or BBCLASSEXTEND but the conventions for those (based on recipes in oe-core) seem to be:

- PACKAGECONFIG lines go between "inherit ..." and EXTRA_OECONF
- BBCLASSEXTEND goes at the end of the recipe

Done.

Thanks for the pointers/tips :-)