Re: [oe] [OE-core] [PATCH] cmake: respect ${S} and ${B}
On Thu, 2013-12-05 at 17:18 -0500, Philip Balister wrote:
> On 12/04/2013 07:38 PM, Ross Burton wrote:
> > Instead of the class-specific variables OECMAKE_BUILDPATH and
> > OECMAKE_SOURCEPATH, just use ${B} and ${S}.
> >
> > If these two paths are different, delete any existing ${B} before running a
> > build so that previous builds don't taint the current build.
> >
> > Note that OECMAKE_SOURCEPATH and OECMAKE_BUILDPATH are not respected at
> > all, so
> > recipes that manually set these in the past will need to be updated to
> > either
> > use something along the lines of separatebuilddir.inc or set B themselves.
>
> I'm carrying EXTRA_OEMAKE = "-C $(OECMAKE_BUILDPATH)" in recipes. It
> looks like this removes the need for this also? My cmake invocation is
> rusty :)
do_compile runs by default in ${B} so in most cases that shouldn't be
needed. The new equivalent would be "-C ${B}" but that shouldn't be
needed in most cases.
Cheers,
Richard
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] [PATCH] cmake: respect ${S} and ${B}
On 12/04/2013 07:38 PM, Ross Burton wrote:
> Instead of the class-specific variables OECMAKE_BUILDPATH and
> OECMAKE_SOURCEPATH, just use ${B} and ${S}.
>
> If these two paths are different, delete any existing ${B} before running a
> build so that previous builds don't taint the current build.
>
> Note that OECMAKE_SOURCEPATH and OECMAKE_BUILDPATH are not respected at all,
> so
> recipes that manually set these in the past will need to be updated to either
> use something along the lines of separatebuilddir.inc or set B themselves.
I'm carrying EXTRA_OEMAKE = "-C $(OECMAKE_BUILDPATH)" in recipes. It
looks like this removes the need for this also? My cmake invocation is
rusty :)
Philip
>
> Signed-off-by: Ross Burton
> ---
> meta/classes/cmake.bbclass | 31 +++
> 1 file changed, 7 insertions(+), 24 deletions(-)
>
> diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
> index 30c1792..4d1489a 100644
> --- a/meta/classes/cmake.bbclass
> +++ b/meta/classes/cmake.bbclass
> @@ -6,15 +6,6 @@ CCACHE = ""
> # We want the staging and installing functions from autotools
> inherit autotools
>
> -# Use in-tree builds by default but allow this to be changed
> -# since some packages do not support them (e.g. llvm 2.5).
> -OECMAKE_SOURCEPATH ?= "."
> -
> -# If declaring this, make sure you also set EXTRA_OEMAKE to
> -# "-C ${OECMAKE_BUILDPATH}". So it will run the right makefiles.
> -OECMAKE_BUILDPATH ?= ""
> -B="${S}"
> -
> # C/C++ Compiler (without cpu arch/tune arguments)
> OECMAKE_C_COMPILER ?= "`echo ${CC} | sed 's/^\([^ ]*\).*/\1/'`"
> OECMAKE_CXX_COMPILER ?= "`echo ${CXX} | sed 's/^\([^ ]*\).*/\1/'`"
> @@ -73,10 +64,10 @@ EOF
> addtask generate_toolchain_file after do_patch before do_configure
>
> cmake_do_configure() {
> - if [ ${OECMAKE_BUILDPATH} ]
> - then
> - mkdir -p ${OECMAKE_BUILDPATH}
> - cd ${OECMAKE_BUILDPATH}
> + if [ "${S}" != "${B}" ]; then
> + rm -rf ${B}
> + mkdir -p ${B}
> + cd ${B}
> fi
>
> # Just like autotools cmake can use a site file to cache result that
> need generated binaries to run
> @@ -88,7 +79,7 @@ cmake_do_configure() {
>
> cmake \
> ${OECMAKE_SITEFILE} \
> - ${OECMAKE_SOURCEPATH} \
> + ${S} \
> -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
> -DCMAKE_INSTALL_SO_NO_EXE=0 \
> -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
> @@ -98,20 +89,12 @@ cmake_do_configure() {
> }
>
> cmake_do_compile() {
> - if [ ${OECMAKE_BUILDPATH} ]
> - then
> - cd ${OECMAKE_BUILDPATH}
> - fi
> -
> + cd ${B}
> base_do_compile
> }
>
> cmake_do_install() {
> - if [ ${OECMAKE_BUILDPATH} ];
> - then
> - cd ${OECMAKE_BUILDPATH}
> - fi
> -
> + cd ${B}
> autotools_do_install
> }
>
>
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/1] mariadb-native: fix link error on Ubuntu 13.10
Great, what is the best way to apply this patch?
Please excuse my noobness.
Thanks,
Scott Penner
Goodwell Inc.
c. 4033761977
a. Box 906 Brooks, Ab T1R1B8
> On Dec 5, 2013, at 12:10 AM, "wenzong@windriver.com"
> wrote:
>
> From: Wenzong Fan
>
> Below errors only occurs on Ubuntu 13.10:
>
> $arch-linux-libtool: link: g++ ... -o .libs/mysqltest_embedded \
>../../libmysqld/.libs/libmysqld.so -ldl
>
>../../libmysqld/.libs/libmysqld.so: undefined reference to `dlopen'
>../../libmysqld/.libs/libmysqld.so: undefined reference to `dlclose'
>../../libmysqld/.libs/libmysqld.so: undefined reference to `dlerror'
>../../libmysqld/.libs/libmysqld.so: undefined reference to `dlsym'
>
> GCC/ld verion on the host:
>gcc (Ubuntu/Linaro 4.8.1-10ubuntu8) 4.8.1
>GNU ld (GNU Binutils for Ubuntu) 2.23.52.20130913
>
> This is a strange behavior on Ub13.10, it fails even '-ldl' in the
> link command line. This patch will append '-ldl' to dependency_libs
> in libmysqld.la.
>
> Signed-off-by: Wenzong Fan
> ---
> .../recipes-support/mysql/mariadb-native_5.1.67.bb |3 ++
> .../mysql/mariadb/fix-link-error-ub1310.patch | 37
> 2 files changed, 40 insertions(+)
> create mode 100644
> meta-oe/recipes-support/mysql/mariadb/fix-link-error-ub1310.patch
>
> diff --git a/meta-oe/recipes-support/mysql/mariadb-native_5.1.67.bb
> b/meta-oe/recipes-support/mysql/mariadb-native_5.1.67.bb
> index a55c2ab..dccbfd0 100644
> --- a/meta-oe/recipes-support/mysql/mariadb-native_5.1.67.bb
> +++ b/meta-oe/recipes-support/mysql/mariadb-native_5.1.67.bb
> @@ -8,6 +8,9 @@ PACKAGES = ""
> EXTRA_OEMAKE = ""
> EXTRA_OECONF = " --with-embedded-server "
>
> +SRC_URI += "file://fix-link-error-ub1310.patch \
> +"
> +
> do_install() {
> oe_runmake 'DESTDIR=${D}' install
> mv -f ${D}${libdir}/mysql/* ${D}${libdir}
> diff --git
> a/meta-oe/recipes-support/mysql/mariadb/fix-link-error-ub1310.patch
> b/meta-oe/recipes-support/mysql/mariadb/fix-link-error-ub1310.patch
> new file mode 100644
> index 000..a528ea7
> --- /dev/null
> +++ b/meta-oe/recipes-support/mysql/mariadb/fix-link-error-ub1310.patch
> @@ -0,0 +1,37 @@
> +mariadb-native: fix link error on Ubuntu 13.10
> +
> +Below errors only occurs on Ubuntu 13.10:
> +
> +$arch-linux-libtool: link: g++ ... -o .libs/mysqltest_embedded \
> +../../libmysqld/.libs/libmysqld.so -ldl
> +
> +../../libmysqld/.libs/libmysqld.so: undefined reference to `dlopen'
> +../../libmysqld/.libs/libmysqld.so: undefined reference to `dlclose'
> +../../libmysqld/.libs/libmysqld.so: undefined reference to `dlerror'
> +../../libmysqld/.libs/libmysqld.so: undefined reference to `dlsym'
> +
> +GCC/ld verion on the host:
> +gcc (Ubuntu/Linaro 4.8.1-10ubuntu8) 4.8.1
> +GNU ld (GNU Binutils for Ubuntu) 2.23.52.20130913
> +
> +This is a strange behavior on Ub13.10, it fails even '-ldl' in the
> +link command line. Below fix will append '-ldl' to dependency_libs
> +in libmysqld.la.
> +
> +Upstream-Status: Submitted [https://mariadb.atlassian.net/browse/MDEV-5362]
> +
> +Signed-off-by: Wenzong Fan
> +
> +diff --git a/libmysqld/Makefile.am b/libmysqld/Makefile.am
> +index 7a2c92e..eee501e 100644
> +--- a/libmysqld/Makefile.am
> b/libmysqld/Makefile.am
> +@@ -92,7 +92,7 @@ INC_LIB=$(top_builddir)/regex/libregex.la \
> + @ndbcluster_libs@ @NDB_SCI_LIBS@ \
> +@mysql_embedded_plugin_libs@ \
> +$(libevent_inc_libs) \
> +-$(yassl_inc_libs)
> ++$(yassl_inc_libs) @LIBDL@
> +
> + if HAVE_YASSL
> + yassl_inc_libs=$(top_builddir)/extra/yassl/src/libyassl.la \
> --
> 1.7.10.4
>
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-filesystems][PATCH v2] xfsprogs: change DESCRIPTION to SUMMARY
Acked-by: Koen Kooi Op 5 dec. 2013, om 13:47 heeft Andreas Oberritter het volgende geschreven: > Ping. > > On 17.10.2013 13:50, Andreas Oberritter wrote: >> Signed-off-by: Andreas Oberritter >> --- >> meta-filesystems/recipes-utils/xfsprogs/xfsprogs_3.1.11.bb | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/meta-filesystems/recipes-utils/xfsprogs/xfsprogs_3.1.11.bb >> b/meta-filesystems/recipes-utils/xfsprogs/xfsprogs_3.1.11.bb >> index ceb0ddf..1dc6f09 100644 >> --- a/meta-filesystems/recipes-utils/xfsprogs/xfsprogs_3.1.11.bb >> +++ b/meta-filesystems/recipes-utils/xfsprogs/xfsprogs_3.1.11.bb >> @@ -1,4 +1,4 @@ >> -DESCRIPTION = "XFS Filesystem Utilities" >> +SUMMARY = "XFS Filesystem Utilities" >> HOMEPAGE = "http://oss.sgi.com/projects/xfs"; >> SECTION = "base" >> LICENSE = "GPLv2" >> > > ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-filesystems][PATCH v2] xfsprogs: change DESCRIPTION to SUMMARY
Ping. On 17.10.2013 13:50, Andreas Oberritter wrote: > Signed-off-by: Andreas Oberritter > --- > meta-filesystems/recipes-utils/xfsprogs/xfsprogs_3.1.11.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta-filesystems/recipes-utils/xfsprogs/xfsprogs_3.1.11.bb > b/meta-filesystems/recipes-utils/xfsprogs/xfsprogs_3.1.11.bb > index ceb0ddf..1dc6f09 100644 > --- a/meta-filesystems/recipes-utils/xfsprogs/xfsprogs_3.1.11.bb > +++ b/meta-filesystems/recipes-utils/xfsprogs/xfsprogs_3.1.11.bb > @@ -1,4 +1,4 @@ > -DESCRIPTION = "XFS Filesystem Utilities" > +SUMMARY = "XFS Filesystem Utilities" > HOMEPAGE = "http://oss.sgi.com/projects/xfs"; > SECTION = "base" > LICENSE = "GPLv2" > ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] [RFC][PATCH] cmake: respect ${S} and ${B}
On Thu, Dec 05, 2013 at 10:10:02AM +, Richard Purdie wrote:
> On Thu, 2013-12-05 at 00:38 +, Ross Burton wrote:
> > Hi,
> >
> > This is a Request For Comments because it changes behaviour of the cmake
> > class
> > and I'm not entirely knowledgeable in cmake.
> >
> > For some reason, cmake.bbclass doesn't use ${S} and ${B}, but instead has
> > it's
> > own variables OECMAKE_SOURCEPATH ("." by default) and OECMAKE_BUILDPATH (""
> > by
> > default). Those defaults meant that the build happened in the source
> > directory,
> > which conveniently was ${S}. Unless ${B} was also set, in which case it all
> > broke.
> >
> > I don't see a good reason for cmake.bbclass having it's own special
> > versions of
> > ${S} and ${B}, so this patch drops them and replicates some of the logic in
> > autotools.bbclass: specifically the part where if ${S} and ${B} are
> > different,
> > delete ${B} before building. This ensures that switching machine doesn't
> > re-use
> > the same build directory, which was the cause of me going back to look at
> > this
> > (libproxy trying to use the nuc sysroot when I'm building for qemux86-64).
> >
> > Some open questions:
> >
> > 1) As I understand it cmake has more reliable support for out-of-tree builds
> > than autotools. If this is the case should cmake.bbclass set B ?=
> > "${WORKDIR}/build", or leave setting of B to separatebuilddir.inc? Are
> > there
> > known recipes using cmake that fail with out-of-tree builds?
>
> separatebuilddir.inc was really a stopgap solution to see how widespread
> potential issues were. Ideally I'd like to get to the point where
> recipes flag themselves are broken with out of tree builds rather than
> having a list of ones which are compatible.
>
> Doing this for OE-Core is straightforward now but what about meta-oe?
>
> Would there be interest in trying to change that default or is it going
> to be too painful?
It would be nice to change it in smaller steps, e.g. by bbclasses.
I'm already using separate B by default in meta-qt5 and it works good.
Adding it in cmake, qmake4, then autotools.bbclass, then ... would allow
to fix meta-oe recipes in smaller chunks instead of trying to fix them
all at once. And if we change it only for few .bbclasses then it would
still be improvement.
> This means I'm in favour of changing the cmake default if we can, it
> looks like a simpler problem space than autotools.bbclass
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] [RFC][PATCH] cmake: respect ${S} and ${B}
On Thu, 2013-12-05 at 00:38 +, Ross Burton wrote:
> Hi,
>
> This is a Request For Comments because it changes behaviour of the cmake class
> and I'm not entirely knowledgeable in cmake.
>
> For some reason, cmake.bbclass doesn't use ${S} and ${B}, but instead has it's
> own variables OECMAKE_SOURCEPATH ("." by default) and OECMAKE_BUILDPATH ("" by
> default). Those defaults meant that the build happened in the source
> directory,
> which conveniently was ${S}. Unless ${B} was also set, in which case it all
> broke.
>
> I don't see a good reason for cmake.bbclass having it's own special versions
> of
> ${S} and ${B}, so this patch drops them and replicates some of the logic in
> autotools.bbclass: specifically the part where if ${S} and ${B} are different,
> delete ${B} before building. This ensures that switching machine doesn't
> re-use
> the same build directory, which was the cause of me going back to look at this
> (libproxy trying to use the nuc sysroot when I'm building for qemux86-64).
>
> Some open questions:
>
> 1) As I understand it cmake has more reliable support for out-of-tree builds
> than autotools. If this is the case should cmake.bbclass set B ?=
> "${WORKDIR}/build", or leave setting of B to separatebuilddir.inc? Are there
> known recipes using cmake that fail with out-of-tree builds?
separatebuilddir.inc was really a stopgap solution to see how widespread
potential issues were. Ideally I'd like to get to the point where
recipes flag themselves are broken with out of tree builds rather than
having a list of ones which are compatible.
Doing this for OE-Core is straightforward now but what about meta-oe?
Would there be interest in trying to change that default or is it going
to be too painful?
This means I'm in favour of changing the cmake default if we can, it
looks like a simpler problem space than autotools.bbclass
Cheers,
Richard
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] [RFC][PATCH] cmake: respect ${S} and ${B}
On 5 December 2013 09:47, Stefan Herbrechtsmeier
wrote:
> I think deleting ${B} before building is wrong. If the build directory makes
> problem you should have the same problems when ${S} and ${B} are same or you
> should remove the ${B} directories when you remove the build files from
> ${S}.
Yes, without S!=B there are problems, and the solution is to put B in
a separate directory and delete the old one when starting a build.
Removing the build files from ${S} is "non-trivial", running "make
clean" isn't universal, and even for autotools distclean isn't always
enough.
oe-core has this as opt-in behaviour for as many modules as possible
and it makes switching machines so much nicer, as you don't get
modules using the previous sysroot. libproxy does this on demand
currently, and anything using libtool will also have this problem.
Ross
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] [RFC][PATCH] cmake: respect ${S} and ${B}
Am 05.12.2013 01:55, schrieb Martin Jansa:
On Thu, Dec 05, 2013 at 12:38:57AM +, Ross Burton wrote:
Hi,
This is a Request For Comments because it changes behaviour of the cmake class
and I'm not entirely knowledgeable in cmake.
Neither am I, but patch looks reasonable and I like it, because I was
planing to do something similar.
Maybe you should add a warning if OECMAKE_BUILDPATH is not "" as
otherwise the package behaviour will change without any note.
For some reason, cmake.bbclass doesn't use ${S} and ${B}, but instead has it's
own variables OECMAKE_SOURCEPATH ("." by default) and OECMAKE_BUILDPATH ("" by
default). Those defaults meant that the build happened in the source directory,
which conveniently was ${S}. Unless ${B} was also set, in which case it all
broke.
I don't see a good reason for cmake.bbclass having it's own special versions of
${S} and ${B}, so this patch drops them and replicates some of the logic in
autotools.bbclass: specifically the part where if ${S} and ${B} are different,
delete ${B} before building.
I think deleting ${B} before building is wrong. If the build directory
makes problem you should have the same problems when ${S} and ${B} are
same or you should remove the ${B} directories when you remove the build
files from ${S}.
This ensures that switching machine doesn't re-use
the same build directory, which was the cause of me going back to look at this
(libproxy trying to use the nuc sysroot when I'm building for qemux86-64).
Some open questions:
1) As I understand it cmake has more reliable support for out-of-tree builds
than autotools. If this is the case should cmake.bbclass set B ?=
"${WORKDIR}/build", or leave setting of B to separatebuilddir.inc? Are there
known recipes using cmake that fail with out-of-tree builds?
2) Is dropping OECMAKE_SOURCEPATH and OECMAKE_BUILDPATH acceptable? Nothing in
oe-core uses them and there's three (IIRC) recipes in meta-oe that use them.
Assuming the answer to (1) is "separatebuilddir.inc" then the only fallout
should be these recipes using in-tree builds until OECMAKE_BUILDPATH is replaced
with B.
As you more or less only rename the variables it should be acceptable
but I would proposed to add a warning or error if some recipe use the
old variables.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] fbgrab 1.2: Add recipe.
Signed-off-by: Denis Carikli
---
meta-oe/recipes-graphics/fbgrab/fbgrab_1.2.bb | 14 ++
1 file changed, 14 insertions(+)
create mode 100644 meta-oe/recipes-graphics/fbgrab/fbgrab_1.2.bb
diff --git a/meta-oe/recipes-graphics/fbgrab/fbgrab_1.2.bb
b/meta-oe/recipes-graphics/fbgrab/fbgrab_1.2.bb
new file mode 100644
index 000..5b55762
--- /dev/null
+++ b/meta-oe/recipes-graphics/fbgrab/fbgrab_1.2.bb
@@ -0,0 +1,14 @@
+DESCRIPTION = "FBGrab is a framebuffer screenshot program."
+HOMEPAGE = "http://fbgrab.monells.se/";
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=ea5bed2f60d357618ca161ad539f7c0a"
+SECTION = "console/utils"
+DEPENDS = "libpng zlib"
+SRC_URI = "http://fbgrab.monells.se/${P}.tar.gz";
+
+inherit autotools
+
+S = "${WORKDIR}/${PN}"
+
+SRC_URI[md5sum] = "15b432735d6efd0373722bb96577b945"
+SRC_URI[sha256sum] =
"61e0772ad6ea744ee597ae478398ddd0ba6fceee2cf343859bebde2c15bafb91"
--
1.7.9.5
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-oe][PATCH] mosh: Perl module dependencies were missing
Signed-off-by: Jukka Rissanen
---
meta-oe/recipes-connectivity/mosh/mosh_1.2.4.bb | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/meta-oe/recipes-connectivity/mosh/mosh_1.2.4.bb
b/meta-oe/recipes-connectivity/mosh/mosh_1.2.4.bb
index c0d03c5..5a8e336 100644
--- a/meta-oe/recipes-connectivity/mosh/mosh_1.2.4.bb
+++ b/meta-oe/recipes-connectivity/mosh/mosh_1.2.4.bb
@@ -24,8 +24,15 @@ inherit autotools
PACKAGE_BEFORE_PN += "${PN}-server"
FILES_${PN}-server = "${bindir}/mosh-server"
+NEEDED_PERL_MODULES = "\
+ perl-module-socket \
+ perl-module-getopt-long \
+ perl-module-errno \
+ perl-module-io-socket-inet \
+ perl-module-posix \
+"
+
# mosh uses SSH to authenticate and the client uses OpenSSH-specific features
-RDEPENDS_${PN} += "openssh-ssh"
+RDEPENDS_${PN} += "openssh-ssh ${NEEDED_PERL_MODULES}"
# The server seemed not to work with dropbear either
-RDEPENDS_${PN}-server += "openssh-sshd"
-
+RDEPENDS_${PN}-server += "openssh-sshd ${NEEDED_PERL_MODULES}"
--
1.8.3.1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
