* [PATCH] Support building all project in one directory
@ 2010-01-14 7:55 Guo Hongruan
2010-01-14 9:14 ` Marcin Juszkiewicz
0 siblings, 1 reply; 20+ messages in thread
From: Guo Hongruan @ 2010-01-14 7:55 UTC (permalink / raw)
To: openembedded-devel
* Append ${LIBC} to CACHE, STAMP, WORKDIR, STAGING_DIR and CROSS_DIR defination, so that package building with different libc will not bother each other.
* Change the '${TMPDIR}/pkgdata/' to '${PKGDATA_DIR}/../', which make PKGDATA_DIR relocationable possible.
* Add mismatch ')' in classes/package_ipk.bbclass
* Override LIBC to null, so that projects with different libc will share the same native tools.
---
classes/native.bbclass | 2 ++
classes/package_ipk.bbclass | 2 +-
classes/packagedata.bbclass | 2 +-
conf/bitbake.conf | 16 ++++++++--------
4 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/classes/native.bbclass b/classes/native.bbclass
index 6698b61..01ee9b2 100644
--- a/classes/native.bbclass
+++ b/classes/native.bbclass
@@ -27,6 +27,8 @@ HOST_PREFIX = "${BUILD_PREFIX}"
HOST_CC_ARCH = "${BUILD_CC_ARCH}"
HOST_EXEEXT = "${BUILD_EXEEXT}"
+LIBC = ""
+
CPPFLAGS = "${BUILD_CPPFLAGS}"
CFLAGS = "${BUILD_CFLAGS}"
CXXFLAGS = "${BUILD_CFLAGS}"
diff --git a/classes/package_ipk.bbclass b/classes/package_ipk.bbclass
index 420c892..708b539 100644
--- a/classes/package_ipk.bbclass
+++ b/classes/package_ipk.bbclass
@@ -54,7 +54,7 @@ python package_ipk_install () {
if (not os.access(os.path.join(ipkdir,"Packages"), os.R_OK) or
- not os.access(os.path.join(tmpdir, "stamps", "IPK_PACKAGE_INDEX_CLEAN"),os.R_OK):
+ not os.access(os.path.join(tmpdir, "stamps", "IPK_PACKAGE_INDEX_CLEAN"),os.R_OK)):
ret = os.system('ipkg-make-index -p %s %s ' % (os.path.join(ipkdir, "Packages"), ipkdir))
if (ret != 0 ):
raise bb.build.FuncFailed
diff --git a/classes/packagedata.bbclass b/classes/packagedata.bbclass
index 86f18a9..a207841 100644
--- a/classes/packagedata.bbclass
+++ b/classes/packagedata.bbclass
@@ -25,7 +25,7 @@ def read_pkgdatafile(fn):
def get_subpkgedata_fn(pkg, d):
archs = bb.data.expand("${PACKAGE_ARCHS}", d).split(" ")
archs.reverse()
- pkgdata = bb.data.expand('${TMPDIR}/pkgdata/', d)
+ pkgdata = bb.data.expand('${PKGDATA_DIR}/../', d)
targetdir = bb.data.expand('${TARGET_VENDOR}-${TARGET_OS}/runtime/', d)
for arch in archs:
fn = pkgdata + arch + targetdir + pkg
diff --git a/conf/bitbake.conf b/conf/bitbake.conf
index 3a68959..cbe5f75 100644
--- a/conf/bitbake.conf
+++ b/conf/bitbake.conf
@@ -280,7 +280,7 @@ FILESDIR = "${@bb.which(d.getVar('FILESPATH', 1), '.')}"
##################################################################
TMPDIR = "${TOPDIR}/tmp"
-CACHE = "${TMPDIR}/cache${@['', '/' + str(bb.data.getVar('MACHINE', d, 1))][bool(bb.data.getVar('MACHINE', d, 1))]}"
+CACHE = "${TMPDIR}/cache/${LIBC}/${@['', '/' + str(bb.data.getVar('MACHINE', d, 1))][bool(bb.data.getVar('MACHINE', d, 1))]}"
CO_DIR = "${DL_DIR}"
CVSDIR = "${CO_DIR}/cvs"
SVNDIR = "${CO_DIR}/svn"
@@ -288,17 +288,17 @@ GITDIR = "${CO_DIR}/git"
BZRDIR = "${CO_DIR}/bzr"
HGDIR = "${CO_DIR}/hg"
-STAMP = "${TMPDIR}/stamps/${MULTIMACH_TARGET_SYS}/${PF}"
-WORKDIR = "${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PF}"
+STAMP = "${TMPDIR}/stamps/${LIBC}/${MULTIMACH_TARGET_SYS}/${PF}"
+WORKDIR = "${TMPDIR}/work/${LIBC}/${MULTIMACH_TARGET_SYS}/${PF}"
T = "${WORKDIR}/temp"
D = "${WORKDIR}/image"
S = "${WORKDIR}/${BP}"
B = "${S}"
-STAGING_DIR = "${TMPDIR}/staging"
+STAGING_DIR = "${TMPDIR}/staging/${LIBC}"
STAGING_DIR_JAVA = "${STAGING_DIR}/java"
-STAGING_DIR_NATIVE = "${STAGING_DIR}/${BUILD_SYS}"
+STAGING_DIR_NATIVE = "${TMPDIR}/staging/${BUILD_SYS}"
STAGING_BINDIR_NATIVE = "${STAGING_DIR_NATIVE}${bindir_native}"
STAGING_BINDIR_CROSS = "${STAGING_DIR_NATIVE}${bindir_native}/${MULTIMACH_HOST_SYS}"
STAGING_BINDIR_CROSS_BASEPKG = "${STAGING_DIR_NATIVE}${bindir_native}/${BASEPKG_TARGET_SYS}"
@@ -327,7 +327,7 @@ STAGING_DIR_SDK = "${STAGING_DIR}/${SDK_SYS}"
# Setting DEPLOY_DIR outside of TMPDIR is helpful, when you are using
# packaged staging and/or multimachine.
-DEPLOY_DIR ?= "${TMPDIR}/deploy"
+DEPLOY_DIR ?= "${TMPDIR}/deploy/${LIBC}"
DEPLOY_DIR_TAR = "${DEPLOY_DIR}/tar"
DEPLOY_DIR_IPK = "${DEPLOY_DIR}/ipk"
DEPLOY_DIR_RPM = "${DEPLOY_DIR}/rpm"
@@ -335,7 +335,7 @@ DEPLOY_DIR_DEB = "${DEPLOY_DIR}/deb"
DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images"
DEPLOY_DIR_TOOLS = "${DEPLOY_DIR}/tools"
-PKGDATA_DIR = "${TMPDIR}/pkgdata/${MULTIMACH_TARGET_SYS}"
+PKGDATA_DIR = "${TMPDIR}/pkgdata/${LIBC}/${MULTIMACH_TARGET_SYS}"
SDK_NAME = "${DISTRO}/${TARGET_ARCH}"
SDK_PATH = "/usr/local/${SDK_NAME}"
@@ -409,7 +409,7 @@ EXTRA_IMAGEDEPENDS = ""
# Toolchain info.
##################################################################
-CROSS_DIR = "${TMPDIR}/cross/${BASE_PACKAGE_ARCH}"
+CROSS_DIR = "${TMPDIR}/cross/${LIBC}/${BASE_PACKAGE_ARCH}"
CROSS_DATADIR = "${CROSS_DIR}/share"
PATH_prepend = "${STAGING_BINDIR_CROSS}:${STAGING_BINDIR_CROSS_BASEPKG}:${STAGING_DIR_NATIVE}${sbindir_native}:${STAGING_BINDIR_NATIVE}:${CROSS_DIR}/${bindir_cross}:${STAGING_DIR_NATIVE}${base_sbindir_native}:${STAGING_DIR_NATIVE}${base_bindir_native}:"
export PATH
--
1.5.4.3
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH] Support building all project in one directory
2010-01-14 7:55 [PATCH] Support building all project in one directory Guo Hongruan
@ 2010-01-14 9:14 ` Marcin Juszkiewicz
2010-01-14 9:19 ` Guo Hongruan
0 siblings, 1 reply; 20+ messages in thread
From: Marcin Juszkiewicz @ 2010-01-14 9:14 UTC (permalink / raw)
To: openembedded-devel
Dnia czwartek, 14 stycznia 2010 o 08:55:39 Guo Hongruan napisał(a):
> * Append ${LIBC} to CACHE, STAMP, WORKDIR, STAGING_DIR and CROSS_DIR
> defination, so that package building with different libc will not bother
> each other.
How does it differ from TMPDIR = "tmp/${LIBC}/" setting in local.conf? End
result is the same and you do not force all developers to restart their builds
from scratch.
Regards,
--
JID: hrw@jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH] Support building all project in one directory
2010-01-14 9:14 ` Marcin Juszkiewicz
@ 2010-01-14 9:19 ` Guo Hongruan
2010-01-14 19:53 ` Khem Raj
0 siblings, 1 reply; 20+ messages in thread
From: Guo Hongruan @ 2010-01-14 9:19 UTC (permalink / raw)
To: openembedded-devel
After changing this way, the native tools can be shared with different
buildings.
在 Thu, 14 Jan 2010 17:14:53 +0800,Marcin Juszkiewicz
<marcin@juszkiewicz.com.pl> 写道:
> Dnia czwartek, 14 stycznia 2010 o 08:55:39 Guo Hongruan napisał(a):
>> * Append ${LIBC} to CACHE, STAMP, WORKDIR, STAGING_DIR and CROSS_DIR
>> defination, so that package building with different libc will not
>> bother
>> each other.
>
> How does it differ from TMPDIR = "tmp/${LIBC}/" setting in local.conf?
> End
> result is the same and you do not force all developers to restart their
> builds
> from scratch.
>
> Regards,
--
Guo Hongruan, Embedded Linux Consultant
Skype: camelguo
Twitter: camelguo
http://www.gulessoft.com
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH] Support building all project in one directory
2010-01-14 9:19 ` Guo Hongruan
@ 2010-01-14 19:53 ` Khem Raj
2010-01-15 1:35 ` Guo Hongruan
0 siblings, 1 reply; 20+ messages in thread
From: Khem Raj @ 2010-01-14 19:53 UTC (permalink / raw)
To: openembedded-devel
On (14/01/10 17:19), Guo Hongruan wrote:
> After changing this way, the native tools can be shared with
> different buildings.
They get shared even now. I have my TMPDIR = /scratch/oe/build and
DEPLOY_DIR = ${TMPDIR}/deploy/${LIBC}
I share the native tools all the time
-Khem
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH] Support building all project in one directory
2010-01-14 19:53 ` Khem Raj
@ 2010-01-15 1:35 ` Guo Hongruan
2010-01-15 3:47 ` Mike Westerhof
2010-01-15 6:33 ` Marcin Juszkiewicz
0 siblings, 2 replies; 20+ messages in thread
From: Guo Hongruan @ 2010-01-15 1:35 UTC (permalink / raw)
To: openembedded-devel
在 Fri, 15 Jan 2010 03:53:01 +0800,Khem Raj <raj.khem@gmail.com> 写道:
> On (14/01/10 17:19), Guo Hongruan wrote:
>> After changing this way, the native tools can be shared with
>> different buildings.
>
> They get shared even now. I have my TMPDIR = /scratch/oe/build and
> DEPLOY_DIR = ${TMPDIR}/deploy/${LIBC}
>
> I share the native tools all the time
This way, the packages built in ${TMPDIR}/work/ will bother each other. It
is obvious that a binary package built based on uclibc is different with
the same one built base on glibc. So I think it's better to classify them
using ${LIBC}.
After applying my patch, all everything built based on uclibc will be
placed in some directories different with glibc,eglibc. The stamps will be
placed in ${TMPDIR}/stamps/${LIBC}, the package data will be placed in
${TMPDIR}/pkgdata/${LIBC} and so on. So you can see, when I tried to build
lots of projects (with different libc), their data will never bother each
other. In you way, we must select different TMPDIR for different libc,
that are very convenient for incremental building by QA.
And more, the native tools (quilt-native, qemu-native) are completely libc
independent, so they could be shared with projects with different libc.
After applying the patch, native tools are shared. It will save my
building machine lots of time on building native tools.
>
> -Khem
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
--
Guo Hongruan, Embedded Linux Consultant
Skype: camelguo
Twitter: camelguo
http://www.gulessoft.com
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH] Support building all project in one directory
2010-01-15 1:35 ` Guo Hongruan
@ 2010-01-15 3:47 ` Mike Westerhof
2010-01-15 9:17 ` Guo Hongruan
2010-01-15 6:33 ` Marcin Juszkiewicz
1 sibling, 1 reply; 20+ messages in thread
From: Mike Westerhof @ 2010-01-15 3:47 UTC (permalink / raw)
To: openembedded-devel
Guo Hongruan wrote:
> After applying my patch, all everything built based on uclibc will be
> placed in some directories different with glibc,eglibc. The stamps will
> be placed in ${TMPDIR}/stamps/${LIBC}, the package data will be placed
> in ${TMPDIR}/pkgdata/${LIBC} and so on. So you can see, when I tried to
> build lots of projects (with different libc), their data will never
> bother each other. In you way, we must select different TMPDIR for
> different libc, that are very convenient for incremental building by QA.
But most -- in fact all except perhaps yourself and a few of the OE core
team don't build with different LIBCs in the same TMPDIR. So all that
your patch does for the overwhelming number of users of OE is add
additional directory levels to an already complicated directory
structure, and provides them with absolutely no benefit whatsoever.
At the very least, you really should provide a means to selectively
enable this -- although I still don't see why it makes sense to support
multiple LIBCs in the same TMPDIR.
-Mike (mwester)
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH] Support building all project in one directory
2010-01-15 3:47 ` Mike Westerhof
@ 2010-01-15 9:17 ` Guo Hongruan
2010-01-15 9:56 ` Phil Blundell
0 siblings, 1 reply; 20+ messages in thread
From: Guo Hongruan @ 2010-01-15 9:17 UTC (permalink / raw)
To: openembedded-devel
在 Fri, 15 Jan 2010 11:47:25 +0800,Mike Westerhof <mike@mwester.net> 写道:
> But most -- in fact all except perhaps yourself and a few of the OE core
> team don't build with different LIBCs in the same TMPDIR. So all that
> your patch does for the overwhelming number of users of OE is add
> additional directory levels to an already complicated directory
> structure, and provides them with absolutely no benefit whatsoever.
Yes, I guest there are some developers who have to build OE in one
directory. Look at below:
distro/include/angstrom.inc:CACHE = "${TMPDIR}/cache/${LIBC}/${MACHINE}"
distro/include/kaeilos.inc:CACHE = "${TMPDIR}/cache/${LIBC}/${MACHINE}"
distro/micro.conf:CACHE ?= "${TMPDIR}/cache/${LIBC}/${MACHINE}"
distro/minimal.conf:CACHE ?= "${TMPDIR}/cache/${LIBC}/${MACHINE}"
distro/shr.conf:CACHE ?= "${TMPDIR}/cache/${LIBC}/${MACHINE}"
distro/include/angstrom.inc:DEPLOY_DIR = "${TMPDIR}/deploy/${LIBC}"
distro/include/kaeilos.inc:DEPLOY_DIR = "${TMPDIR}/deploy/${LIBC}"
distro/micro.conf:DEPLOY_DIR ?= "${TMPDIR}/deploy/${LIBC}"
distro/minimal.conf:DEPLOY_DIR ?= "${TMPDIR}/deploy/${LIBC}"
distro/shr.conf:DEPLOY_DIR ?= "${TMPDIR}/deploy/${LIBC}"
From above, I can guess that the developers or testers of the
distributions had met the same question as me. Without ${LIBS}, sometimes
it is difficult to determine which libc the runtime image is based on.
Image several weeks later how can you or other maintainers tell which libc
it's based on? Different libc means different sysroot, but without the
changes in the patch, the whole building does not distinguish the sysroot.
So I think adding ${LIBC} to build directory is necessary.
> At the very least, you really should provide a means to selectively
> enable this -- although I still don't see why it makes sense to support
> multiple LIBCs in the same TMPDIR.
I wanted to implement it just as the singlemachine.bbclass. But due to
some little bugs in other bbclass, it is impossible to implement the
function without any changes to other bbclass files. See the following
files:
classes/package_ipk.bbclass | 2 +-
classes/packagedata.bbclass | 2 +-
- pkgdata = bb.data.expand('${TMPDIR}/pkgdata/', d)
+ pkgdata = bb.data.expand('${PKGDATA_DIR}/../', d)
But, if the change is acceptable, I will try to implement it as a bbclass
file with a little patch file.
Thanks a lot!
--
Guo Hongruan, Embedded Linux Consultant
Skype: camelguo
Twitter: camelguo
http://www.gulessoft.com
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH] Support building all project in one directory
2010-01-15 9:17 ` Guo Hongruan
@ 2010-01-15 9:56 ` Phil Blundell
2010-01-15 10:42 ` Guo Hongruan
2010-01-15 10:43 ` Guo Hongruan
0 siblings, 2 replies; 20+ messages in thread
From: Phil Blundell @ 2010-01-15 9:56 UTC (permalink / raw)
To: openembedded-devel
On Fri, 2010-01-15 at 17:17 +0800, Guo Hongruan wrote:
> Without ${LIBS}, sometimes
> it is difficult to determine which libc the runtime image is based on.
For the majority of DISTROs, there is only a single supported C library
anyway so there should be no ambiguity. For example, if you build for
micro-uclibc, that means you are using uClibc. If you build for micro,
that means you are using eglibc.
So, I would not be in favour of rearranging the filesystem layout for
those DISTROs to make the selection of libc explicit in the pathnames.
p.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH] Support building all project in one directory
2010-01-15 9:56 ` Phil Blundell
@ 2010-01-15 10:42 ` Guo Hongruan
2010-01-15 10:46 ` Phil Blundell
2010-01-15 11:00 ` Koen Kooi
2010-01-15 10:43 ` Guo Hongruan
1 sibling, 2 replies; 20+ messages in thread
From: Guo Hongruan @ 2010-01-15 10:42 UTC (permalink / raw)
To: openembedded-devel
在 Fri, 15 Jan 2010 17:56:39 +0800,Phil Blundell <philb@gnu.org> 写道:
> For the majority of DISTROs, there is only a single supported C library
> anyway so there should be no ambiguity. For example, if you build for
> micro-uclibc, that means you are using uClibc. If you build for micro,
> that means you are using eglibc.
OE should provide a mechanism which should not restrict one certain libc
type.
Even though every distro supports only one libc type, you should be better
add ${LIBC} into your pathnames if you are trying to build multiple
projects (which use different libc) in one directory. To illustrate this
problem, let suppose that: you are trying to build DISTR_A which uses
glibc and DISTRO_B which uses eglibc for qemumips machine, What would
happended when building them in one directory?
tmp/work/mips-oe-linux/libassuan-0.6.9-r0
You can not tell which the package building of libassuan is based on. And
in fact, the next building will use the wrong temp files of packages
libassuan-0.6.9-r0. This case will cause some little questions which is
very very difficult to debug.
Most of the OE users do not need to build multiple projects in one
directory, but the QA does. The QA team need to setup regression test
environment. Without sharing, how much building time and disk space it
will consume!
--
Guo Hongruan, Embedded Linux Consultant
Skype: camelguo
Twitter: camelguo
http://www.gulessoft.com
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH] Support building all project in one directory
2010-01-15 10:42 ` Guo Hongruan
@ 2010-01-15 10:46 ` Phil Blundell
2010-01-15 10:59 ` Guo Hongruan
2010-01-15 11:00 ` Koen Kooi
1 sibling, 1 reply; 20+ messages in thread
From: Phil Blundell @ 2010-01-15 10:46 UTC (permalink / raw)
To: openembedded-devel
On Fri, 2010-01-15 at 18:42 +0800, Guo Hongruan wrote:
> OE should provide a mechanism which should not restrict one certain libc
> type.
>
> Even though every distro supports only one libc type, you should be better
> add ${LIBC} into your pathnames if you are trying to build multiple
> projects (which use different libc) in one directory. To illustrate this
> problem, let suppose that: you are trying to build DISTR_A which uses
> glibc and DISTRO_B which uses eglibc for qemumips machine, What would
> happended when building them in one directory?
You can't do this. There are many other reasons besides C library
selection why packages (and even -native tools, under some
circumstances) from DISTRO_A might be incompatible with those for
DISTRO_B. Mixing multiple DISTROs in a single TMPDIR is not, and never
has been, supported.
p.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH] Support building all project in one directory
2010-01-15 10:46 ` Phil Blundell
@ 2010-01-15 10:59 ` Guo Hongruan
2010-01-15 12:50 ` Phil Blundell
0 siblings, 1 reply; 20+ messages in thread
From: Guo Hongruan @ 2010-01-15 10:59 UTC (permalink / raw)
To: openembedded-devel
In fact, I just mixer multiple machines in a single TMPDIR with different
libcs. Hope I am lucky :)
在 Fri, 15 Jan 2010 18:46:36 +0800,Phil Blundell <philb@gnu.org> 写道:
> On Fri, 2010-01-15 at 18:42 +0800, Guo Hongruan wrote:
>> OE should provide a mechanism which should not restrict one certain libc
>> type.
>>
>> Even though every distro supports only one libc type, you should be
>> better
>> add ${LIBC} into your pathnames if you are trying to build multiple
>> projects (which use different libc) in one directory. To illustrate this
>> problem, let suppose that: you are trying to build DISTR_A which uses
>> glibc and DISTRO_B which uses eglibc for qemumips machine, What would
>> happended when building them in one directory?
>
> You can't do this. There are many other reasons besides C library
> selection why packages (and even -native tools, under some
> circumstances) from DISTRO_A might be incompatible with those for
> DISTRO_B. Mixing multiple DISTROs in a single TMPDIR is not, and never
> has been, supported.
>
> p.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
--
Guo Hongruan, Embedded Linux Consultant
Skype: camelguo
Twitter: camelguo
http://www.gulessoft.com
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH] Support building all project in one directory
2010-01-15 10:59 ` Guo Hongruan
@ 2010-01-15 12:50 ` Phil Blundell
2010-01-15 12:57 ` Guo Hongruan
0 siblings, 1 reply; 20+ messages in thread
From: Phil Blundell @ 2010-01-15 12:50 UTC (permalink / raw)
To: openembedded-devel
On Fri, 2010-01-15 at 18:59 +0800, Guo Hongruan wrote:
> In fact, I just mixer multiple machines in a single TMPDIR with different
> libcs. Hope I am lucky :)
Yes, mixing multiple MACHINEs in one TMPDIR is fine.
p.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] Support building all project in one directory
2010-01-15 12:50 ` Phil Blundell
@ 2010-01-15 12:57 ` Guo Hongruan
2010-01-15 13:02 ` Phil Blundell
0 siblings, 1 reply; 20+ messages in thread
From: Guo Hongruan @ 2010-01-15 12:57 UTC (permalink / raw)
To: openembedded-devel
In theory, mixing mutiple DISTROs in one TMPDIR should be fine too, unless
the package recipes use the DISTRO as OVERRIDE.
在 Fri, 15 Jan 2010 20:50:08 +0800,Phil Blundell <philb@gnu.org> 写道:
> On Fri, 2010-01-15 at 18:59 +0800, Guo Hongruan wrote:
>> In fact, I just mixer multiple machines in a single TMPDIR with
>> different
>> libcs. Hope I am lucky :)
>
> Yes, mixing multiple MACHINEs in one TMPDIR is fine.
>
> p.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
--
Guo Hongruan, Embedded Linux Consultant
Skype: camelguo
Twitter: camelguo
http://www.gulessoft.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] Support building all project in one directory
2010-01-15 12:57 ` Guo Hongruan
@ 2010-01-15 13:02 ` Phil Blundell
2010-01-15 13:09 ` Guo Hongruan
0 siblings, 1 reply; 20+ messages in thread
From: Phil Blundell @ 2010-01-15 13:02 UTC (permalink / raw)
To: openembedded-devel
On Fri, 2010-01-15 at 20:57 +0800, Guo Hongruan wrote:
> In theory, mixing mutiple DISTROs in one TMPDIR should be fine too, unless
> the package recipes use the DISTRO as OVERRIDE.
Several package recipes do indeed use the DISTRO as an override, but
even if this were not the case it would still not be safe to mix
multiple DISTROs in a single TMPDIR.
As I said before, the DISTRO configurations might be quite incompatible
in any number of ways: for example, they might be using entirely
different ABIs, or packaging systems, or binary formats, or package
naming conventions, or filesystem layouts.
p.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] Support building all project in one directory
2010-01-15 13:02 ` Phil Blundell
@ 2010-01-15 13:09 ` Guo Hongruan
0 siblings, 0 replies; 20+ messages in thread
From: Guo Hongruan @ 2010-01-15 13:09 UTC (permalink / raw)
To: openembedded-devel
在 Fri, 15 Jan 2010 21:02:39 +0800,Phil Blundell <philb@gnu.org> 写道:
> On Fri, 2010-01-15 at 20:57 +0800, Guo Hongruan wrote:
>> In theory, mixing mutiple DISTROs in one TMPDIR should be fine too,
>> unless
>> the package recipes use the DISTRO as OVERRIDE.
>
> Several package recipes do indeed use the DISTRO as an override, but
> even if this were not the case it would still not be safe to mix
> multiple DISTROs in a single TMPDIR.
>
> As I said before, the DISTRO configurations might be quite incompatible
> in any number of ways: for example, they might be using entirely
> different ABIs, or packaging systems, or binary formats, or package
> naming conventions, or filesystem layouts.
Yes, You are right, they are some questions we must consider before
continue.
>
> p.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
--
Guo Hongruan, Embedded Linux Consultant
Skype: camelguo
Twitter: camelguo
http://www.gulessoft.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] Support building all project in one directory
2010-01-15 10:42 ` Guo Hongruan
2010-01-15 10:46 ` Phil Blundell
@ 2010-01-15 11:00 ` Koen Kooi
1 sibling, 0 replies; 20+ messages in thread
From: Koen Kooi @ 2010-01-15 11:00 UTC (permalink / raw)
To: openembedded-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 15-01-10 11:42, Guo Hongruan wrote:
> 在 Fri, 15 Jan 2010 17:56:39 +0800,Phil Blundell <philb@gnu.org> 写道:
>
>> For the majority of DISTROs, there is only a single supported C library
>> anyway so there should be no ambiguity. For example, if you build for
>> micro-uclibc, that means you are using uClibc. If you build for micro,
>> that means you are using eglibc.
>
> OE should provide a mechanism which should not restrict one certain libc
> type.
>
> Even though every distro supports only one libc type
Angstrom supports glibc, uclibc and eglibc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFLUErPMkyGM64RGpERAt7EAKCx70to28K9IdhgjCmqyyL0N2ZIIQCfSJt8
ZcsK/7uJIjVbkKQWZTYjJCA=
=q9F7
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] Support building all project in one directory
2010-01-15 9:56 ` Phil Blundell
2010-01-15 10:42 ` Guo Hongruan
@ 2010-01-15 10:43 ` Guo Hongruan
1 sibling, 0 replies; 20+ messages in thread
From: Guo Hongruan @ 2010-01-15 10:43 UTC (permalink / raw)
To: openembedded-devel
In fact, I should implement it as a single bbclass file, which let you
enable or disable it through 'inherit'
在 Fri, 15 Jan 2010 17:56:39 +0800,Phil Blundell <philb@gnu.org> 写道:
> On Fri, 2010-01-15 at 17:17 +0800, Guo Hongruan wrote:
>> Without ${LIBS}, sometimes
>> it is difficult to determine which libc the runtime image is based on.
>
> For the majority of DISTROs, there is only a single supported C library
> anyway so there should be no ambiguity. For example, if you build for
> micro-uclibc, that means you are using uClibc. If you build for micro,
> that means you are using eglibc.
>
> So, I would not be in favour of rearranging the filesystem layout for
> those DISTROs to make the selection of libc explicit in the pathnames.
>
> p.
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
--
Guo Hongruan, Embedded Linux Consultant
Skype: camelguo
Twitter: camelguo
http://www.gulessoft.com
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] Support building all project in one directory
2010-01-15 1:35 ` Guo Hongruan
2010-01-15 3:47 ` Mike Westerhof
@ 2010-01-15 6:33 ` Marcin Juszkiewicz
2010-01-15 8:23 ` Koen Kooi
1 sibling, 1 reply; 20+ messages in thread
From: Marcin Juszkiewicz @ 2010-01-15 6:33 UTC (permalink / raw)
To: openembedded-devel
Dnia piątek, 15 stycznia 2010 o 02:35:13 Guo Hongruan napisał(a):
> 在 Fri, 15 Jan 2010 03:53:01 +0800,Khem Raj <raj.khem@gmail.com> 写道:
> > On (14/01/10 17:19), Guo Hongruan wrote:
> >> After changing this way, the native tools can be shared with
> >> different buildings.
> >
> > They get shared even now. I have my TMPDIR = /scratch/oe/build and
> > DEPLOY_DIR = ${TMPDIR}/deploy/${LIBC}
> >
> > I share the native tools all the time
> This way, the packages built in ${TMPDIR}/work/ will bother each other. It
> is obvious that a binary package built based on uclibc is different with
> the same one built base on glibc. So I think it's better to classify them
> using ${LIBC}.
As long as you do build for uclibc and glibc/eglibc in one TMPDIR they are
fine due to different TARGET_SYS. Problem starts when you want to share glibc
and eglibc builds as they use same TARGET_SYS. And thats when you need
something to separate TMPDIR. But as I wrote before you can alter name of
directories in your local.conf without changing them for rest of our users.
Regards,
--
JID: hrw@jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH] Support building all project in one directory
2010-01-15 6:33 ` Marcin Juszkiewicz
@ 2010-01-15 8:23 ` Koen Kooi
2010-01-15 9:23 ` Guo Hongruan
0 siblings, 1 reply; 20+ messages in thread
From: Koen Kooi @ 2010-01-15 8:23 UTC (permalink / raw)
To: openembedded-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 15-01-10 07:33, Marcin Juszkiewicz wrote:
> Dnia piątek, 15 stycznia 2010 o 02:35:13 Guo Hongruan napisał(a):
>> 在 Fri, 15 Jan 2010 03:53:01 +0800,Khem Raj <raj.khem@gmail.com> 写道:
>>> On (14/01/10 17:19), Guo Hongruan wrote:
>>>> After changing this way, the native tools can be shared with
>>>> different buildings.
>>>
>>> They get shared even now. I have my TMPDIR = /scratch/oe/build and
>>> DEPLOY_DIR = ${TMPDIR}/deploy/${LIBC}
>>>
>>> I share the native tools all the time
>
>> This way, the packages built in ${TMPDIR}/work/ will bother each other. It
>> is obvious that a binary package built based on uclibc is different with
>> the same one built base on glibc. So I think it's better to classify them
>> using ${LIBC}.
>
> As long as you do build for uclibc and glibc/eglibc in one TMPDIR they are
> fine due to different TARGET_SYS. Problem starts when you want to share glibc
> and eglibc builds as they use same TARGET_SYS. And thats when you need
> something to separate TMPDIR. But as I wrote before you can alter name of
> directories in your local.conf without changing them for rest of our users.
Or you can just use angstrom, which has all that magic already :)
regards,
Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFLUCYWMkyGM64RGpERAlzFAKCMEP4Gvm64Jr6LU28MamhAmdlULACcCKrK
xja2GfGxhQs2avrMe/3CZIw=
=vIXP
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH] Support building all project in one directory
2010-01-15 8:23 ` Koen Kooi
@ 2010-01-15 9:23 ` Guo Hongruan
0 siblings, 0 replies; 20+ messages in thread
From: Guo Hongruan @ 2010-01-15 9:23 UTC (permalink / raw)
To: openembedded-devel
在 Fri, 15 Jan 2010 16:23:50 +0800,Koen Kooi <k.kooi@student.utwente.nl>
写道:
> Or you can just use angstrom, which has all that magic already
Yes, I found it several days ago. But the question is that angstom have
not add ${LIBC} to ${TMPDIR}/stamps and ${TMPDIR}/pkgdata. If I just want
to build target images, it is enough. But I want to do incremental
building, so I have to keep the stamps and pkgdata within different
directories.
--
Guo Hongruan, Embedded Linux Consultant
Skype: camelguo
Twitter: camelguo
http://www.gulessoft.com
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2010-01-15 13:12 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-14 7:55 [PATCH] Support building all project in one directory Guo Hongruan
2010-01-14 9:14 ` Marcin Juszkiewicz
2010-01-14 9:19 ` Guo Hongruan
2010-01-14 19:53 ` Khem Raj
2010-01-15 1:35 ` Guo Hongruan
2010-01-15 3:47 ` Mike Westerhof
2010-01-15 9:17 ` Guo Hongruan
2010-01-15 9:56 ` Phil Blundell
2010-01-15 10:42 ` Guo Hongruan
2010-01-15 10:46 ` Phil Blundell
2010-01-15 10:59 ` Guo Hongruan
2010-01-15 12:50 ` Phil Blundell
2010-01-15 12:57 ` Guo Hongruan
2010-01-15 13:02 ` Phil Blundell
2010-01-15 13:09 ` Guo Hongruan
2010-01-15 11:00 ` Koen Kooi
2010-01-15 10:43 ` Guo Hongruan
2010-01-15 6:33 ` Marcin Juszkiewicz
2010-01-15 8:23 ` Koen Kooi
2010-01-15 9:23 ` Guo Hongruan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.