libwebsockets: rely on cmake.bbclass to put cmake package files in dev package
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
@@ -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
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
@@ -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
PATCH 3/17 rocksdb: rely on cmake.bbclass to put cmake package files in dev package
In reply to Andre McCurdyThe 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
@@ -28,5 +28,3 @@ EXTRA_OECMAKE = "\ -DWITH_TESTS=OFF \ -DWITH_TOOLS=OFF \ " - -FILES_${PN}-dev += "${libdir}/cmake"
Signature · 1 line
1.9.1
PATCH 4/17 capnproto: rely on cmake.bbclass to put cmake package files in dev package
In reply to Andre McCurdyThe 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
@@ -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
PATCH 5/17 grpc: rely on cmake.bbclass to put cmake package files in dev package
In reply to Andre McCurdyThe 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
@@ -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
PATCH 6/17 json-spirit: rely on cmake.bbclass to put cmake package files in dev package
In reply to Andre McCurdyThe 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
@@ -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
PATCH 7/17 librcf: rely on cmake.bbclass to put cmake package files in dev package
In reply to Andre McCurdyThe 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
@@ -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
PATCH 8/17 msgpack-c: rely on cmake.bbclass to put cmake package files in dev package
In reply to Andre McCurdyThe 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
@@ -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
PATCH 9/17 rapidjson: rely on cmake.bbclass to put cmake package files in dev package
In reply to Andre McCurdyThe 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
@@ -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
PATCH 10/17 glm: rely on cmake.bbclass to put cmake package files in dev package
In reply to Andre McCurdyThe 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
@@ -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
PATCH 11/17 openjpeg: rely on cmake.bbclass to put cmake package files in dev package
In reply to Andre McCurdyThe 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
@@ -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
PATCH 12/17 ceres-solver: rely on cmake.bbclass to put cmake package files in dev package
In reply to Andre McCurdyThe 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
@@ -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
PATCH 13/17 gflags: rely on cmake.bbclass to put cmake package files in dev package
In reply to Andre McCurdyThe 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
@@ -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
PATCH 14/17 libftdi: rely on cmake.bbclass to put cmake package files in dev package
In reply to Andre McCurdyThe 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
@@ -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
PATCH 15/17 libssh: rely on cmake.bbclass to put cmake package files in dev package
In reply to Andre McCurdyThe 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
@@ -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
PATCH 16/17 libtinyxml2: rely on cmake.bbclass to put cmake package files in dev package
In reply to Andre McCurdyThe 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
@@ -12,6 +12,4 @@ S = "${WORKDIR}/git" inherit cmake -FILES_${PN}-dev += "${libdir}/cmake/" - BBCLASSEXTEND = "native"
Signature · 1 line
1.9.1
PATCH 17/17 poco: rely on cmake.bbclass to put cmake package files in dev package
In reply to Andre McCurdyThe 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
@@ -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
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=d91dc4666683a96e9d03cbbd21b8a546f9069c93Signed-off-by Andre McCurdy <[email protected]>--- 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@@ -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/*"
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
Signed-off-by Andre McCurdy <[email protected]>--- 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/*"
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
Signed-off-by Andre McCurdy <[email protected]>--- 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/*"
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
Signed-off-by Andre McCurdy <[email protected]>--- 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/*"
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.
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.
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 packageQuoted 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 McCurdyQuoted 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
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...
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
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).
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 :-)